That's they way to do it. But HttpEndpoint delegates to ConsumerProcessor / ProviderProcessor, so you also need to write another processor for your endpoint.
Btw, Bruce suggested a while ago, that we should have several dedicated endpoints instead of having only one. We should be able to do that without breaking compatibility (I hope, else...) so we would have <http:consumer ... /> <http:provider .... /> <http:soap-consumer ... /> <http:soap-provider ... /> It may be easier to understand for users. Cheers, Guillaume Nodet On 7/26/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
What about extending the endpoint in the Service Unit? P On 7/26/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > On 7/26/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > > > > Actually that is a good point, I wonder whether we should depreciate > the > > HTTP bindings from the components then? > > > I think so. > I have tried hardly to push servicemix-http during the past monthes. > The only thing is that if you want some custom things, they are easier to > modify, as you > do not need to repackage the component. > > And I'll try and give you a hand on the documentation :) > > > Thanks > > Cheers, > Guillaume Nodet > > 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.xmlstart > > > 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.xmlto > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
