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 <[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
> >
> >
>
