I would much prefer a single "Service" that can be grouped in to another construct, "ServiceGroup" sounds like the right kind of thing to me.
I am not a fan of changing service to component, as I think this makes the 80% case much harder to understand when you come in cold to the system. I think it would be much better to have some sort of advanced construct that I can ignore unless and until I need it. -- Tom Jordahl Macromedia Server Development > -----Original Message----- > From: Venkat Reddy [mailto:[EMAIL PROTECTED] > Sent: Tuesday, July 19, 2005 9:15 AM > To: [email protected] > Subject: Re: [Axis2] CHANGE : Components vs. Services? > > "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 <[EMAIL PROTECTED]> wrote: > > 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/ > > > > > >
