[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] What Is A "Metaservice"?
as typical, +1 On Feb 10, 2006, at 12:26 PM, Frank McCabe wrote: > I personally see lots of potential for services about services. The > classic domain being service management. > However, I also fail to see why we need to do anything about it :) All > the pieces needed to support management and other similar meta cases > <duck/> is already there. > Frank > > On Feb 10, 2006, at 8:45 AM, Ken Laskey wrote: > >> The problem of metaservice as you've defined it is that you are >> assuming the underlying capability is only used to do something with >> another service. Now while that may be the only use that makes sense >> for a particular metaservice, in SOA we specifically do not make >> assumptions on who future users may be or the context in which they >> will find that service useful. Would we really get value out of >> arguing the conditions under which a service is a metaservice and >> when it is not? >> >> Ken >> >> >> On Feb 10, 2006, at 11:32 AM, Chiusano Joseph wrote: >> >>>> -----Original Message----- >>>> From: Rex Brooks [mailto:rexb@starbourne.com] >>>> Sent: Friday, February 10, 2006 11:10 AM >>>> To: Ken Laskey; Chiusano Joseph >>>> Cc: soa-rm@lists.oasis-open.org >>>> Subject: Re: [soa-rm] What Is A "Metaservice"? >>>> >>>> Why do we need a term for service metadata? >>> >>> Exactly. That was my motivation for suggesting a different definition >>> for "metaservice". >>> >>> Joe >>> >>> Joseph Chiusano >>> Associate >>> Booz Allen Hamilton >>> >>> 700 13th St. NW, Suite 1100 >>> Washington, DC 20005 >>> O: 202-508-6514 >>> C: 202-251-0731 >>> Visit us online@ http://www.boozallen.com >>> >>>> >>>> Rex >>>> >>>> >>>> At 9:55 AM -0500 2/10/06, Ken Laskey wrote: >>>>> I typically cause physical damage to people who say metadata >>>> is about >>>>> data. (OK, not really.) That is a circular definition that >>>> tells you >>>>> nothing. In our context, metadata is a subset of >>>> information related >>>>> to an entity, including parts of the entity, that are needed for a >>>>> particular purpose. That means metadata can also be descriptive >>>>> information about a service. The early SOA-RM drafts (I >>>> think 07 and >>>>> before) had an appendix on metadata >>>>> >>>>> As far as metaservice, the description of service supports a >>>> hierarchy >>>>> or combination of services, including services working with and on >>>>> other services. To have metaservice as a useful concept, you would >>>>> need a base level SERVICE and then things acting on it. The >>>>> identification of SERVICE will be use dependent and the source of >>>>> endless, fruitless arguments. >>>>> >>>>> Ken >>>>> >>>>> On Feb 10, 2006, at 8:34 AM, Chiusano Joseph wrote: >>>>> >>>>>> This may potentially be pertinent for our Reference >>>> Architecture work: >>>>>> >>>>>> In a recent entry[1] in his blog called "Focus on >>>> Repositories", David >>>>>> Linthicum mentions the term "metaservice". Quote (see end of >>>>>> [1]): >>>>>> >>>>>> "Since data about data is called metadata, I call data >>>> about services >>>>>> metaservices. A term we may be hearing more about in the >>>> future, and >>>>>> what will exist in these repositories." >>>>>> >>>>>> I differ with Dave on this, and see "metaservice" as being >>>> something >>>>>> different. Here's my comment on his blog: >>>>>> >>>>>> <Comment> >>>>>> On the following: "Since data about data is called metadata, I >>>>>> call >>>>>> data about services metaservices": >>>>>> >>>>>> Since metadata is "data about data", I wonder if a >>>> metaservice should >>>>>> really be considered a "service about services"? If so, what would >>>>>> that really mean? Perhaps it's a service that "sits above" >>>> a number of >>>>>> other services and provides, well, services about (or >>>>>> for?) those services that, upon invocation, returns various >>>>>> details >>>>>> about those services, or perhaps performs services upon the >>>> services >>>>>> themselves (such as aggregating them at design time). >>>>>> >>>>>> Just thinking out loud here... >>>>>> </Comment> >>>>>> >>>>>> Comments on my comment? >>>>>> >>>>>> Joe >>>>>> >>>>>> <http://blogs.ittoolbox.com/eai/cto/archives/007469.asp>[1] >>>>>> http://blogs.ittoolbox.com/eai/cto/archives/007469.asp >>>>>> >>>>>> Joseph Chiusano >>>>>> Associate >>>>>> Booz Allen Hamilton >>>>>> >>>>>> 700 13th St. NW, Suite 1100 >>>>>> Washington, DC 20005 >>>>>> O: 202-508-6514 >>>>>> C: 202-251-0731 >>>>>> Visit us online@ >>>>>> <http://www.boozallen.com/>http://www.boozallen.com >>>>>> >>>>>> >>>>> >>>>> --- >>>>> 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 >> >> >> > > ------------------------------------------------------------------------ ------------------ Ken Laskey MITRE Corporation, M/S H305 phone: 703-983-7934 7515 Colshire Drive fax: 703-983-1379 McLean VA 22102-7508
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]