[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] What Is A "Metaservice"?
+2 At 12:30 PM -0500 2/10/06, Ken Laskey wrote: >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 -- 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]