Mailing-List: contact axis-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: axis-dev@ws.apache.org
Received-SPF: pass (asf.osuosl.org: domain of vreddyp@gmail.com designates
 64.233.170.206 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=t0ppk4UhsigSy263zgGL8X3xyyxZxlhrT1okbcjT/tvCpuLRFih2e0VWoFpoR1RPijfBvCg01/VshVXCq4lurhUHd7kVAy1GSFkLJiAI3CYLF4fHZMwYztyX2qNMiWKZo1ZiPRmTkM2SeuTyN6H8/+OsqYQXKXORh7nQ8mJKb38=
Message-ID: <fadf663105071906151eabdbce@mail.gmail.com>
Date: Tue, 19 Jul 2005 18:45:10 +0530
From: Venkat Reddy <vreddyp@gmail.com>
Reply-To: Venkat Reddy <vreddyp@gmail.com>
To: axis-dev@ws.apache.org
Subject: Re: [Axis2] CHANGE : Components vs. Services?
In-Reply-To: <041801c58c61$72af88f0$0400a8c0@MicroMe>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: 
 <80A43FC052CE3949A327527DCD5D6B2701297AA3@MAIL01.bedford.progress.com>
	 <f8de7ee0507160817280a4187@mail.gmail.com>
	 <1121566491.20054.28.camel@localhost.localdomain>
	 <bf414ee605071718591f67bd4a@mail.gmail.com>
	 <00f201c58b44$05afc710$0400a8c0@MicroMe>
	 <bf414ee6050718101944ff40c@mail.gmail.com>
	 <032d01c58bcb$1da212b0$0400a8c0@MicroMe>
	 <19e0530f050718120654c7f455@mail.gmail.com>
	 <041801c58c61$72af88f0$0400a8c0@MicroMe>

"Component" seems to be alright for me to mean something which offers
one or more services. Remember COM components, which were
QueryInterface'd to see if they spoke a specific language (or
interface) and get connected to the right interface :-)

As an analogy, the fact that a java component (class) can implement
multiple interfaces, and if we see each interface as a separate
service, then the component is of larger granularity than a service /
interface. I agree that we are running out of popular dictionary
words, and "component" is also used to mean bits and pieces that
implement a business functionality such as EJBs, JSPs, which is fine
too :-)

- venkat

On 7/19/05, Glen Daniels <glen@thoughtcraft.com> wrote:
> Well, the idea is not really to have a /new/ thing which is in addition t=
o
> 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.
>=20
> "AxisAssembly" isn't bad, but not perfect either.  I still think "Compone=
nt"
> is better.
>=20
> --Glen
>=20
> ----- Original Message -----
> From: "Davanum Srinivas" <davanum@gmail.com>
> To: <axis-dev@ws.apache.org>
> Cc: "Anne Thomas Manes" <atmanes@gmail.com>
> Sent: Monday, July 18, 2005 3:06 PM
> Subject: Re: [Axis2] CHANGE : Components vs. Services?
>=20
>=20
> How about?
>=20
> "Service Collection"
> "Service Aggregate"
>=20
> -- dims
>=20
> PS: or "Service Mix" :)
>=20
> On 7/18/05, Glen Daniels <glen@thoughtcraft.com> 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" <atmanes@gmail.com>
> > To: <axis-dev@ws.apache.org>
> > Cc: "Srinath Perera" <hemapani@gmail.com>
> > 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 <glen@thoughtcraft.com> 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" =3D=3D WSDL 2.0 service).
> > >
> > > JBI calls something like this thing a "component" (the larger class o=
f
> > > 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 el=
se
> > > (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" <atmanes@gmail.com>
> > > To: <axis-dev@ws.apache.org>
> > > Cc: "Srinath Perera" <hemapani@gmail.com>
> > > 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 <sanjiva@opensource.lk> wrote:
> > > > I have a longer reply coming but a definite -1 to doing anything th=
is
> > > > 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 <gdaniels@sonicsoftware.com> wrote:
> > > > > >
> > > > > > Axis2'ers:
> > > > > >
> > > > > > I've been thinking recently about a couple of things with respe=
ct
> > > > > > to
> > > > > > Axis2.  First of all, the idea that we might want to support so=
me
> > > > > > concept of "service groups" - a bunch of individual services wh=
ich
> > > > > > 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 wh=
ich
> > > > > > can
> > > > > > each provide multiple services.
> > > > > >
> > > > > > What about changing our model slightly to enable "components" t=
o
> > > > > > 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
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>=20
>=20
> --
> Davanum Srinivas -http://blogs.cocoondev.org/dims/
>=20
>=20
>