Thanks Guillaume for your answers. A few more comments in-line.
Guillaume Nodet wrote:
First, I assume all components must handle the message exchange
pattern defined by the service type (e.g. one-way, request-response,
...). Otherwise, I don't think the exchange could be carried out
successfully.
Yes. Note that such limitations could be expressed by the component by
using the isExchangeWithProviderOk and isExchangeWithConsumerOk
methods. But these methods are only called by the NMR and can not be
accessed by another component (the router). If such information may be
usefull to you, please raise a JIRA.
Understood. I don't have a need for this right now.
Now, is it a requirement of the JBI spec that MyRouter expose
SameInterface on the JBI bus using ComponentContext#activateEndpoint
and subsequently Component#getServiceDescription? If so, does
ServiceMix require this as well?
The JBI spec, in 5.5.2.2, says: " the component MUST supply service
metadata concerning services it provides in its implementation of the
getServiceDescription(ServiceEndpoint) method ". ServiceMix does not
require such information, but if provided uses the wsdl to retrieve the
interfaces implemented by the endpoint. Note that ServiceMix can only
handle WSDL 1 documents. We are planning to use Apache Woden in the
future to parse and use wsdl 2 documents.
Ok, that clarifies it. I'm looking forward to WSDL 2 support for my
Axis2 binding component. More on this later since I don't know if it's
going to be a strict requirement.
I'm going to go out on a limb now and say that MyConsumer cannot be
(deterministically) linked to MyRouter by relying on service type
routing because we have more than one component exposing
SameInterface. Thus, MyConsumer must specify MyRouter's fully
qualified service endpoint name. Is this right?
Depending on how you design your components, you could also use the
service name, without the full endpoint, provided that each of your
component have a different service name. But using the ServiceEndpoint
is the only way to be sure about the target endpoint. Note that if your
router want to access the list of activated endpoints dynamically (with
the JBI API methods) it will receive a list of ServiceEndpoint.
That's also good to know. I was not clear whether the routing could
happen with the service name alone, or if a full service endpoint was
required. Service name alone works as well (but may resolve to multiple
endpoints).
Based on section 5.4.3.3 of the JBI specification, the service
endpoint name can be a hard link, a soft link or a standard link as
determined by in the service unit's meta-data. I guess the choice
between those is a deployment preference. I'd be curious to hear from
people who have experience about which approach work best for them.
This is a not well tested area of ServiceMix. Maybe someone has already
used that, but I am not sure.
Alright, I'll thread carefully.
I'll assume MyRouter is driven by some sort of business policy, such
as content-based routing. For example, the policy could be "route all
transactions under $1000 to ServiceA and those equal or over $1000 to
ServiceB." MyRouter must therefore be configured with rules and with
service endpoint names of ServiceA, ServiceB, etc.
Once again, is it a requirement of the JBI spec that service provider
components (ServiceA, ServiceB, ...) expose SameInterface on the JBI
bus? And if so, does ServiceMix enforce this?
I am not sure of what you are saying: I do not see how ServiceMix (or
any other JBI container) can know that two endpoints should expose the
same interface. The JBI spec says that each endpoint should have a wsdl
description, but this description is given by the component. If your
endpoints do not implement the same interface, then routing will behave
according to this fact.
You answered my question above. I wanted to know if ServiceA and
ServiceB needed to implement getServiceDescription(ServiceEndpoint) and
they do.
Another question I have is whether it would be advantageous to hook a
policy at the NMR level instead of having a routing component on the
JBI bus.
The pros of using a policy are imho,
* you do not have to worry about selecting the possible endpoints : you
can leverage interface based routing and the use of isExchangeWithXXXOk
methods (if your components implements them)
* easy to write
Cons:
* ServiceMix specific
* unmanageable (installation / deployment / stats ...)
The last point is imho the one that makes me think, that if the policy
becomes involves business rules, it may be better to use a router. This
may be argued, especially if the rules are not hard-coded, but stored
externally.
Good points. I'll try the component-based router approach and see how
it goes.
thanks again!
alex
