[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] OASIS SOA-EERP Whitepaper
|
The distinction between SOA service and business service is
leading us to the rabbit hole of treating SOA as purely decomposition
technique. The whole premise of SOA was to align IT with business which
means that a service that does not have a concrete business meaning becomes a
technical component, using SOA technology for its access. Authentication
service should not really be a service in SOA terms. This aside, EERP whitepaper is about supplementing
technical definition of service contract (WSDL/WADL) with business definition. From: Bashioum,
Christopher D [mailto:cbashioum@mitre.org] 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] 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----- 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? The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]