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