Definitely interested. It's been a while since I've checked in on the ServiceMix project and the directions wrt OSGi look extremely promising.
On 8/24/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > > Any other people interested ? > > Cheers, > Guillaume Nodet > > On Aug 23, 2007, at 3:37 PM, Kit Plummer wrote: > > > I'd be up for a few chat sessions! > > > > On 8/23/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote: > >> > >> Btw, if there is sufficient interest, we could organize irc meetings > >> to discuss these topics and post the log to the dev list for > >> archiving > >> and later discussion. > >> > >> Cheers, > >> Guillaume Nodet > >> > >> On Aug 22, 2007, at 4:59 PM, Nodet Guillaume 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 > >>> * no more components > >>> * no more JBI packaging (just use OSGi bundles) > >>> * move the Channel to the Endpoint > >>> * use push delivery instead of pulling exchanges > >>> * introduce a single interface for identifying the Target of an > >>> Exchange > >>> > >>> 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 ?). > >>> In a non OSGI environment, the Endpoint will be registered in the > >>> Registry by calling the register method > >>> somehow. > >>> > >>> 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 :-) > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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. > >>> > >>> 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 ;-) > >>> > >>> Feedback welcome.... > >>> > >>> Cheers, > >>> Guillaume Nodet > >>> > >>> > >> > >> > >
