Guillaume, Couple of questions for you:
1) What do you mean that these components are not in the spirit of JBI? Please give all the details on what in your opinion makes these non JBI "spirited"? :). Is this just in regards to how they can be deployed? 2) Can you provide an example of the two different deployment scenarios? I think it would help to understand this email thread a little better with real use cases etc... 3) What does JBI say that a WSDL for a component will look like? In my head a WSDL will describe all the expected messages (data types) and operations of a component, but I suspect with JBI and components it's a little more abstract than this. I took a look at the JBI spec but I'm not sure how it requires a WSDL to look in the context of ServiceMix. 4) Once components expose their wsdl's, how will routing to these components change? What does exposing a WSDL for a component really do for us when all we are doing is configuring things via spring beans? Thanks, Jeff -----Original Message----- From: Guillaume Nodet [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 10:46 AM To: [email protected] Subject: Re: [servicemix-user] Distribution of ServiceMix Hi ! We are not avoiding these questions :) ServiceMix aims to be 100% JBI compliant, but I do not pretend we are yet. We do not have a TCK, but as soon as we get one, we will ensure it passes it. As for WSDL, you are right that the lightweight components do not expose any wsdl interface. But these components are not really in the spirit of the JBI spec either: they do not support service unit deployments. But they offer a more light weight approach of JBI. When you implement a specifiation, you do not have to limit yourself to what the spec says and we hope to further ease the use of JBI with other enhancements. The 3.0 version of ServiceMix, which we are working on, will offer new components, which are written in the spirit of the JBI spec. They support wsdl or xml deployment, so that the service units you deploy on them can expose a wsdl for their service. I will also say that we do not support WSDL 2.0 yet, which the JBI spec mandates (we will use Apache Woden for that). But one of the reason is that WSDL 2 is not very known / used and no WS-* specifications uses it yet. Btw, this is an open source project, and we have nothing to hide. You are also free to join the team and contribute to any area you wish, in particular JBI compliance :) Cheers, Guillaume Nodet Kosuru, Giri wrote: >Hi Hendrik, > > Even I have questions about ServiceMix claim as JBI implementor. >As per JBI specification 4.1, every component has to expose WSDL to be >claimed as JBI complaint. But I saw no component with WSDL interface in >Servicemix examples. I asked these questions to James Strachen on TSS >and in these forums. Due to unkonown reason, the servicemix team is >avoiding to answer these questions. But by any chance, if you get an >answer, please share with me. > >Thanks >Kosuru > >-----Original Message----- >From: Hendrik Jander [mailto:[EMAIL PROTECTED] >Sent: Friday, February 10, 2006 4:21 AM >To: [email protected] >Subject: [servicemix-user] Distribution of ServiceMix > >Hello, > >im doing some research on ESB's actually and also evaluated ServiceMix >while >this. > >Im a bit confused about the Distribution aspect of ServiceMix.This is >because i >read that that JBI itself in its actual version is not distributed. >So how can ServiceMix implement an distributed ESB based on JBI? > >in the docs i only can find doucmentation about JMS topologies. >so , is this the key to distribution of ServicexMix? and if so, is the >service >repository then also distributed? > >This may be newbie question for you, but im a bit confused with the >stuff..:) > >REgards, >Hendrik > > >---------------------------------------------------------------- >This mail was sent through http://webmail.uni-jena.de > > > > This email (and any attachments) is intended only for the use of the individual or entity named above and may contain information that is privileged and confidential. If you are not the intended recipient, or have unauthorized access, you are hereby notified that copying, disseminating, distributing or taking any action in reliance on this email is strictly prohibited. Opinions, conclusions and other information in this message that do not relate to the official business of our company shall be understood as neither given nor endorsed by it.
