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] Proposed Response for #1


Hi Jyoti:

 

Thank you again for taking the minutes this meeting.  It is much appreciated!

 

Here are the participants as I recorded them:

 

Michael Stieffel

Duane Nickull

Ken Laskey

David Ellis

Danny Thornton

Don Flinn

Bob Ellinger

Jeff Estefan

Gregory Kohring

Tom Merckle

Kathryn Breninger

Joe Chiusano

Yourself

Frank McCabe

 

The exact text for the three comments are:

 

Comment #1:

 

The next section 3.2.2.2 of the RM discusses behavior models and the roles these play.  It is beyond the scope of the RM to expand on the specifics of “formal description”.

 

Also please note the section on Service Description (section 3.3.1) goes into further detail to provide clarification.

 

Comment #2:

 

1. The TC agrees regarding the importance of policy and the RM includes numerous mentions of policy and an in depth discussion in section 3.3.2.  While an SOA policy reference model may be of value, it is beyond the scope of the current effort.

 

 

 

2. This TC recognizes that there are several other organizations that are developing standards, specifications around the concept of policy.  We would like to forward this comment to them for their consideration to include some form of reference model in their work.  We will forward this comment to various WS groups and the W3C who are working on the issue.

 

 

 

3. The subcommittee working on our Reference Architecture for SOA will also likely provide further clarification on the concept of policy with respect to SOA in their work.

 

Comments #3:

 

As noted in section 1.3, the RM is intended to assist a wide audience, and that also implies a wide range of background.  In some of the introductory sections, the TC tries to not only provide perspective but to answer recurring questions about SOA and its relationship to well known paradigms.  The discussion of OO is one example of such a relationship.  Unfortunately, it is impossible to include sufficient background material for every referenced technology.  Section 3 of the RM provides the main body of the description of SOA and does not require an in depth knowledge of other paradigms discussed in the preceding sections.

 

 

 

We also note in the abstract section on the first pages that “While service-orientation may be a popular concept found in a broad variety of

 

applications, this reference model focuses on the field of software architecture”.  We believe that this sets realistic expectations of all audience members that they have a basic understanding of terminology used within the software industry or they are able to use resources to facilitate an understanding of the concepts should they require such.

 

 

 

 

 

 

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Adobe Developer Program - http://developer.adobe.com/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************


From: Namjoshi, Jyoti [mailto:Jyoti.Namjoshi@patni.com]
Sent: Wednesday, June 28, 2006 9:20 AM
To: Duane Nickull
Subject: RE: [soa-rm] Proposed Response for #1

 

Duane,

 

Can you pls. forward me a complete list of participants in today's call from the roll call taken? Just want to make sure I don't miss anyone / misinterpret any short name.

 

Thanks.

 

Jyoti

 


From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: Wednesday, June 28, 2006 9:39 PM
To: Ken Laskey; SOA-RM
Subject: [soa-rm] Proposed Response for #1

omment from: Sean.barker@baesystems.com

 

Name:Sean Barker

 

Title:Scientist

 

Organization:BAE SYSTEMS

 

Regarding Specification:Reference Model for Service Oriented Architecture 1.0

 

Re Section 3.2.2.1.2 Semantics, line 457, 458. The claim that "The formal descriptions of terms and the relationships between them (e.g., an ontology) provides a firm basis for selecting correct interpretations for elements of information exchanged" is incomplete, in that for applications that have an effect on the real world, the formal description must be based on the behaviour of the organizations - that is, at least some form of process model - and not simply on the descriptions of the terms themselves. A clarification of what constitutes a formal description in this context would be helpful.

 

 

 

<response>

The next section 3.2.2.2 of the RM discusses behavior models and the roles these play.  It is beyond the scope of the RM to expand on the specifics of “formal description”.

Also please note the section on Service Description (section 3.3.1) goes into further detail to provide clarification.

</response>

 

 

------

 



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