OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [soa-rm] What Is A "Metaservice"?


Offline for a couple of days and I come back to this extraordinary
thread....hmmm

I'd move to close the thread...and take a shotgun to anyone who raises any
other marchitecture gimmicks around the word meta+anything...just a reasoned
opinion made on the basis of rapidly sampling some of the 30-odd postings...


Now can we start a discussion on ur-data and ur-services, please?

Our brains obviously need architexercise...

Peter

-----Original Message-----
From: Bashioum, Christopher D [mailto:cbashioum@mitre.org] 
Sent: 13 February 2006 22:44
To: Rex Brooks; Laskey, Ken; McGregor.Wesley@tbs-sct.gc.ca
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] What Is A "Metaservice"?

Excellent idea (and articulately stated).  So, whether or not the
re-definition is actually *useful* is not as important as the re-definition
being *not harmful* (i.e., keeping the weeds out of our garden ; )


-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Monday, February 13, 2006 3:57 PM
To: Laskey, Ken; McGregor.Wesley@tbs-sct.gc.ca; Bashioum, Christopher D
Cc: rexb@starbourne.com; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] What Is A "Metaservice"?

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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]