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] OASIS SOA-EERP Whitepaper


I am more in agreement with Ken, Boris and Michael on this. In fact, in 
my review of the SOA-EERP specs, the issue never came up, but then, I 
was part of the initial work on SOA-EERP so that's not surprising. For 
me this is all of-a-piece, and self-consistent, and SOA-EERP is just 
putting in place a set of structured specifications that, like the SCA 
and Security pieces, fit into the overall mosaic that are inching us 
closer to a robust SOA Ecosystem. There is still a lot of work to be 
done, and a ton of lessons that need to be learned, partcularly where 
scalability breaks down in the attempt to use all of these 
specifications together, but I am confident we'll get there.

Cheers,
Rex

mpoulin@usa.com wrote:
> Between Christopher and Boris positions, I am rather closer to the 
> Boris' one.
>
> While I agree with Christopher that unaccessible function is not a 
> service, I think that 'capability' is an ability to realise a business 
> function and this capability is not about visibility or interaction. 
> This is why I agree with 'service' (which provides visibility and 
> allows for interactions) is not the same thing as the function or 
> ability to execute the function (=capability). Despite this small 
> difference, I do not have a significant difference with Christopher in 
> this topic.
>
> However, I do not see at all how this 'service(capability)' can lead 
> to a <<distinction between a business service and a SOA service >>. I 
> do believe and write in all my later BLOGs that such separation is the 
> root of all the worst mistakes in dealing with Service Orientation. 
> The real - business - value of Service Orientation is in convergence 
> between manual and automated parts of the business service. All 
> technical service interfaces and 'contracts' are immaterial until they 
> have an association with particular business meaning. To me, SOA 
> Executions Context comprises Business Execution Context and Technical 
> Execution Context; I wrote about this in a few messages a year ago. 
> SOA context is the business context, first of all. Service Orientation 
> is the natural business methodology that finds its a part of its 
> implementation in the Technology. This is why it is Business who has 
> to lead SOA technical initiatives, not other way around. The RAF 
> statement about positioning of SOA between Busienss and Technology 
> fully reflects my statement about Business-Technology relationship.
>
> I think that the statement <<*/Services /*are performed by people, 
> machines, and hardware/software applications, and represented by SOA 
> services>> is ABSOLUTELY correct. This is what I was waiting for the 
> long time and expected SOA RAF to put in place.
>
> Orientation of Business on service is well visible at the top of the 
> business structure but it is dissolved in the service implementation 
> via processes in the middle of the structure. Technology, i.e. 
> automation, is one of possibilities of implementation of SOA in the 
> Enterprise. Different services may have different interfaces to its 
> consumers; some services may have a postal interface as well as a Web 
> interface simultaneously and <<accessed via a network endpoint >> is 
> only one among many others. Even more, automation in Business SOA 
> Services is not an enabler as many of us think but it is an improver, 
> enhancer, facilitator or alike.
>
> This is how I look at SOA and I believe that the existence of SOA RM 
> and RAF are enabling SOA-EERP, making the solid ground for it.
>
> - Michael
>
>
>
> -----Original Message-----
> From: Bashioum, Christopher D <cbashioum@mitre.org>
> To: mpoulin@usa.com <mpoulin@usa.com>; soa-rm@lists.oasis-open.org 
> <soa-rm@lists.oasis-open.org>
> Cc: Laskey, Ken <klaskey@mitre.org>
> Sent: Tue, Apr 6, 2010 3:38 pm
> Subject: RE: [soa-rm] OASIS SOA-EERP Whitepaper
>
> The problem here is the intuitive notion of a “service†as 
> performing some function for another, as opposed to the less intuitive 
> but absolutely necessary notion of making that “function†
> accessible to another. The side-effect of this is that many folks now 
> call every function a “function-service†and voila, they are done! 
> Unfortunately, they then avoid the harder work required to make a 
> capability - intended for consumption by others - actually consumable, 
> i.e., the stuff the RM points out like visibility, interaction (across 
> different execution contexts), and real-world effect. If they just 
> focus on the functionality (capability) and assume it is a service 
> because it is stated to be so, it will end up being the same old 
> “stovepipe†that we’re trying to get away from.
> This is why the distinction between a business service and a SOA 
> service is necessary, and why I keep pointing it out. The business 
> side of the house is looking at what the business does for another 
> (the end result of some set of business processes – done on behalf 
> of another), wherease the technology side of the house **must** do 
> things very differently if they want to enable the business side of 
> the house via a SOA context.
> The EERP whitepaper seems to confuse this distinction. I didn’t read 
> the xml schemas, but I did read the whitepaper, and the whitepaper 
> seems to indicate that the quality of service is for a business 
> service that is made available on the network via a SOA service. The 
> business service may be accomplished via humans (e.g., Amazon’s 
> mechanical turk), but the business service is accessed via a network 
> endpoint and any associated processing that is necessary to make the 
> business service accessible over that network (i.e., the SOA RM service).
> *From:* mpoulin@usa.com <mailto:mpoulin@usa.com> 
> [mailto:mpoulin@usa.com <mailto:mpoulin@usa.com?>]
> *Sent:* Monday, April 05, 2010 2:12 PM
> *To:* Bashioum, Christopher D; soa-rm@lists.oasis-open.org 
> <mailto:soa-rm@lists.oasis-open.org>
> *Cc:* Laskey, Ken
> *Subject:* Re: [soa-rm] OASIS SOA-EERP Whitepaper
> While I think that a White Paper would be really useful, replacement 
> of the word 'service' by the word 'capabilities' may have unpleasant 
> effect in the business meaning of 'service'. In Business, people, 
> machines and HW/SW serve the business needs/tasks. Service as a means 
> of accessing capabilities is too abstract and difficult to expand on 
> the area of corporate business (according to RAF, SOA is in between 
> and in both Business and Technology).
> An alternative interpretation is that people, machines and HW/SW 
> perform service by utilizing capabilities. Service cannot exist 
> without associated capabilities. If capabilities are unaccessible, no 
> service exists. Service is an activity/action with capabilities. 
> Service can exist w/o consumers; the opposite is also correct - 
> consumers may have needs/intents to use a 'service', which is not 
> available yet (it is known as 'demand').
> That is, the capabilities may exist w/o a service while opposite is 
> incorrect. How much this re-interpretation changes the 'service' 
> semantic in RAF?
> - Michael
> -----Original Message-----
> From: Bashioum, Christopher D <cbashioum@mitre.org 
> <mailto:cbashioum@mitre.org>>
> To: soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org> 
> <soa-rm@lists.oasis-open.org <mailto:soa-rm@lists.oasis-open.org>>
> Cc: Laskey, Ken <klaskey@mitre.org <mailto:klaskey@mitre.org>>
> Sent: Thu, Apr 1, 2010 7:08 pm
> Subject: [soa-rm] OASIS SOA-EERP Whitepaper
> Has anyone else from the SOA RM TC reviewed the OASIS SOA-EERP whitepaper
> http://docs.oasis-open.org/soa-eerp/whitepaper/EERP-Model-UseCase-WhitePaper-cd03.pdf
> They reference the RM, however, there is one paragraph that caught my 
> attention:
> */Services /*are performed by people, machines, and hardware/software 
> applications, and represented by SOA services. The qualities of a 
> business service are expressed by means of the Business Quality of 
> Service (bQoS) specification. The nature of bQoS varies across 
> industries and services.
> The RM would change this to
> */Capabilities /*are performed by people, machines, and 
> hardware/software applications, and represented by SOA services. The 
> qualities of a business service are expressed by means of the Business 
> Quality of Service (bQoS) specification. The nature of bQoS varies 
> across industries and services.
> I think we may need to do something about addressing the idea of a 
> capability that is intended for “othersâ€, i.e., a business service 
> – which is enabled in Software by a SOA service in front of a 
> capability. We’ve talked about it, but I think a whitepaper on this 
> will be useful.
> Note that such a whitepaper would also go a long way towards helping 
> to navigate the SOA Standards landscape, as I think the main issue 
> between the various SDOs on SOA is about using the term “service†
> to mean “functionality intended for others†vs. as an IT artifact 
> that enables access to such funtionality (which is the RM view).
> Thoughts?

-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670



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