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 agree we should not reference other specs that in the best of worlds should derive from the RM, but I am interested in hearing opinions of other concepts that someone might expect to be included.  I expect to be presenting this to sponsors and I see great value in practicing my arguments with a friendly audience.  If that audience uncovers something missing, we are alerted what to add in.  If we can justify a more limited RM scope and show how those extra concepts can be derived from the smaller set, I have my argument practiced.

A win-win either way.

Ken

On Dec 7, 2005, at 7:02 PM, Matt MacKenzie wrote:

Let[s remember that SOA-RM is meant to be a foundational work.  I am certainly very interested to hear and absorb the ideas of our colleagues in ebSOA, and OASIS as a whole…but I am just not interested in referencing other SOA specs.  We’re trying to define the first principles of SOA-RM, and to do that I think we have to remain pure.

 

-matt

 


From: goran.zugic@semantion.com [mailto:goran.zugic@semantion.com]
Sent: Wednesday, December 07, 2005 6:43 PM
To: Ken Laskey; goran.zugic@semantion.com
Cc: Duane Nickull; Sally St. Amand; frank.mccabe@us.fujitsu.com; soa-rm@lists.oasis-open.org; Matt MacKenzie; MATHEWS, Tim; john@maphin.net; george.w.brown@intel.com; vasco.drecun@cpd-associates.com
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

 

Ken,

 

Thanks for the response. I will send you specific additions and suggestions soon. I do not want to interfere with the current finalization of your draft. You will definitely have "a proposal" to discuss at your next week's FTF.

 

I look forward to discussing a potential collaboration between SOA RM and ebSOA TC. I believe that ebSOA editors think the same.

 

Goran

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org]
Sent: Wednesday, December 7, 2005 05:42 PM
To: goran.zugic@semantion.com
Cc: 'Duane Nickull', 'Sally St. Amand', frank.mccabe@us.fujitsu.com,
soa-rm@lists.oasis-open.org, 'Matt MacKenzie', 'MATHEWS, Tim'
Subject: Re: [soa-rm] Proposal: Reorganization of SOA-RM Draft for Better

Goran,

You are certainly much more familiar with the specs you mention than I. Consider what specific additions you would suggest for the RM spec and we can see exactly how this would affect the current draft. Although time is short, it would be best to have something for consideration at next week's ftf.

Ken


On Dec 7, 2005, at 5:30 PM, goran.zugic@semantion.com wrote:

Ken,
 
You raised some very interesting points here. These are just some of architectural details we support in Federated Enterprise Reference Architecture (FERA)-based SOA.
 
We already have a reference architecture and we already model and use services in SOA Information Model (SOA IM) and SOA Collaboration Semantics (SOA CS) and link them with business processes and their components. I am not trying to interfere with SOA RM TC concept and vision of SOA RM. I expressed what my vision is and I respect and understand differences. However it is not the reason that we cannot collaborate in supporting integration of OASIS SOA related specs. SOA RM TC does not have to change its specs to do that but some kind of link that provides the integration has to be formulated and mutually referenced in our specs. Please keep in mind that this is my opinion. Some kind of flexibility is needed to support OASIS standards convergence and integration.
 
Our view and support of business processes is generic (i.e., supply chain, logistics, data management, finance, and many others). We also support infrastructural processes and IT management processes. Any process that can be presented using  standard generic process language (activities, decisions, events, etc.) we support. Just to list very few concepts from our model that match what you mentioned below:
 
- A service consumer can be a human or a system ( a software agent). We support and model both people and systems as participants in collaborations.
- Each service has inputs and outputs. Outputs of one service become inputs for others. In SOA IM, we even model them based on versioning, timing and other constraints.
- FERA-based SOA reference architecture does not change with processes. It is a generic architecture that supports many types of processes. We support all SOA layers from message exchanges to complex services orchestrations. For example, ESB is just one of the components in FERA-based SOA architecture represented in a form of the Gateway and the Federation Manager. We have a complete "service  orchestration engine" that semantically integrates SOA architectural components like registry and repository, security provider, process flow controller and others. And all of them are open standard-based components. We integrate and reference already available standards for these components (i.e., Web Services, ebXML, etc.). SOA Information Model and SOA Collaboration Semantics  provide architectural integration and management and maintenance of process context and content and of course processes and their components are modeled and executed as services.
 
I just tought that this can save some time to SOA RM TC if you start considering concepts and solutions ebSOA TC already have in place for a while.
 
Goran

-----Original Message-----



From:
Ken Laskey [mailto:klaskey@mitre.org]



Sent:
Tuesday, December 6, 2005 01:38 PM



To:
'Duane Nickull', 'Goran Zugic', 'Matt MacKenzie', '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



