Jeffrey Puro wrote:
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?
The lightweight components have three very specific points:
* they are not deployed in the way the JBI spec mandates
* they do not accept deployment of service units
The JBI spec sees components as "containers": a BPEL engine is a very good
example of such a container. You deploy a BPEL process, packaged as a
service unit, and the component activates one or more endpoints according
to the bpel process. The lightweight components do not accept service
units:
they are not containers and they only activate one JBI endpoint (service
name
+ endpoint name) specified in the activationSpec.
The servicemix.xml file is a ServiceMix specific (not JBI compliant) way of
deploying these components. The main purpose is to ease JBI use and to
allow the JBI container to be easily embedded in an application (web or
not).
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...
The new snapshot distributions now contains several examples of the "JBI
way" to
build a JBI application. See bpel, soap-binding and loan-broker.
The JBI spec uses service units and service assemblies.
A service unit is something that will be deployed to an installed component.
Service units must be grouped in a service assembly, which contains a
jbi descriptor
describing the service units and target components.
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.
The JBI spec says that each endpoint (not each component) must have a
WSDL 2 abstract description of
the endpint. So the WSDL would contain one interface definition (port
type in the wsdl 1 terminology)
and the associated messages and schema definitions.
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?
If you use lightweight components and the servicemix.xml configuration file,
WSDL will not add much to you. The only feature that WSDLs add is the
ability for the container
to better check message routing and this is the only standard way for
the container to discover
what interfaces an endpoint implements. A JBI MessageExchange can
contain the name of the target
interface and the name of the target operation: these features are fully
supported by the ServiceMix container
but not used by the lightweight components.
Cheers,
Guillaume Nodet
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.
