With these new Container Service Engines approach how will people working in a servicemix.xml world use them? will the servicemix.xml start to include the ability to deploy exploded su's
Like: <sm:container id="jbi" rootDir="./data/smx" MBeanServer="#mbeanServer" installationDirPath="./install" deploymentDirPath="./deploy" dumpStats="true" statsInterval="10" flowName="seda" transactionManager="#transactionManager" workManager="#workManager" depends-on="jndi"> <sm:installComponent location="classpath:myComponent.jar"/> <sm:deployServiceUnit location="classpath:/firstSU"/> </sm:container> Since otherwise if we start to migrate away from POJO components to proper Service Engines (such as the obvious introduction of a Transformation Service Engine) how can people embedding ServiceMix use these engines and manage their deployment? I think its worth talking this through now - since I really would like to try and build a mental image of how smx migrates into a cleaner separtion of core functionality, and also makes adding components to a product/ESB or SOA simple. P On 7/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
On 7/24/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > > Its a good point - though I think a lot of people at attaching themselves > to > the lw-container as the de-facto mechanism for developing JBI components, > we should probably start trying to break down what they want to achieve > and > offer up some better SE's in that case. Maybe an EJB3 SE would allow > people > to see that they can house their application logic in a good development > container and still reference it from JBI. I was thinking of embedding PitchFork ( http://www.interface21.com/pitchfork) in the jsr181 component, which would provide a non persistent ejb3 container. I was also thinking on creating a wsdl / jbi binding annotation set to be able to map jbi properties or attachments to arguments on a method call. If you want to access a real EJB, you can still use the jsr181 component and leverage spring proxy features to expose an existing EJB as a JBI endpoint. Another recent addition is the jsr181 proxy that can be used to request another endpoint using a java proxy (provided that the endpoint has a wsdl description and that you have a matching java interface). On the POJO side, we also have the SCA component (that needs to be finished and documented). I had some chat with the tuscany guys about that at Apachecon in Dublin. I see your point on the Container of Containers, I suppose its how that > breaks into physical implementation that is still vague, and while JSR181 > is a good way of exposing the metadata I suppose it isn't a good > development > container. And I still feel that we are going to need to look at how we > can > extend the handing of common SE Container logic (ie. classpaths for SU's > etc). > > I think we need to visit how we can start creating a cleaner understanding > of the components - and it might be time to state that we see the POJO > components are first generation and not the future - and quickly provide a > replacement POJO deployment model so that people can get into JBI with > POJO's without picking up the lw-container? Agreed. But this is mainly a problem of documentation, which is obvisouly not my main skill :( I think we nearly have the POJO deployment model with the jsr181, but we need (maybe another component) more jbi specific features (time to revive/rewrite the Spring Client Toolkit somehow). Cheers, Guillaume Nodet P > > On 7/23/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > Note that the lwcontainer' s only purpose is to be able to deploy > existing > > lightweight > > components. It relies on servicemix specific features, whereas other > > components > > are not specifically tied to ServiceMix. > > I' d really like to get rid of that in a very very long term. > > * implement existing lw components (xslt, ftp, drools, groovy, ...) as > > standard JBI components > > * create a simpler programming model (maybe like the old spring client > > toolkit) or > > enhance the jsr181 component . > > > > Recall that a JBI container is a "container of containers". JBI > > components > > are not so easy > > to write (if you want it to be reusable) and when possible, all JBI > > related > > features should be hidden by SE > > when you want to develop a service. That' s what the jsr181 component > or > > a > > BPEL engine SE do: you just > > deploy a service unit (pojo, xslt, bpel, ...) in a container (the > > component) > > to activate a service. > > > > > > Cheers, > > Guillaume Nodet > > > > On 7/24/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > Quoting the JBI spec: > > > "SEs are the business logic drivers of the JBI system." > > > "BCs are used to send and receive messages via particular protocols > and > > > transports." > > > > > > Let's talk about the jsr181 component. I think the definition for BCs > > > clearly indicates > > > that the jsr181 component is not a BC, so I think it must be a SE ;) > > > The fact that you deploy some java code on it is just a side point: > each > > > JBI component > > > has its own deployment model for service units and I would not > consider > > a > > > java class > > > on a different level than a BPEL process. If you do not want to deal > > with > > > classpath issues, > > > we could add a default classpath location of "." to the SU if nothing > is > > > specified. > > > And I do think that the service deployed on the jsr181 component > > contains > > > the business logic > > > in the same way a BPEL process do. > > > > > > The lwcontainer is a bit of a problem. If possible, i would not > > > categorize it as a BC or SE. > > > Actually, the lwcontainer will never send or receive exchange > > itself. The > > > only operation performed > > > is to start / stop lightweight components (which can be BCs or SEs). > > > > > > For the shared-library part, it would be cool to put lightweight > > > components in a shared library. > > > However, due to classloader considerations, this shared library would > > need > > > to contain all the > > > dependencies of all lightweight components, and that would make a very > > big > > > SL (in tens of MBs). > > > WE could also put all these dependencies in the lwcontainer, but the > > > problem would be the same. > > > I' m not very keen on having a 30 Mb component just to use a > lightweight > > > component i would have > > > created on my own. > > > > > > Btw, SL can not really be used when embedding servicemix -- or you use > > the > > > full JBI feature set > > > (component installation, SU deployment, etc) and it is not really > > embedded > > > anymore ;) > > > > > > Feel free to argue :) > > > > > > Cheers, > > > Guillaume Nodet > > > > > > > > > On 7/24/06, Philip Dodds <[EMAIL PROTECTED] > wrote: > > > > > > > > I have been working through the lw-container, JSR181 and wanted to > > share > > > > some thoughts on these service engines. > > > > > > > > I'm wondering whether then should be service engines, since they > each > > > > require a additions to the classpath I'm wondering if they shouldn't > > be > > > > Binding Component Archetypes. I suppose the question becomes one on > > how > > > > > > > > best to define the JBI spec. > > > > > > > > Here is the logic for my argument: > > > > > > > > If a binding component is meant to broker some interaction with an > > > > external > > > > system then the JSR-181 and lw-container are most likey doing > > that. If > > > > I > > > > can presenting a service interface to the ESB for business logic > (most > > > > common usecase in the JSR181) then I would have thought I was a > > binding > > > > component. In a binding component we would be able to handle > > additions > > > > to > > > > the classpath through the JBI descriptor, while in the Service > Units > > > > this > > > > is don't outside of JBI. > > > > > > > > I'm thinking that the lw-container and jsr-181 se could be better > > places > > > > as > > > > shared libraries that archetypes use - such that you can create an > > > > archetype > > > > (even add classes to the dependencies) and still have the > > functionality. > > > > > > > > This leads into the ServiceMix components and LW-Container - I'm > > > > wondering > > > > whether servicemix-components would be better off being a Shared > > > > Library, > > > > then you could create a binding component based on the lightweight > > > > component > > > > shared library and the servicemix components shared library and > > > > hopefully > > > > the class path would be resolved. The only problem I see here is > that > > > > if > > > > you are working in a servicemix embedded model you might need to be > > able > > > > to > > > > reference shared libraries in your servicemix.xml to force them to > > load > > > > in > > > > there so that the packaging can be consistent. > > > > > > > > I realize this is all large scale changes but I wanted to throw them > > out > > > > > > > > there to see what people think? > > > > > > > > Cheers > > > > > > > > P > > > > > > > > > > > > > > > > >