You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Philip Dodds <ph...@gmail.com> on 2006/07/24 00:10:16 UTC
LWContainer, JSR181 (and the components?)
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
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/24/06, Philip Dodds <ph...@gmail.com> wrote:
>
> Yeah I know the spec speaks about SE and the business logic - though I
> tend
> to this that was meant in the context of BPEL and Business Process - I
> suppose the question becomes if i have an application that wants to expose
> functionality should that be a SE? SE's by the spec are meant to contain
> artifacts which in my mind would push them toward the concept of re-usable
> services (complex routing/transformation/process defintion). I'm just not
> convinced they suit a programming environment that people can use to make
> their application "ESB-able".
>
> While I might be a bit off the mark - I suppose I'm trying to look beyond
> the JBI spec at how we can make people using ServiceMix in their
> applications easier - and if I wanted to start developing an endpoint for
> my
> application I would imagine that I'm going to create a component that is
> going to include many of the library from my application and therefore I
> would be writing a Service Engine (according to the spec) but what if
> going
> to go in my Service Unit?
>
> I suppose it is a discusion on the user-cases for implementing :) I'm
> coming
> from a place where I think of SE's as re-usable services supplied by the
> IT
> department to service integration and therefore when the ESB touches upon
> an
> application in the enterprise I don't think of them writing a Service
> Engine
> to expose their accounting services, in an ESB model they would be
> exposing
> Endpoints that aren't really re-usable in a Service Assembly? I'm sure
> I'll
> be shouted down a bit for it, but I'm just thinking out loud on how
> ServiceMix gets implemented in a large scale SOA?
If you read the introduction in the JBI spec, from a user pov, there are
mainly two roles:
* JBI component developers
* JBI application developers
I really think these roles are not the same and may require different skill
sets.
As i said in another mail, the lightweight components / container is not the
best way to
think about JBI. I think that xslt, file, ftp, drools, groovy lightweight
components should be
reusable standard JBI components were you would deploy SU.
Given that, ServiceMix would ship with the a set of reusable components that
would cover most
of the basic needs. Thus, the main role to target imho is the JBI
application developer.
All routing, transformation and binding should be covered by existing
components and the developer
should just have to create the SUs (xslt stylesheet, routing definitions as
done in the EIP component),
http or jms bindings, and link them together in a SA.
Of course, there are cases where you won' t find an existing reusable JBI
component
to provide the feature you need. In such a case, you can choose to develop
a simple
lightweight component instead of trying to create a fully reusable SE.
This is where the lwcontainer comes into play, but again, i would prefer a
component
that would not rely on servicemix specific features (a la spring toolkit).
On the components note - I was thinking we turn both the lw-container and
> servicemix-components in shared libraries and then create a lw-container
> and
> lw-container-with-components projects that would simply reference both of
> these? I was hoping the parent first class loader delegate would get us
> around it?
This would not work, because the JVM will always load classes that are
referenced
directly from the same classloader. So if you put a lightweight component
in a SL,
the dependencies need to be in this classloader or the parent one(s).
Cheers,
Guillaume Nodet
Nothing like a Sunday night discussion :)
>
> P
>
> On 7/23/06, Guillaume Nodet <gn...@gmail.com> 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 <ph...@gmail.com> 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
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
Yeah I know the spec speaks about SE and the business logic - though I tend
to this that was meant in the context of BPEL and Business Process - I
suppose the question becomes if i have an application that wants to expose
functionality should that be a SE? SE's by the spec are meant to contain
artifacts which in my mind would push them toward the concept of re-usable
services (complex routing/transformation/process defintion). I'm just not
convinced they suit a programming environment that people can use to make
their application "ESB-able".
While I might be a bit off the mark - I suppose I'm trying to look beyond
the JBI spec at how we can make people using ServiceMix in their
applications easier - and if I wanted to start developing an endpoint for my
application I would imagine that I'm going to create a component that is
going to include many of the library from my application and therefore I
would be writing a Service Engine (according to the spec) but what if going
to go in my Service Unit?
I suppose it is a discusion on the user-cases for implementing :) I'm coming
from a place where I think of SE's as re-usable services supplied by the IT
department to service integration and therefore when the ESB touches upon an
application in the enterprise I don't think of them writing a Service Engine
to expose their accounting services, in an ESB model they would be exposing
Endpoints that aren't really re-usable in a Service Assembly? I'm sure I'll
be shouted down a bit for it, but I'm just thinking out loud on how
ServiceMix gets implemented in a large scale SOA?
On the components note - I was thinking we turn both the lw-container and
servicemix-components in shared libraries and then create a lw-container and
lw-container-with-components projects that would simply reference both of
these? I was hoping the parent first class loader delegate would get us
around it?
Nothing like a Sunday night discussion :)
P
On 7/23/06, Guillaume Nodet <gn...@gmail.com> 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 <ph...@gmail.com> 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
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
I like the idea of being able to have more read-able endpoint elements in
the xbean XML :)
P
On 7/26/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> 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 <ph...@gmail.com> wrote:
> >
> > What about extending the endpoint in the Service Unit?
> >
> > P
> >
> > On 7/26/06, Guillaume Nodet <gn...@gmail.com> wrote:
> > >
> > > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > >
> > > > > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > > > > > > >
> > > > > > > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com>
> 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 <gn...@gmail.com>
> 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 <gn...@gmail.com>
> > 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 <ph...@gmail.com>
> > > > > 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
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ph...@gmail.com> wrote:
>
> What about extending the endpoint in the Service Unit?
>
> P
>
> On 7/26/06, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > >
> > > > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com>
> 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 <philip.dodds@gmail.com >
> > > > 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
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
What about extending the endpoint in the Service Unit?
P
On 7/26/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > >
> > > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com >
> > > 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
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> >
> > On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > > > >
> > > > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com >
> > 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
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
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 <gn...@gmail.com> wrote:
>
> On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > > >
> > > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com >
> 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
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/26/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > > >
> > > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
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?
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?
P
On 7/26/06, Guillaume Nodet <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > > >
> > > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ph...@gmail.com> 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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > > >
> > > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
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 <gn...@gmail.com> 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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> > >
> > > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ph...@gmail.com> 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 <gn...@gmail.com> wrote:
> >
> > On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
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 <gn...@gmail.com> wrote:
>
> On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > > >
> > > > >
> > > >
> > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
On 7/24/06, Philip Dodds <ph...@gmail.com> 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 <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > > >
> > > >
> > >
> >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Philip Dodds <ph...@gmail.com>.
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 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?
P
On 7/23/06, Guillaume Nodet <gn...@gmail.com> 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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> > >
> > >
> >
>
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <gn...@gmail.com> 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 <philip.dodds@gmail.com > 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
> >
> >
>
Re: LWContainer, JSR181 (and the components?)
Posted by Guillaume Nodet <gn...@gmail.com>.
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 <ph...@gmail.com> 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
>
>