On 7/26/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
I suppose there are compliations, and the embedding of SMX in App Server get around most of them, I suppose its just a case now of people understanding that the two models are different, and so the plan for current POJO components is to re-write them as Service Engines based on XBean so they can continue to be used in the embedded mode?
Agreed. FWIW, the servicemix-http is already a rewrite of the lightweight http components, so is servicemix-jms. Does the Service Engine archetype provide enough framework to ensure that
any component written using it as a base in embeddable? Should we look at provide guidelines for writing components from this basis?
The SE archetype is already embeddable. The junit test proves it :) We need to provide better documentation for sure. I need to finish http://servicemix.goopen.org/site/creating-a-standard-jbi-component.html Cheers, Guillaume Nodet P
On 7/26/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > It will be difficult to embed servicemix and use non embeddable > components. > (I guess it depends on what you mean by embed). > For example if you take the PXE component, it will require a full > installation step > so that it can create the embedded database (and thus require a file > system > directory > to store it). I think in this case, it would be easier to just start a > full > servicemix container > and put the components and assemblies in the install/deploy dir, where > they > would automatically be > installed. > > Cheers, > Guillaume Nodet > > On 7/26/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > > > > So in this case only Service Engines based on XBeans can be used in > > servicemix.xml, I suppose in my mind in the end SE's like the bpel and > > transformation would have been more likely to work out endpoints through > > provides/consumes metadata in jbi.xml and simple contain xslts and bpel > in > > the SU's not xbean.xml? > > > > Also if this is the case we should probably package the components (and > > dependencies) in a none-SE/SL form? > > > > P > > > > On 7/26/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > > > > All existing components can already be deployed in a > > > servicemix.xmlconfiguration file. > > > See for example > > > > > > > > > http://servicemix.goopen.org/site/servicemix-eip.html#servicemix-eip-UsingservicemixeipinaServiceMixxmlconfigurationfile > > > > > > The syntax is exactly the same (thanks to XBean). > > > So I don' t see any problems with the way it currently works, > > > but any opinion is welcome. > > > > > > You are right that there is no support for installing components and > > > deploying > > > SUs from the servicemix.xml configuration file, but I think that the > > > current > > > way > > > is easier to deal with. > > > > > > Cheers, > > > Guillaume Nodet > > > > > > On 7/26/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
