Hi Anne:
The idea here is that a "foo" is a deployment unit which a) shares
classloaders, b) is packaged as a single thing, and c) implements 1..N
services (where "service" == WSDL 2.0 service).
JBI calls something like this thing a "component" (the larger class of which
SE's and BC's are subtypes). I don't see why it's particularly
non-intuitive to call it that.
I'm not stuck on the name at all, and would be fine with something else (got
any suggestions?), but I do think the concept that one .aar might implement
multiple WSDL services is something we should integrate (pre-1.0).
--Glen
----- Original Message -----
From: "Anne Thomas Manes" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Srinath Perera" <[EMAIL PROTECTED]>
Sent: Sunday, July 17, 2005 9:59 PM
Subject: Re: [Axis2] CHANGE : Components vs. Services?
Who came up with the concept that a "component" is of larger
granularity than a "service"? that terminology is just remarkably
non-intuitive!
Anne
On 7/16/05, Sanjiva Weerawarana <[EMAIL PROTECTED]> wrote:
I have a longer reply coming but a definite -1 to doing anything this
drastic before 1.0.
I'll explain further when I write my detailed response .. apologies for
the two-stage note :(.
Sanjiva.
On Sat, 2005-07-16 at 21:17 +0600, Srinath Perera wrote:
> Hi Glen;
>
> I think the basic idea is to widen the scope of a componenet! and
> replace service archive with a componenet archive. This allowed number
> of services to share a same class loader.
>
> mm .. seems ok to me (may be need to think bit more before commit my
> self :) ).
> Thanks
> Srinath
>
> On 7/16/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> >
> > Axis2'ers:
> >
> > I've been thinking recently about a couple of things with respect to
> > Axis2. First of all, the idea that we might want to support some
> > concept of "service groups" - a bunch of individual services which are
> > related somehow (via state, implemented with the same code, etc).
> > Second of all, I'm thinking of building a JBI implementation on top of
> > Axis2, and JBI's notion of "components" are deployable units which can
> > each provide multiple services.
> >
> > What about changing our model slightly to enable "components" to
> > implement more than one Web Service? This would entail, I believe:
> >
> > * Change axis/services to axis/components (just for clarity)
> >
> > * Add a "ComponentContext" level to the context stack between
> > ServiceContext and ConfigurationContext
> >
> > * Components would be "engage()"d just like services (although looking
> > at the code I don't see this for services yet... need to dig around
> > more)
> >
> > * component.xml (replacement for service.xml) would contain 1..N
> > <service> elements each of which looks like the current service.xml,
> > so
> > the minimal one-service file would be
> > <component><service>...</service></component>. We could allow
> > optimizing this to just <service> at the top level too!
> >
> > Thoughts?
> >
> > Thanks,
> > --Glen
> >
>
