You're welcome Roy. To help answer your question below,
here are 3 excerpts from the current OASIS SOA-RM public review draft that
address the relationship between services and their
interfaces:
- "A service
is
a mechanism to enable access to a set of one or more capabilities, where the
access is
provided using a prescribed interface and is exercised consistent with
constraints and policies as specified by the service description."
- "A service is accessed by means of a service
interface (see Section 3.3.1.4), where the interface comprises the specifics of
how to access the underlying capabilities."
- "The service interface is the means for
interacting with a service. It includes the specific protocols, commands, and
information exchange by which actions are initiated that result in the real
world effects as specified through the service functionality portion of the
service description."
Though not mentioned in this manner in our SOA-RM spec
(because I believe it is more appropriate for our in-process SOA Reference
Architecture), I believe there is a hierarchy here of sorts:
INTERFACE
------------------
SERVICE
------------------
CAPABILITY
That is, I believe a
given capability (e.g. provide supply chain visibility) may be accessed via
multiple services (perhaps from different geographic locations, or within
different organizations). Also, a given service may have multiple interfaces -
for example, a service may expose an interface to one consumer that includes
(i.e. causes it to provide) additional information pertinent to that consumer,
without providing that information to other consumers. An example might be a
Weather service that provides a "last updated" time for a given consumer. Now
one could argue that that consumer is interfacing with an entirely different
service than the other consumers for which the "last updated" time is not
provided, but I personally believe it is the same service but with a different
"face".
Joe
Joseph Chiusano
Associate
Booz Allen Hamilton
700 13th St. NW, Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
UNCLASSIFIED
Thanks Joe, I appreciate your thoughts and they address the issue I was
getting at with my question. I was also wondering if the "Service" is
generally talked about without discussion of the interface and how the
discussion of the interfaces is usually handled in the community of
experts?
Vr, Roy
_____
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-bounces@xxxxxxxxxxxxxx]
On Behalf Of Chiusano Joseph
Sent: Wednesday, May 10,
2006 8:28 AM
To: Service-Oriented Architecture
CoP
Cc: soa@xxxxxxxxxxxxx
Subject: RE: [soa-forum] Definitions of SOA (U)
I believe that it should. More specifically, which type of
interface (technical or business) depends on whether a service is primarily a
technical service or a business service. Or rather, whether it is primarily
technical-"facing" or business-"facing".
In my explanation below, I will use the
term "technical interface" to mean an an electronic "contract" between two
services, such as WSDL (with full knowledge that WSDL only provides part of what
is needed in many cases). I will use the term "business interface" to imply the
presence of a technical interface, plus business-level details about how a
service fits within an organization's operations, the general benefits that can
be realized from using the service, how it fits with the organization's
strategic plans and goals, what organizational units may most benefit from it,
etc.
An example of a "technical-facing"
service would be a security service that enables services to be
authenticated/authorized by other services/systems/data sources through the
provisioning of security tokens (Kerberos, SAML, etc.). Such a service may, for
example, be invoked by a data service (think Enterprise Information Integration
(EII) and federated queries) in order to enable it to be authenticated and
authorized (if all goes well) by the data source. I would assert that the
interface between the data service and the security service is more of a
technical interface than a business interface, as it reflects an electronic
"contract" between the two services (the data service and the security service),
and there is no need (or at least not as great a need as with business-facing
services) to provide a business interface.
An example of a "business-facing"
service would be a "shipment visibility" service that is part of a supply chain
that provides the ability to know the location *and condition* (which is very
important!) of cargo at any point in a supply chain. Such a service could, for
example, enable a supply chain participant to know that certain cargo is damaged
earlier than they otherwise would know (i.e. before the ultimate customer
receives the cargo), thereby providing the participant with an opportunity to
correct the situation as soon as possible. If this links to an operational
performance measure/goal for the participant (e.g. decrease percentage of
damaged goods on arrival by X percent this quarter), then that service is also
supporting key operational needs, and potentially providing the organization
with a distinct strategic advantage.
I would assert then that such a service
(which I like to call an "operational" service, as it does not imply bias to
commercial entities) requires both a technical interface and a business
(operational) interface. The business (operational) interface would primarily be
in written (human-readable) form, and would include such details as those I
outlined above: how the service fits within an organization's operations (the
"shipment visibility" service would be most closely aligned with its Supply
Chain operations), the general benefits that can be realized from using the
service (decreased amount of damaged goods on arrival, which ultimately leads to
greater customer satisfaction), how it fits with the organization's strategic
plans and goals (greater customer satisfaction can provide strategic
advantages), what organizational units may most benefit from it (those that
interface with Supply Chain operations), etc.
Thanks,
Joe
Joseph
Chiusano
Associate
Booz Allen
Hamilton
700 13th St. NW,
Suite 1100
Washington, DC 20005
O: 202-508-6514
C: 202-251-0731
Visit us online@ http://www.boozallen.com
_____
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-bounces@xxxxxxxxxxxxxx]
On Behalf Of Mabry, Roy, Mr, OSD-NII
Sent: Wednesday,
May 10, 2006 8:02 AM
To: Service-Oriented Architecture
CoP
Cc: soa@xxxxxxxxxxxxx
Subject: RE: [soa-forum] Definitions of SOA (U)
UNCLASSIFIED
Hi,
In regard to
the definition of service, shouldn't it include the notion that the service has
to be exposed to the external environment by a technical and business interface?
Vr, Roy
_____
From: soa-forum-bounces@xxxxxxxxxxxxxx [mailto:soa-forum-bounces@xxxxxxxxxxxxxx]
On Behalf Of Chris Harding
Sent: Friday, May 05, 2006
8:31 AM
To: Service-Oriented Architecture CoP;
'Service-Oriented Architecture CoP'
Cc:
soa@xxxxxxxxxxxxx
Subject: [soa-forum] Definitions of
SOA
Hi -
As a further update, here is the definition of SOA that was
presented at The Open Group conference last week (and which we have shared with
the OMG).
SOA is an architectural style that supports service
orientation
Service orientation
A way of a way of
thinking in terms of services and service based development and the outcomes
that services bring
Service
A logical representation of a
repeatable business activity that has a specified outcome (e.g., check customer
credit; provide weather data, consolidate drilling reports), is self-contained
and maybe composed of other Services. It is a black box to consumers of the
Service
Architectural Style
The combination of
distinctive features in which Enterprise Architecture is done, or
expressed
The SOA Architectural styles distinctive features:
Based on the design of the services comprising an
enterprises
(or
inter-enterprise) business processes. Services mirror real-world
business activity
Service representation utilizes business descriptions.
Service
representation requires
providing its context (including business
process, goal, rule, policy, service interface
and service component)
and
service orchestration to implement service
Has
unique requirements on infrastructure. Implementations are
recommended to use open standards, realize
interoperability and
location
transparency.
Implementations are environment
specific, they are constrained or
enabled by context and must be described within their context.
Requires strong governance of service representation and
implementation
Requires a Litmus Test", which
determined a good service
At 20:31 04/05/2006, Cory Casanave wrote:
As an update from the OMG meeting last week, the SOA SIG adopted
the following definition of SOA;
Service Oriented Architecture is an architectural style for a
community of providers and consumers of services to achieve mutual value, that:
* Allows participants in the
communities to work together with minimal co-dependence or technology dependence
* Specifies the
contracts to which organizations, people and technologies must adhere in order
to participate in the community
* Provides for business
value and business processes to be realized by the community
* Allows for a variety of technology
to be used to facilitate interactions within the community
The corresponding definition of service has not yet been
finalized but the sense of the group is that there would be both a
business/domain centric notion of service as well as an interaction focused
definition.
In both cases this seems to fit well with the notion of SOA that
is evolving in this group and in the SOA Demo.
Regards,
Cory Casanave
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP
Regards,
Chris
+++++
========================================================================
Dr. Christopher J. Harding
Forum
Director for SOA and Semantic Interoperability
THE OPEN
GROUP
Thames Tower, 37-45 Station Road, Reading RG1 1LX,
UK
Mailto:c.harding@xxxxxxxxxxxxx Phone
(mobile): +44 774 063 1520
http://www.opengroup.org
******************************************************************
IT Architecture Practitioners Conference
Hyatt Regency, Coral Gables, FL July 17-19, 2006
Member Meetings - July 17-21, 2006
http://opengroup.org/miami2006/
========================================================================
TOGAF is a trademark of The Open Group
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (01)
|