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:] 

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:] 

Sent: Wednesday, June 28, 2006
9:39 PM

To: Ken Laskey; SOA-RM

Subject: [soa-rm] Proposed
Response for #1

omment from: 

 

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>

 

 

------