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] Groups - Rough notes taken during the last ebSOA meeting. (ebSOA-Elements.pdf) uploaded


I agree that Data Model may be an ill-advised term because it is too  
easy to connect it with aspects of the service that are hidden from  
users and thus of no immediate consequence to the SOA.  I think what we  
are talking about might be better described as  the external interface  
definition.

As to semantics, I believe it is crucial that we include that a  
mechanism MUST exist to indicate the semantics, otherwise it is  
impossible to really use a service you have discovered for the first  
time.  Concepts in namespaces, tModels, and OWL-S may be useful here.

To go further, I'd suggest the service description be liberally defined  
to be *everything* (and, at the moment, I think I do mean everything) a  
prospective user could need to access to determine (1) if the service  
is of use (including whether the terms of use are acceptable) and (2)  
if useful, how to use.  Conversely, the user description should include  
everything the service needs to access to determine whether the user is  
authorized to use the service.

The question would then be what constructs are necessary in an SOA to  
support these "capabilities".

Ken

On Mar 31, 2005, at 9:44 AM, Rex Brooks wrote:

> Data Models do include the notion of Semantics inherently, but as Joe  
> points out, it seems out of scope for this RM. However, we do need to  
> consider Semantic concerns for how we define and classify, if we  
> classify, Services.
>
> Ciao,
> Rex
>
> At 7:39 AM -0500 3/31/05, Chiusano Joseph wrote:
>> <Quote>
>> An open ended question is "does the data model
>> include the notion of semantics?".  I would like to hear comments back
>> on this matter.
>> </Quote>
>>
>> I wonder if the answer to this question has any bearing on our RM, or  
>> if
>> it is out of scope no matter what the answer is?
>> Kind Regards,
>> Joseph Chiusano
>> Booz Allen Hamilton
>> Visit us online@ http://www.boozallen.com
>>
>>
>>>  -----Original Message-----
>>>  From: Duane Nickull [mailto:dnickull@adobe.com]
>>>  Sent: Wednesday, March 30, 2005 7:33 PM
>>>  To: Metz Rebekah
>>>  Cc: soa-rm@lists.oasis-open.org
>>>  Subject: Re: [soa-rm] Groups - Rough notes taken during the
>>>  last ebSOA meeting. (ebSOA-Elements.pdf) uploaded
>>>
>>>  Hi Rebekah:
>>>
>>>  Some comments inline:
>>>
>>>  Metz Rebekah wrote:
>>>
>>>  >All -
>>>  >
>>>  >I have another 25 messages to go before I catch up with all
>>>  the traffic
>>>  >on the list, so I apologize if my comments are already outdated.
>>>  >
>>>  I would recommend reading Thomas's elegant summary - it may
>>>  save you some time ;-)
>>>
>>>
>>>  >Respecting the service description, contract, and data model from
>>>  >Duane's message - does you think that "all aspects of the service"
>>>  >encompasses the service interface and the policy?  I like
>>>  the use of the
>>>  >term service contract, but have seen several interpretations
>>>  of the term
>>>  >ranging from semantics ("what is meant") to syntax (vis a
>>>  vis the WSDL)
>>>  >and also that the WSDL is the data model is the contract.  I
>>>  would argue
>>>  >that the contract is the same as the data model.  However,
>>>  I'd have to
>>>  >think a bit more to provide a convincing argument rather than  
>>> simply
>>>  >positing an idea.
>>>  >  >
>>>  The data model is the abstract concept of what data you will
>>>  pass in and
>>>  out of a service.  An open ended question is "does the data model
>>>  include the notion of semantics?".  I would like to hear
>>>  comments back
>>>  on this matter.
>>>
>>>  >Continuing into the message, I would disagree with the following:
>>>  >  >
>>>  >>If I build something and that is "Service Oriented"
>>>  >>architecturally, does it have to have a "message"?  No - the
>>>  >>service itself has a mechanism that allows a service consumer
>>>  >>to bind to it to invoke the service but it doesn't actually
>>>  >>have to be invoked for it to be "service oriented
>>>  >>architecture".  >>    >>
>>>  >
>>>  >I would argue that conceptually, a message exists.  <SNIP>
>>>  >
>>>
>>>  Try to think abstract.  If you think concrete - then the
>>>  answer is yes,
>>>  however the reference model is not concrete.  No other
>>>  reference models
>>>  use messages by convention either.  If you find one that is well
>>>  scrutinized and accepted by peers, please let me know.
>>>
>>>  >The mechanism by
>>>  >which the consumer binds to the service and invokes it
>>>  constitutes the
>>>  >message.
>>>  >
>>>  Conceptually - yes.  The "service" element of the SOA RM draft on  
>>> the
>>>  position paper includes the concept of a binding.  A physical  
>>> message
>>>  does not have to be sent.  When using the RM to write a concrete SO
>>>  infrastructure architecture, one would recognize that a
>>>  message protocol
>>>  would likely be needed to be specified, along with several
>>>  other items
>>>  like security, potentially some sort of state management
>>>  (like BPM), etc
>>>  etc.
>>>
>>>  I hope this helps a bit.
>>>
>>>  Duane
>>>
>>>  --
>>>  ***********
>>>  Senior Standards Strategist - Adobe Systems, Inc. -
>>>  http://www.adobe.com
>>>  Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>>>  Adobe Enterprise Developer Resources  -
>>>  http://www.adobe.com/enterprise/developer/main.html
>>>  ***********
>>  >
>>>
>
>
> --  
> 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-883-7934
7515 Colshire Drive                        fax:        703-883-1379
McLean VA 22102-7508




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