On Aug 22, 2007, at 11:43 PM, Bruce Snyder wrote:
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
As I explained in the other thread, I've been working on a new API
for ServiceMix 4.0.
Hopefully this will serve as an input for JBI 2.0.
This API is available at https://svn.apache.org/repos/asf/incubator/
servicemix/branches/servicemix-4.0/api
So here a few key changes:
* clean integration with OSGi
* the NormalizedMessage can contain not only XML
Nice!
* no more components
* no more JBI packaging (just use OSGi bundles)
* move the Channel to the Endpoint
* use push delivery instead of pulling exchanges
This is an interesting change for sure.
* introduce a single interface for identifying the Target of an
Exchange
How will this work? Can you explain this one a bit more?
Basically, instead of having different ways to express how the
exchange will be routed by the NMR
(using the endpoint, the service name or the interface name), there
would be only a single way to express
the destination using a Reference object (not Target, sorry). These
objects would represent either a specific
endpoint, or a service by its name or interface name, or more complex
policies that could be built.
These objects would be looked up in the Registry using a single
method. Depending on the metadata passed
to this method, you would retrieve an object that you can use as the
target.
Btw, for simple use cases, we should avoid needing a service QName +
endpoint name to uniquely identify
an endpoint. An unique ID should be sufficient. Everything else
should be optional.
Hopefuly you would not have to deal with that the lookup directly and
you would use spring beans factories
for that, so that you can easily inject References and use them as
target in your endpoints.
As we remove components, everything goes down to the endpoint which
become a key feature.
The endpoint must implement the Endpoint interface. In OSGi, the NMR
would listen to endpoints
registered in the OSGi registry and call the registry to register /
unregister the endpoints.
As part of the endpoint registration, the NMR would inject a Channel
into them, thus actually activating the
endpoint. I guess I could write a sequence diagram for that (anybody
knows a good tool for uml ?).
I've been trying to find some good UML software for a while -
something that doesn't cost an arm and a leg, that generates sequence
diagrams (IMO, these are invaluable!) from code and that runs on MacOS
X. Anyone know of something that meets this criteria?
In a non OSGI environment, the Endpoint will be registered in the
Registry by calling the register method
somehow.
Is there any interoperability between the OSGi registry and a UDDI
registry?
Not really. But i'm sure we could add that as an optional feature if
needed (but does anyone
really need to use a UDDI registry?)
OSGi registry contains services implementing a java interface with
some associated metadata,
while UDDI contains xml document (and mainly WSDL in our use case).
They can complement
together, but I'd really want to keep WSDL as completely optional.
The Endpoint receives Exchange to be processed on the process method.
I think we should keep the JBI 1.0 semantics and the endpoint use the
same process as for JBI 1.0, which is
send the exchange back using the Channel (with the response / fault /
error / done). This will put the threading,
transactions and security burden on the container itself. Which
means it is easier to write JBI apps :-)
This is exactly the architecture we need - a much cleaner separation.
Exchanges can be created using the Channel#createExchange method.
The only change I'd like to
integrate in the messaging API is to allow for non xml payloads and
maybe untyped attachments. The body
could be converted automatically to a given type if supported (I
think Camel does it nicely, so I'm thinking of
shamelessly copying the converter layer). I have added a few helper
methods on the exchanges and
messages (copy, copyFrom, ensureReReadable, display) to ease message
management.
Very nice, sounds similar to Spring convenience classes.
For the deployment part, there is no packaging anymore. One would
deploy an OSGi bundle that would
register the needed endpoints in the OSGi registry. For certain
types of endpoints, we may need an external
activation process (such as creating a server socket for listening to
HTTP requests) that may need to be shared
across endpoints of a given type. In such a case, you would deploy a
"component" that listens to new
endpoints implementing HttpEndpoint for example. When a new endpoint
is registered, the listener would
activate a server socket that could be shared across all http
endpoints. In a different way, if we have a BPEL
engine, the bpel "component" would listen for new bundles and look
for a specific file containing deployment
information. The component would register new endpoints in the OSGi
registry as needed (we could do that
for jaxws pojos using cxf for example).
So I said there is no more components, because this feature is not in
the api anymore, but we will certainly need
these components for some use cases. For simple endpoints, you
would not need any component at all.
Another benefit is that you can easily deploy a whole application
inside a single OSGi bundle. Using spring-osgi,
the bundle would just consist in a spring configuration file
containing the endpoints declaration and expose them
as OSGi services.
I'm not sure I understand this completely. Is this a type of
interceptor or am I misunderstanding you?
Well, somewhat yeah. OSGi defines several kind of calbacks that you
can register
in the OSGi framework. They can be called when a service is
registered / unregistered,
or when a bundle is started / stopped.
Of course, we need to write a JBI 1.0 compatibility layer, and we
could have an intermediate layer where SAs and
JBI components could be OSGi bundles directly, thus leveraging the
OSGi classloading mechanism.
Yep.
The thing I'm not completely sure about if the Target interface which
aims to identify the target of an exchange.
I'm thinking that some metadata are associated with endpoints (like
service name, interface name, wsdl
location, etc..). These metadatas could be used to retrieve targets
using the Registry. We could plug in different
mechanisms to query the metadata (simple lookup per id, policy based,
etc...). And the result itself could be
not only a single Endpoint, but could include some policies like:
load balance between all the endpoint implementing
the given interface, etc.... Also, I think Target should be injected
on Endpoints using spring, so you would look up a
targe using a spring bean factory (or multiple ones):
<smx:endpoint-target id="my-endoint-id" />
or
<smx:interface-target name="my:qname" />
The API is quite open right now, so any ideas welcome.
Very nice!
I think i covered the main areas of the API. The main goal is OSGi
and leveraging it as much as possible. There are
still some gray areas: what about the start/stop/shutdown lifecycle
which may be needed in some cases as I
discovered recently (when you want to gracefully shutdown a jms
consumer without loosing the ongoing messages
for example). I also want to give due credits to James, which has
been working with me on that.
Remember that nothing can't be changed and that' s why I'm asking for
feedback at this early stage, where there are
only ideas ;-)
Yes, the lifecycle is a must so that messages are not dropped. I know
that OSGi provides a lifecycle for bundles, how does this affect what
you mention above?
OSGi lifecycle only has two states (started / stopped) mainly (at
least for the
services). I think for some use cases, we would need three states
(started / stopped / shutdown) but I have no idea how to implement that.
Maybe going from start to stop should just be graceful enough to wait
for pending
exchanges. I will send an email to felix dev list to ask about that
at some point.
Guillaume
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL PROTECTED]&5R\"F)R=6-E+G-N>61E<D\!
G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
