Hi Joe It seems to me that the coupling you require between these legacy apps might be too high to consider for using ServiceMix. If two or more apps are talking to each other in any way other than through the NMR as service units, they will be using some method other than JBI. The JBI spec's prime reason for existence is to provide a single, SOAP-based, message transport facility. One either uses it or one doesn't. The choice depends on the degree of sacrifice one must make.
Unless these objects can be serialised (converted to XML) and sent via SOAP, my knowledge of ServiceMix or JBI (which I think is comprehensive enough) tells me that your coupling requirements may not be satisfied. This may be a case where you might have to sacrifice universal conversion to an SOA for the sake of continuing to meet business objectives. The NMR and SU's use MBeans to receive and transmit management information relating to their execution state. See chapter 10 of the JBI 1.0 spec (follow the link provided below) for more info on these. However, I believe it is the case that MBeans are not shared between SU's in the exchange of information relating to the services provided. If MBeans were shared between services for information relating to what each service did, they would be subverting the NMR, and the exchange would be independent of JBI. I hope that's clarifying things for you so that you have a better understanding of whether, in your particular instance, using JBI is going to be good for you. Have a good day, Owen. PS: In case you don't have the 1.0 JBI spec, you get it from here: http://jcp.org/aboutJava/communityprocess/final/jsr208/index.html -----Original Message----- From: jbi joe [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 6:28 PM To: [email protected] Subject: RE: Service unit to service unit interopperability Is there a recommended standard for two related serviceunits within the same service assembly to exchange objects, such as a Managed BEAN?? Im not lookin to redevelop the wheel, but ask what the recommended way should be. ALthough I would prefer some XML, the service units I have are converted from legacy apps and require sharing an OBJECT. SO I was thinkin a Managed Bean might work? If so, is there an example somewhere? TIA Owen Thomas wrote: > > Hi there. > > Thought, as I am usually so prolific in asking questions here, take your > question as an opportunity to provide some advice. > > What you have with JBI is a way for message exchange that is > standardised for the purpose of interoperability. If JBI doesn't, for > whatever reason, suit your requirements for exchanging messages between > applications, it probably might be better to base your message exchange > on some other standard, or to develop your own. > > Owen. > > -----Original Message----- > From: jbi joe [mailto:[EMAIL PROTECTED] > Sent: Monday, May 07, 2007 10:09 AM > To: [email protected] > Subject: Re: Service unit to service unit interopperability > > > > From your reply, it appears that communications between > different service units within a service assembly are done > via NMR?? > Would like to have service units within a single service assembly > be able to talk more readily than the expense of wsdl, etc.. > TIA > > > gnodet wrote: >> >> What do you mean by interoperability ? >> Service contracts should be defined by their respective WSDL. >> >> On 5/5/07, Java Energizer <[EMAIL PROTECTED]> wrote: >>> >>> Is there a url on recommended interopperability between >>> service units within the same service assembly? >>> TIA >>> >> >> >> >> -- >> Cheers, >> Guillaume Nodet >> ------------------------ >> Principal Engineer, IONA >> Blog: http://gnodet.blogspot.com/ >> >> > > -- > View this message in context: > http://www.nabble.com/Service-unit-to-service-unit-interopperability-tf3 > 696183s12049.html#a10350651 > Sent from the ServiceMix - User mailing list archive at Nabble.com. > > > -- View this message in context: http://www.nabble.com/Service-unit-to-service-unit-interopperability-tf3 696183s12049.html#a10353816 Sent from the ServiceMix - User mailing list archive at Nabble.com.
