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? > 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? > 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? > 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? 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/