In your example, you want a single request to be processed by several
providers and
aggregate their responses. This can not be handled automatically by JBI
: the aggregation part
must contains business logic and thus can not be done in a generic way.
Such situations are extensively described in the EIP book
(http://www.enterpriseintegrationpatterns.com/eaipatterns.html).
Note that the EIP patterns are geared towards asynchronous messaging,
which is not always easy to map to an in-out mep,
because the patterns usually use in-only messages.
First, there are two possibilities :
* use publish / subscribe : each provider will register itself so that
it will receive messages. the main problem is for the aggregator
that has no simple way to know how many messages it will need to
aggregate
* use a recipient list
For the first case, ServiceMix offer two ways : internal publish /
subscribe (in the xml config, you specify on the activation spec the
endpoint you
want to subscribe to) or WS-Notification (servicemix-wsn2005 service
engine).
Using a recipient list may be easier, as a JBI endpoints may implement
one or more interfaces. In this case, you could have a component
which will ask jbi for endpoints implementing a known interface. It
could send an in-out to each of these endpoints, select the best offer,
and discard the others.
JBI also defines interface base routing : when a consumer send an
exchange, it can specify the interface name that should service the request.
The NMR will select an endpoint that implements this interface. This
can be customized using policies
(see org.apache.servicemix.jbi.resolver.EndpointChooser) on an
activation spec for example.
So to answer your question, there is a kind of mapping between logical
and physical endpoints, but this is done by interfaces.
Cheers,
Guillaume Nodet
PS: you can take a look at
http://www.enterpriseintegrationpatterns.com/RecipientList.html
http://www.enterpriseintegrationpatterns.com/PublishSubscribeChannel.html
http://www.enterpriseintegrationpatterns.com/Aggregator.html
Charles Souillard wrote:
What I mean by logical/physical endpoint is :
Let's take the example of a supermarket which deals with many food
providers.
Each time the supermarket wants to buy a product it choose the best
price between all of these food providers.
So I was thinking that we could have a logical endpoint which is "food
provider" and dynamically we can bind this logical partner to a
physical partner which could be "Danone" or "Labeyrie".
What I understand from your previous email is that to do such a thing
I will have to deploy two service assemblies (one for Danone and one
for Labeyrie) and I will have to specify (WHEN ? HOW ?) the physical
partner I want to deal with ?
About the storage, I was thinking that there was a map somewhere
containing :
* the possible mapping for a logical endpoint : all food providers
* the current mapping for a logical endpoint : Danone for example
What I think now is that I will have to give my two providers two
different names as they provides the same service (food provider) and
I will have to select one between the two when calling the JMS binding
Component for example...
If I am right on this, can you please explain me how I can configure
dynamically the partner I want to call ? How can I move from one to
one other dynamically ?
Thanks alot for your answers,
Regards,
Charles
Guillaume Nodet wrote:
What do you mean exactly by logical and physical ?
Let's take the example of jms : when deploy a wsdl with the
appropriate binding information,
the endpoints can be either consumer endpoint or provider endpoint,
in the jbi meaning.
A consumer endpoint will receive requests from the external world and
route them in the NMR.
A provider endpoint will receive requests from the NMR and route them
to the external world.
For a provider endpoint, a jbi endpoint will be activated with a
service name and an endpoint name
retrieved from the wsdl. Binding informations are used to determine
the queue / topic to use.
For a consumer endpoint, informations will be retrieved and a jms
consumer will be created.
Currently, the exchanges are routed to the jbi endpoint defined by
the service name and endpoint
name defined in the wsdl. Binding informations are used to
determine the queue / topic to
listen to.
There is no global store of this informations : each binding
component is responsible for mapping
its own protocol specific endpoints to jbi endpoints. However all
jbi endpoints can be accessed
via the jbi api and the wsdl description can be retrieved for each
jbi endpoint.
Guillaume
Charles Souillard wrote:
Guillaume,
thanks for your quick answer !
Have you got any any idea for my last 2 questions concerning :
* The way used to do the mapping logical/physical endpoint ?
* And where this map is stored ?
Regards,
Charles
Guillaume Nodet wrote:
The new BC will behave as you say.
So this is true for
* servicemix-http
* servicemix-jms
Note that these components are not finished yet, but i am currently
working on it.
When you will deploy a service unit, it contains informations about
the endpoints to create,
either consumer endpoint or provider endpoint.
Depending on the deployment model you will use (wsdl or xml), the
information is extracted
and use to create endpoints.
Cheers,
Guillaume Nodet
Charles Souillard wrote:
Hi all,
I just want to be sure of something about BCs.
My understanding is that BCs are "generic". It means the JMS BC is
deployed into SM only once and then if we want to configure
different endpoints (each partner has its own queue/topic for
example) we only have to deploy (JBI deploy) new service
assemblies containing some artifacts...
Can you just confirm this understanding or tell me if I am wrong...
This question comes to me by thinking about JCA which is a special
case as each partner will have its own JCA connector I think,
isn't it ?
I have another question concerning endpoints. I just want to know
how the mapping is done between logical endpoints and physical
endpoints.
On the web site, I can read that UDDI is not yet supported so
where are stored these informations ?
Thanks,
Regards,
Charles
