Actually that is a good point, I wonder whether we should depreciate the HTTP bindings from the components then?
And I'll try and give you a hand on the documentation :) P On 7/26/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:
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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
