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


Its is an interesting dicsussion wether a message is part of a RM or not.

If one want to create, send receive, listen, save etc then what is to be 
operated on if some container of information is not part of the RM?  
There seem to a need to for some basic key concepts if one want to build 
higher level (semantically enriched) constructs. A RM could benefit from 
being mappable, extended, made concrete, made detailed etc.

/anders


/anders

Ken Laskey wrote:

> I have not yet gone through the rest of this thread (and several  
> others) but it seems that while the message itself is not part of the  
> RM, the ability to create, transport, receive, and possibly  
> save/archive the message is part of the RM.  Can we conceive of an 
> SOA  without messages?  Consider the message exchange patterns (MEPs) 
> that  are part of WSDL 2.0 for the types of message patterns people 
> imagine.   Do we think these are accurate?  How does the RM 
> acknowledge these?
>
> Ken
>
>
> On Mar 30, 2005, at 7:32 PM, Duane Nickull wrote:
>
>> 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
>> ***********
>>
>>
> ------------------------------------------------------------------------ 
> ------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-883-7934
> 7515 Colshire Drive                        fax:        703-883-1379
> McLean VA 22102-7508
>
>
>


-- 

Best Regards
/Anders

////////////////////////////
/ Anders W. Tell           /
/ Financial Toolsmiths AB  /
/ <anderst@toolsmiths.se>  /
////////////////////////////

-----------------------------------------------------------------------
CONFIDENTIALITY AND DISCLAIMER NOTICE

 This e-mail in its entirety, including any associated files, are 
confidential and intended only for the addressee named above. 
If you are not the intended recipient or the person responsible for 
delivering to the intended recipient, be advised that you have received
this email in error and that any use of the information contained 
within this email or attachments is strictly prohibited.

 The contents should not be disclosed to any other person nor copies 
taken. Any views or opinions presented are solely those of the sender 
and do not necessarily represent those of Toolsmiths unless otherwise 
specifically stated.

 As internet communications are not secure we do not accept legal 
responsibility for the contents of this message nor responsibility for
any change made to this message after it was sent by the original 
sender. 

We advise you to carry out your own virus check before opening any 
attachment as we cannot accept liability for any indirect or 
consequential damages sustained as a result of any software viruses. 
If you have received this email in error, or if you are concerned with
the content of this email please notify Toolsmiths by sending e-mail 
to us at: info@toolsmiths.se.
-----------------------------------------------------------------------





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