I think we need to add some words to the RM to capture this discussion.  We cover part of this in the beginning of Section 3.2.1 but need to be more specific that:

- a service consumer can be a human or a software agent;

- a service consumer can invoke any number of services (including a single service in isolation) and can chain the output of some services to act as the input of others;

- from the perspective of a given service, the occurrence of such chaining would not be visible;

- the service consumer can be implementing a business process;

- the specific of a business process do not change the basic SOA concepts as described in the RM; however, the specific architecture that one designs and implements will reflect the business process and make use of specific service instances that corresponds to the real world effects that the business process hopes to realize.

Now that said, and in full appreciation that we agreed earlier that mechanisms which combine services (e.g. choreography, orchestration) are out of scope, is it sufficient for words, such as those suggested above, to be included somewhere within the current discussion or do we need to pull it out into a subsection on its own?  As an example of the former, we tried to deal with loose-coupling and coarse-grained with words at the end of Section 2.1.

Ken

At 12:23 PM 12/6/2005, Duane Nickull wrote:

Goran:



 



I slightly disagree with your assertions, probably based on semantics.  For a service to “participate” in a process, it would have to be aware of the process (which many will not be).  A better way to depict this may be to state “services may be aggregated and used by processes” and “processes may be represented/exposed as services”.  There are really no limits to the number of layers that can be present.  Attached is a UML CVD depicting such.



 



A key rationale of why process is not part of SOA is that services cannot see process.  They are not aware of whether they are being called as part of a process vs. as an individual service.  If the “s” part of SOA cannot see or touch that, it cannot be part of the RM.



 



The chicken and egg discussion you bring forward is a requirement for those building services to strongly consider the business process when designing their service infrastructure.  Accordingly, it is not really part of the RM for SOA yet I agree that it is a very important consideration.



 



For your messages to get to the list, you must join as a “applicant” rather than an “observer” as per OASIS process.



 



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:
Goran Zugic [ mailto:goran.zugic@semantion.com]



Sent:
Monday, December 05, 2005 8:47 PM



To:
Duane Nickull; Matt MacKenzie; 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


 

Duane,


 

Thanks for the response. Yes I would like to see the PPT. I hope you do not mind if I add few more thoughts related to services and business processes:


 

Services participate in a business process to add some value to it. They can be governed and evaluated using business process metrics. One service can participate in many business processes and provide value to each of them according to the context within that process. As far as SOA is concerned it is as important to know what the service does, how it can be discovered, contacted, invoked, executed, etc. as it is to be able to use it within the process context, measure it and assess its value from the business process requirements point of view. SOA needs to avoid typical new technology chicken and egg syndrome, e.g. companies not producing services because there are no service friendly process definitions to use them and not having SOA friendly process definitions because there are no services to use. Services do not have to know if they will be involved in the process upfront, they will be contacted on demand according to the process script that is in effect, and they will be contacted, checked if available, passed the arguments, collected the response and according to their procedure left alone to wait for another call. The process execution engine however needs to invoke the service according to both service specific information and the process specific information.


 

Having just the service specific information in a model covers only one part of the picture and I think it is fine as long as that model is a pure service model. However I find it difficult to understand that the SOA RM TC model is a SOA reference model when it does not include other concepts of SOA. Unfortunately it seems that we cannot get to the point where we could agree on a minimal set of supported SOA concepts by a model to be the SOA RM.  We do not have to and I do not want to argue with you or anybody else in SOA RM TC. I am just trying to see how our works can fit together in a most efficient way. We obviously need more time to better understand each others thoughts and ideas and I strongly believe that a constructive respectable discussion is helpful for everybody.


 

By the way, do you know what I am supposed to do to get my messages to the SOA RM list. In spite of that I am the SOA RM TC observer I get a faliure notice whenever I send a note to the SOA RM. 


 

Goran


 

----- Original Message -----

 

From: Duane Nickull

 

To: Matt MacKenzie ; goran.zugic@semantion.com; MATHEWS, Tim ; Sally St. Amand ; frank.mccabe@us.fujitsu.com

 

Cc: soa-rm@lists.oasis-open.org

 

Sent: Monday, December 05, 2005 5:02 PM

 

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




 




 



!




 




 





 

 



--



     ---------------------------------------------------------------------------------



  /   Ken Laskey                                                                \



 |    MITRE Corporation, M/S H305    phone:  703-983-7934   |



 |    7515 Colshire Drive                    fax:      703-983-1379   |



  \   McLean VA 22102-7508                                              /



    ----------------------------------------------------------------------------------


------------------------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508



---
Ken Laskey
MITRE Corporation, M/S H305     phone:  703-983-7934
7515 Colshire Drive                        fax:        703-983-1379
McLean VA 22102-7508





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