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] OO vs. SOA and what goes into a service


So from the foundation laid in the RM, I'd say finance is a set of business functions for which individual services could provide access to the capabilities that give the real world effects associated with each function.  Procurement is a multiple step process and some of those steps can be accomplished using more fundamental services and some of the steps are more specialized to procurement.  The specialized steps will likely show up as actions and the process model describes the path through the actions and external services invoked.  (Because there can be lots of pieces, the process model may have recognized dependencies.)

The Procurement service may have multiple process models.  For example, one process could be nominal ordering, on could be recovery if an error occurred during the process, and a third might be special confirmation.  We should probably go out of our way not to bundle too many variations or options in a single service, because that's when description and discovery become mangled and that probably reduces opportunities for reuse.

So questions:
1. Does this capture our consensus on how SOA services and interactions should work?  (I think it is consistent with most of what has been said on this thread.)
2. Are there fundamental things floating in this thread that need to be clearly expressed in the RA?  Have we clearly included this?

Ken

On Jan 23, 2008, at 3:21 AM, Jones, Steve G wrote:

The capabilities are the operations, the service is the container IIRC the RM.
 
From my perspective the services are the “what” bits of the enterprise so they define broadly what an enterprise or project does so “finance” is a business service and “procurement” is a business service inside finance.  Services then have capabilities which are “why” another service/consumer/actor would communicate with them.  So Procurement has a “buy” capability.
 
On OO v SOA I’ve tended to think of SOA as being like OO that has grown up and taken on real world responsibilities J
 
Steve
 
 
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: 23 January 2008 03:58
To: Duane Nickull
Cc: soa-rm-ra
Subject: Re: [soa-rm-ra] OO vs. SOA and what goes into a service
 
I'm not talking implementation (SOA can use OO principles to develop the code) but general mindset.  We once agreed that asking "what is a service?" is similar to asking "what is an object?" because the answer is it could be anything that fits your problem.  My thought is a service is not necessarily a good object that you operate on but more like an operation that you may be feeding objects to.
 
Again, this is all at the concept level, no implementation.
 
Ken
 
On Jan 22, 2008, at 6:45 PM, Duane Nickull wrote:


In SOA, is it necessary that there is an object behind the service?  We talk to the interface (service)and don’t really care what is behind it.  Assuming there is an object could be errant and architecturally un-elegant.

Duane


On 1/22/08 3:05 PM, "Ken Laskey" <klaskey@mitre.org> wrote:


Is it fair (or at least not too distorted) to say that with OO we define an object and look for what we can do to it (i.e. its methods) while with SOA we identify what we want to do (i.e. business functions) and then, if appropriate, look for objects to do it to?


-- 
**********************************************************************
"Speaking only for myself"
Senior Technical Evangelist - Adobe Systems, Inc.
Blog - http://technoracle.blogspot.com
Community Music - http://www.mix2r.com
My Band - http://www.myspace..com/22ndcentury
Adobe MAX 2008 - http://technoracle.blogspot.com/2007/08/adobe-max-2008.html
**********************************************************************
 
-----------------------------------------------------------------------------
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7151 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508
 
 


 


Capgemini is a trading name used by the Capgemini Group of companies which includes Capgemini UK plc, a company registered in England and Wales (number 943935) whose registered office is at No. 1 Forge End, Woking, Surrey, GU21 6DB. 
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.


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




smime.p7s



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