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] Proposal: Reorganization of SOA-RM Draft for Better "Componentization"



A reference model actually needs to be a bottom up effort.  We leave the ever so popular “top-down” approach to folks like ebSOA J


We’re creating a vocabulary and general understanding of what I hope we can call a discipline of computer science in the future.  This means, we need a durable reference model that is not dependent on the current business environment.




From: Sally St. Amand [mailto:sallystamand@yahoo.com]
Sent: Monday, December 05, 2005 10:19 AM
To: frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better "Componentization"




This is in response to your request on last week’s conference call, if anyone has comments speak now. I also think that the recent comments on clarifying sections are a reflection of my issues with the specification.


I agree with the majority of points made/described in ver 10. My issues are with what is not in this draft. Based on Fig 1 the Refe! rence Model is guided by Reference Architectures, Concrete Architectures, Profile & Related Models. They in turn account for requirements, motivation & goals. This is creating a Reference Model from the bottom up. I believe a Reference Model should reflect a top down approach.


The Reference Model needs to reflect the environment, the strategy and the priorities of the business/mission/collaboration.  This will impact the construction of services. A service is a business task or activity that is realized through technology. The draft does a good job of describing how that realization happens. But it doesn’t provide a sufficient link between processes and services. The draft makes the point that the central focus of! SOA is the task of business function—getting something done. A business process is made up of tasks and activities to achieve a goal (getting something done). The concept of creating the service from the tasks and activities in a process is important. For example, where on the continuum of fine grained to coarse grained should a particular service be; this will affect interaction, reusability. The relationship between processes and services needs to be in the Reference Model.


While I saw that there is a note saying the glossary is still in flux, since one of the objective of the Reference Model is a vocabulary, having less in the glossary might be a better option. Is semantic integration a guiding principle of SOA? 


With respect to conformance there needs to be business results. That is an SOA should provide demonstrable mission accomplishments, e.g. ROI, match a competitors distribution channel. SOA is not a technology. Conformance should provide operational accomplishments, these should be measurable.









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