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


I’m glad the RM doesn’t go into this area it would probably get religious! I’d make process subservient to service, its just a technology choice in the implementation of a service.  A high level business service could be implemented as a set of processes which orchestrate lower level services.  Service Architecture is a vision of the business realised by IT, the implementation technology for each service is the most appropriate for a given service.  Sometimes Services are People rather than IT (workflow et al), I agree about not having every service that is called maintaining a process thread, but not on the separation between Services (low-level) and processes (high-level).

 

POA is in my mind just Visual COBOL, a bad idea in 1980, a bad idea today. 

 

Steve

 

 


From: Duane Nickull [mailto:dnickull@adobe.com]
Sent: 05 December 2005 22:02
To: Matt MacKenzie; goran.zugic@semantion.com; MATHEWS, Tim; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

 

Goran:

 

The service layer enables the process layer over top of it, however during runtime, services do not know if they are part of a process or being called individually (it would generally be a bad idea to try to maintain the overall state of a process within each service, although it could be done).  For maximum repurposing of services, it would be better to have the service as a simple slave to the processes that may use it.  

 

Accordingly, we made a decision that BPM, Orchestration, choreography is not a core part of the RM for SOA.  We generally seem to agree that many SOA implementations will include a layer of BPM over top.  We are only addressing the SOA model, not the model for the underlying or overarching layers.

 

I have a PPT that explains this in more detail if you are interested.

 

Duane

 

*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT 
http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
*******************************

 


From: Matt MacKenzie [mailto:mattm@adobe.com]
Sent: Monday, December 05, 2005 12:51 PM
To: goran.zugic@semantion.com; MATHEWS, Tim; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

 

Process orientation is only one of multiple potential integration with service oriented architecture.  SOA-RM is laying the foundation for durable architecture based on the core concept of service orientation.  We recognize that process oriented architecture is a natural fit with service orientation…but so are things like event orientation.

 

-matt

 


From: goran.zugic@semantion.com [mailto:goran.zugic@semantion.com]
Sent: Monday, December 05, 2005 3:36 PM
To: MATHEWS, Tim; Matt MacKenzie; Sally St. Amand; frank.mccabe@us.fujitsu.com
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

 

I think that SOA RM has done good job documenting well-known service related concepts and defining some new ones.

 

I do not see other details besides service and service-related concept definitions in the current SOA RM committee draft right now. I look forward to seeing the completion of the model you are working on with the bottom-up approach. 
 
Business, business processes and collaboration aspects of business are important to address in the model what is not the case with the current content of the SOA RM committee draft. By a business process I mean a generic business process entity which has common components (activities, decisions, etc) and relationships between them that can be used to model a business process in any environment regardless of what business we support and technology we use. I agree with Sally that a link between business processes and services should be one of key requirements any SOA reference model should try to meet.

 

I am not sure what SOA with services brings to business when the link between the business processes and services and overall business process semantics in the SOA context are not considered to be important aspects in a SOA-based reference model.

 

Goran

-----Original Message-----
From: MATHEWS, Tim [mailto:tmathews@lmi.org]
Sent: Monday, December 5, 2005 12:34 PM
To: 'Matt MacKenzie', 'Sally St. Amand', 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"

Matt - I am not sure what point you are trying to make by this?  I agree with your premise of a bottom up effort, as this was one of the operating assumptions that was made from the beginning.

 

But, I am confident it is the business environment that is independent from the reference model.

 

TM

 


From: Matt MacKenzie [mailto:mattm@adobe.com]
Sent: Monday, December 05, 2005 11:58 AM
To: Sally St. Amand; 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"

Sally,

 

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.

 

-matt

 


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"

 

Frank

 

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.

 

Sally

 

 

!

 

 

 

This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.



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