[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] What Is A "Metaservice"?
Thanks Ken, Understood. I would be okay with metaservice combining metaservices as well as atomic services as long we clearly divorce it from service metadata. That's really the point I think we need to make. Regards, Rex At 5:05 PM -0500 2/13/06, Ken Laskey wrote: >Rex, > >I still cringe but I also appreciate your point. Couple points: > >1. Given there is some appreciation of the term metamodel, should we >try to align metaservice to have some consistency. Note, we are >trying to choose among misuses of meta-. > >2. In your definition, would a metaservice be limited to combining >atomic services or could it combine other metaservices? No, I do >not want to get to metametaservices :-) > >3. How soon would RA work need to define and otherwise name the >concept before we get overrun with the metaservice term? Do we need >to resurrect the sinkhole to collect rogue terms with which we may >have to deal? > >Ken > >At 03:56 PM 2/13/2006, Rex Brooks wrote: >>I think we already have the confusion, I'm sorry to say. >> >>At this point it has moved beyond being trivial and I am now >>hearing a couple of conflations of possible interpretations, and I >>think we are on the verge of doing ourselves multiple disservices. >> >>First, to reiterate my first comment on this, I don't think we need >>the term. We can already describe any amount of service metadata we >>want. However, this confusion highlights exactly what will happen >>in the minds of our public if we don't address it now that it has >>been turned into an issue of whether or not to take it seriously. >>That issue alone places it above the merely trivial and gives it >>enough weight that it is demanding out attention. >> >>The author who suggested it in the first place, was, in my opinion, >>already placing it in the weed patch with the other largely one-, >>two- or few-vendor hodgepodges of concepts currently being >>exploited under the moniker of SOA. Our effort to plant a neat, >>tidy garden has done quite well so far, and I would hate to see the >>weeds win, but we all live in the real world where a standard is >>only a standard if it is used widely. If the weeds win, we all get >>to play in their patch like it or not. So, coming to terms with >>something as imminently coinable and usable as metaservice is >>something we are faced with. Linguistically, I think it is >>unavoidable, so I suggest we pre-empt it. >> >>Since we don't need it for service metadata, perhaps we can use it >>for what it sounds like it should mean, provided we throw away the >>actual concept of what "meta" means. By that I mean defining >>metaservice a specific type of service that does nothing but >>describe combined atomic services as a type of "service" per se >>itself. >> >>I suggest that in order to divorce it totally and forever from the >>concept of service metadata. Of course, in this version of a >>metaservice, it would still be possible if not required for it to >>provide service metadata about itself. >> >>Regards, >>Rex >> >>At 3:07 PM -0500 2/13/06, Ken Laskey wrote: >>>Wes, >>> >>>My problem is we seem to have a term for which we are searching >>>for a meaning. We do better in making concepts clear (including >>>concepts beyond the RM) and then figuring out a descriptive name. >>>The term "metaservice" seems like confusion just begging to >>>happen, i.e. the name doesn't provide an unambiguous description >>>and our discussion points out possibilities but also doesn't know >>>which of the possibilities is needed and why. >>> >>>I dismiss out-of-hand the ambiguous creation of jargon, not in >>>developing understanding of (and naming) real problems. >>> >>>Ken >>> >>>At 02:45 PM 2/13/2006, McGregor.Wesley@tbs-sct.gc.ca wrote: >>>>Ken, >>>From a minimalist point of view your point is valid and the RM as >>>>it now stands reflects that. >>>> >>>>For those who manage large multi-business, multi-jurisdiction, >>>>multi-departmental, multi-lingual enterprises, there may be great >>>>value in having a "meta-service" in order to assist the >>>>classification of services and provide the level of abstraction >>>>needed to ease the building of a common framework. >>>> >>>>To out-of-hand dismiss the idea, is, to say the least, self-defeating. >>>> >>>>Regards, >>>> >>>>Wes >>>> >>>>P.S. Be careful of what you call worthless, what large SOA >>>>players are backing this RM? >>>> >>>> >>>> -----Original Message----- >>>>From: Ken Laskey [mailto:klaskey@mitre.org] >>>>Sent: February 13, 2006 2:23 PM >>>>To: Bashioum, Christopher D >>>>Cc: McGregor, Wesley; Rex Brooks; soa-rm@lists.oasis-open.org >>>>Subject: Re: [soa-rm] What Is A "Metaservice"? >>>> >>>> From an SOA standpoint, unless it is vital information that would >>>>somehow be made known through the service description, there is only a >>>>service and we neither know nor care whether it is atomic or meta. >>>> >>>>re another comment, I see no reason to generate a worthless definition >>>>just to beat someone else's worthless definition to the punch. >>>> >>>>Ken >>>> >>>>On Feb 13, 2006, at 11:00 AM, Bashioum, Christopher D wrote: >>>> >>>>> I just now read the actual blog, and I think Dave L. is right-on with >>>>> regard to the overall intent of better describing services in a >>>>> consistent way. In fact, I've been working on such a meta-description >>>>> for services for the DoD for a number of months now. My problem is >>>>> with the term. I made the following post to his blog >>>>> >>>>> <Post> >>>>> Agree with the article, but not the term metaservice. We are using the >>>>> term "service definition framework" for the added information used to >>>>> describe the services. >>>>> >>>>> I would submit that most of this additional information should exist >>>>> within the WSDL framework, most of it in the abstract portion. In >>>>> WSDL-2.0, it would generally be children of the Interface element. >>>>> >>>>> My problem with the term "metaservice" is that it sounds more like a >>>>> type of service (like a stock quote service, or a weather service). It >>>>> does not communicate what you are looking for. A better term might be >>>>> meta-description, or a meta-interface, or something like that >>>>> </Post> >>>>> >>>>> That being said, Joe's original comment to the SOA-RM list about a >>>>> metaservice being a "service about services" would also have another >>>>> name, depending on what it did. E.g., an aggregation service, an >>>>> orchestration service, etc. To call it a metaservice doesn't really >>>>> describe what it does. On the other hand, any service that uses other >>>>> services may be a "type" or "class" of service that uses other >>>>> services. In which case a service that is itself an aggregation of >>>>> other 'lower-level' services would be a metaservice. This might be >>>>> helpful in distinguishing between atomic services and metaservices. >>>>> >>>>> -----Original Message----- >>>>> From: Rex Brooks [mailto:rexb@starbourne.com] >>>>> Sent: Monday, February 13, 2006 10:39 AM >>>>> To: McGregor.Wesley@tbs-sct.gc.ca; soa-rm@lists.oasis-open.org >>>>> Subject: RE: [soa-rm] What Is A "Metaservice"? >>>>> >>>>> Good point Wes, >>>>> >>>>> Would it make an errata? Just to pre-empt the obvious. >>>>> >>>>> Regards, >>>>> Rex >>>>> >>>>> P.S. What would the equivalent be in a bus or a fabric? Can I build a >>>>> server for it? Does it do Windows? >>>>> >>>>> At 9:57 AM -0500 2/13/06, <McGregor.Wesley@tbs-sct.gc.ca> wrote: >>>>>> Hi Joe, >>>>>> >>>>>> The definition of "meta-service" would be dependent on the context >>>>>> in which it is used IMHO. >>>>>> >>>>>> I would note however that some company will define it soon, publish >>>>>> it, and that definition (even if erroneous) may be THE definition. >>>>>> >>>>>> To simply ignore the inevitable is to put our heads in the sand. >>>>>> >>>>>> A service about services seems logically equivalent to data about >>>>> data. >>>>>> >>>>>> Do we need to say more? >>>>>> >>>>>> Regards, >>>>>> >>>>>> Wes >>>>> >>>>> >>>>> -- >>>>> Rex Brooks >>>>> President, CEO >>>>> Starbourne Communications Design >>>>> GeoAddress: 1361-A Addison >>>>> Berkeley, CA 94702 >>>>> Tel: 510-849-2309 >>>>------------------------------------------------------------------------ >>>>------------------ >>>>Ken Laskey >>>>MITRE Corporation, M/S H305 phone: 703-983-7934 >>>>7515 Colshire Drive fax: 703-983-1379 >>>>McLean VA 22102-7508 >>> >>>-- >>>--------------------------------------------------------------------------------- >>> / Ken Laskey \ >>> | MITRE Corporation, M/S H305 phone: 703-983-7934 | >>> | 7515 Colshire Drive fax: 703-983-1379 | >>> \ McLean VA 22102-7508 / >>>---------------------------------------------------------------------------------- >> >> >>-- >>Rex Brooks >>President, CEO >>Starbourne Communications Design >>GeoAddress: 1361-A Addison >>Berkeley, CA 94702 >>Tel: 510-849-2309 > >-- > >--------------------------------------------------------------------------------- > / Ken Laskey >\ > | MITRE Corporation, M/S H305 phone: 703-983-7934 | > | 7515 Colshire Drive fax: 703-983-1379 | > \ McLean VA 22102-7508 / > >---------------------------------------------------------------------------------- -- Rex Brooks President, CEO Starbourne Communications Design GeoAddress: 1361-A Addison Berkeley, CA 94702 Tel: 510-849-2309
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]