Well, the idea is not really to have a /new/ thing which is in addition to
our current service concept, it's to enable the current thing to support
multiple WSDL services... so calling it something like "ServiceGroup" or
"ServiceCollection" is, I think, a little weird for people who want to do
the simple case of just deploying a single service.
"AxisAssembly" isn't bad, but not perfect either. I still think "Component"
is better.
--Glen
----- Original Message -----
From: "Davanum Srinivas" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Anne Thomas Manes" <[EMAIL PROTECTED]>
Sent: Monday, July 18, 2005 3:06 PM
Subject: Re: [Axis2] CHANGE : Components vs. Services?
How about?
"Service Collection"
"Service Aggregate"
-- dims
PS: or "Service Mix" :)
On 7/18/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Anne:
I am fairly certain that JBI had nothing whatsoever to do with the "one
interface per service" decision in WSDL. Really. Though I definitely do
support that decision, I agree we shouldn't get into it here.
Regarding terminology, though - got any other suggestions?
--Glen
----- Original Message -----
From: "Anne Thomas Manes" <[EMAIL PROTECTED]>
To: <[email protected]>
Cc: "Srinath Perera" <[EMAIL PROTECTED]>
Sent: Monday, July 18, 2005 1:19 PM
Subject: Re: [Axis2] CHANGE : Components vs. Services?
My concern is that EJBs, JBs, JSPs, servlets, MDBs, etc. are
"components". "Services" are larger-grained applications that comprise
multiple "components".
Having recently spent the time to read the JBI spec, I kinda get the
impression that it's responsible for the bone-headed decision by the
WSDL 2.0 WG to establish what I view as an arbitrary and inappropriate
constraint that a service can implement only one interface. (A service
should implement at least three interfaces: its functional interface,
its metadata interface, and its management interface, and it's quite
reasonable for a service to implement multiple functional interfaces.
Somehow the "inheritance" argument [an interface can inherit multiple
interfaces] doesn't sit well with me. But I shouldn't rant about it
here...)
In any case, IBM and BEA have no plans to support JBI. Oracle is
clearly on the fence about JBI. IMNSHO, JBI as unnecessary overhead.
Therefore I don't think that JBI terminology should influence Axis
terminology.
Anne
On 7/17/05, Glen Daniels <[EMAIL PROTECTED]> wrote:
> 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
> > > >
> > >
> >
> >
>
>
--
Davanum Srinivas -http://blogs.cocoondev.org/dims/
