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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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


Subject: Re: [soa-rm-ra] FW: [s-ramp] Feedback S-RAMP Foundation Working Draft 01(s-ramp-foundation-v1.0-wd01.docx)


Fully agree with Rex
- Michael



-----Original Message-----
From: Rex Brooks <rex.brooks@ncoic.org>
To: mpoulin@usa.com
Cc: peter@peterfbrown.com; soa-rm-ra@lists.oasis-open.org
Sent: Mon, Jan 31, 2011 4:57 pm
Subject: Re: [soa-rm-ra] FW: [s-ramp] Feedback S-RAMP Foundation Working Draft 01 (s-ramp-foundation-v1.0-wd01.docx)

I agree for the most part with Michael, but I don't think it would hurt to specifically state that we are NOT specifying the type or kind of registry-repository. That should get us away from the WS bias.

Cheers,
Rex

On 1/30/11 3:23 PM, mpoulin@usa.com wrote:
Peter, 
thank you got this information. I constantly participate in public discussions about things mentioned by Linda. If you are interested (as well as anybody else), here are my comments:

- I have commented already that the term "implementation" is too IT related and for general purposes it is better to use "realisation"

- in the Management Concept, I have listed Service Repository as a part of minimal inventory of managed SOA infrastructure. However, I have not elaborated what interfaces , communications channels, standards and other details may be attributed to the Service Repository (IMO, Service Repository has to include Service Descriptions and, separately, Service Contracts first of all); technical specifics belong rather to Service Registry)

- I am strictly against using canonical data model of the organization in services; as Steve Jones has said, canonical data model  kills SOA. I fully agree with Steve and I have several publications of my own on this topic 

- I think that RAF is above the level of type of frameworks described by Linda. BTW, Rule-ML is a good candidate not for pre- and postconditions but for the service realisation.

- Michael

 



-----Original Message-----
From: Peter F Brown <peter@peterfbrown.com>
To: soa-rm-ra@lists.oasis-open.org
Sent: Sun, Jan 30, 2011 8:59 pm
Subject: [soa-rm-ra] FW: [s-ramp] Feedback S-RAMP Foundation Working Draft 01 (s-ramp-foundation-v1.0-wd01.docx)

FYI…
 
Peter
 
From: Linda Terlouw [mailto:linda.terlouw@icris.nl]
Sent: Sunday, 30 January, 2011 05:05
To: s-ramp@lists.oasis-open.org
Subject: [s-ramp] Feedback S-RAMP Foundation Working Draft 01 (s-ramp-foundation-v1.0-wd01.docx)
 
Dear TC members,

I am terribly sorry that I didn't respond to any of the earlier emails and did not participate in the conference calls. The last few weeks I was working on the manuscript of my dissertation and combined with commercial work I did not have any time left. The last few days I took the time to thoroughly study the working draft. Good to see all the work already done!

My most important feedback is:
- I like the distinction between the SOA model and the service implementation model. However, the word "implementation" is a bit confusing as people can also interpret this as the internal implementation of the services (internal design of the service). Of course this is not what is meant. Maybe we should alter this term (e.g. service technical specification). Or we could give a better explanation on what we do and do not mean with the term "implementation".
- In my opinion it is important to make a generic service repository that can be used for specifying services made using different standards, e.g. Web services, REST services, services based on Java RMI etc. So I think separation of the specification of functional aspects of the service and the actual technical contracts (e.g. WSDL/XSD) is key. A lot of information can be specified on a functional level without knowing the standard used (e.g. goal of the service, preconditions, postconditions, QoS, service provider information). It seems that the repository is focused very much on the WS-stack at the moment. Or am I wrong about this?
- I think we need to make a clear distinction between services that base their input and output on the canonical data model of the organization or those that do not.
- I think we are lacking some specification aspects in the framework. These include: information about the service provider (name, role/function, contact information), pre- and postconditions (or effects as they are called by the OpenGroup), an indicator whether or not a XSD belongs to the canonical data model or is a native XSD of some application, and a data dictionary for specifying semantics of the terminology used in the input/output of services. A possible standard for pre- and postconditions is Rule-ML.
- It's a bit unclear to me what the role of OWL is at the moment. In the current working draft it seems that OWL is used for building a service taxonomy. Or am I wrong. OWL can also be used for modeling the canonical data model, but I do not think this is intended in the current document. But I can be wrong about this.

I had a look at the list of issues in JIRA. If it's OK with everybody I can contribute to the following issues:
- SRAMP-3 RDF/OWL vs XML Schema
- SRAMP-18 UML Generation

Also, I can assist in modeling some of the functional aspects that need to be specified.

This Wednesday I'll also join the conference call.

--
Met vriendelijke groet/Kind regards,

ICRIS B.V.
Consulting and Research

Linda Terlouw
Enterprise Architect
Mob: +31 (0) 6 24 380 962
E-mail: linda.terlouw@icris.nl


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