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