Yes, but…
The other swing of the pendulum – everything is a service – will make SOA nothing, but a reincarnation of distributed computing. I would rather eliminate
some potential services, then see this happening.
Take a look at
http://63.246.7.136/news/2010/02/SOANutshell
From: Mike Poulin [mailto:mpoulin@usa.com]
Sent: Tuesday, December 27, 2011 10:38 AM
To: Lublinsky, Boris; soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] Using of the term "service"
I know, Boris. I was thinking about this since you first made this statement. At the end, I think it is too early to say that all services are
business services. We still have a gap in a common mindset between business and technology and at this moment we still need recognition and support of technology people who concern mostly about automation. That is, I am in the favor for the presence of both
business and technical services.
In general, I do agree with you that any service is a business and any business is service-oriented by nature (the latter is my conclusion). This is why I struggle against "service-oriented business process" and "service-oriented business collaboration"
Also, I was a witnes and even an actor in the case where the same security service was identified as a technical service and as a business services depending on who used it (IT Security Admin or Business Manager of a Call Centre).
Best regards,
- Michael
----- Original Message -----
From: Lublinsky, Boris
Sent: 12/27/11 04:18 PM
To: Mike Poulin, soa-rm-ra@lists.oasis-open.org
Subject: RE: [soa-rm-ra] Using of the term "service"
Michael,
The whole point of this was to ensure that the word service means business service. All other extraneous
services mentioned in the document are not really services – they are supporting thingies
From: soa-rm-ra@lists.oasis-open.org
[mailto:soa-rm-ra@lists.oasis-open.org] On Behalf Of Mike Poulin
Sent: Tuesday, December 27, 2011 10:10 AM
To: soa-rm-ra@lists.oasis-open.org
Subject: Re: [soa-rm-ra] Using of the term "service"
I trust that Boris has found all related cases. Therefore, I only put my comments (MP)
to Boris notes in the text.
- Michael
----- Original Message -----
From: Lublinsky, Boris
Sent: 12/26/11 06:27 PM
To: Ken Laskey, peter@peterfbrown.com
Subject: [soa-rm-ra] Using of the term service
As promised, here is the scan of the document with suggested changes
1867, 1868
A single point of failure. If the mediation service fails then a large number of service providers and consumers are potentially adversely affected.
Suggestion – service mediator
MP: leave "mediation service". Service mediator is a detail
of implementation of mediation service
1869
If the central mediation service is owned by,
Suggestion – service mediator
MP: leave "mediation service". Service mediator is a detail
of implementation of mediation service
1872
The registry stores links or pointers to service description artifacts. The repository in this example is the storage location for the service description
artifacts. Service descriptions can be pushed (publish/subscribe for example) or pulled from the registry/repository mediator.
Suggestion
The registry stores links to the services end points locations, while repositories stores service description artifacts. Both service locations and
descriptions can be pushed (publish/subscribe for example) or pulled from the registry/repository mediator.
MP:
The registry/repositorystores links to the services end points locations and service description artifacts. Both service locations and descriptions can be pushed (publish/subscribe
for example) or pulled from the registry/repository.
- I'd advice to avoid debates and explanations on differences and specifics of registry vs. repository. Also, both of them storages as a data base and, thus, cannot be Actors in the SOA ecosystem, i.e. they cannot
be mediators or mediator services.
2253
Infrastructure services that provides mechanisms to support service interaction, including but not limited to:
o
mediation services such as message and event brokers, providers, and/or buses that provide message translation/transformation, gateway capability, message persistence, reliable message
delivery, and/or intelligent routing semantics;
o
binding services that support translation and transformation of multiple application-level protocols to standard network transport protocols;
o
auditing and logging services that provide a data store and mechanism to record information related to service interaction activity such as message traffic patterns, security violations,
and service contract and policy violations
o
security services that provide centralized authorization and authentication support, etc., which provide protection against common security threats in a SOA ecosystem;
o
monitoring services such as hardware and software mechanisms that both monitor the performance of systems that host services and network traffic during service interaction, and are capable of
generating regular monitoring reports.
Suggestion
Services infrastructure that provides mechanisms to support service interaction, including but not limited to:
o
service mediation such as message and event brokers, providers, and/or buses that provide message translation/transformation, gateway capability, message persistence, reliable message
delivery, and/or intelligent routing semantics;
o
service binding that support translation and transformation of multiple application-level protocols to standard network transport protocols;
o
auditing and logging services that provide a data store and mechanism to record information related to service interaction activity such as message traffic patterns, security violations,
and service contract and policy violations
o
service security that provide centralized authorization and authentication support, etc., which provide protection against common security threats in a SOA ecosystem;
o
service monitoring such as hardware and software mechanisms that both monitor the performance of systems that host services and network traffic during service interaction, and are capable of
generating regular monitoring reports.
MP: It seems to me that Infrastructure Services are proposed to be replaced by Infrastructure. These are not the
same or synonims and, probably, should exist/coexist together. The question is: do we want to go down to the level of Infrastructure or do we want to leave this "detail" for implementation or pre-requisits of implementation of the Infrastructure services.
BTW, all loging and audit and evendata services do not necessary provide ata store but rather use one, which may be under separate authority (like Shared UDDI was under IBM-Microsoft-Oracle-Do
notRememberName and not under any services that used it).
Also, authorization and authentication should not be necessary centralized, especially in SOA ecosystem (no one controls ntire SOA ecosystem) but rather utilize a federaton model.
Finally, from my SOA testing experience, I believe that monitoring performance of systems and network traffic does not provide a full picture of transaction and events in the SOa ecosystem; we need to monitor
services' actions as well (Parasoft's SOATest and iTKO's LISA do exactly this and are the best SOA testing tools in the market).
So, my suggestions are:
Infrastructure services that provides mechanisms to support service interaction, including but not limited to:
o mediation services that utilise such infrastructure elements as message and event brokers, and/or buses that
can can be featured with message translation/transformation, gateway capability, message persistence, reliable message delivery, and/or intelligent routing semantics;
o binding services that support mapping and transformation of multiple
application-level protocols to standard network transport protocols;
o translation services that support semantic interpretation or rendering of message content including message
destinations network transport protocols between different semantics and ontologies used in the service interactions;
o auditing and logging services that provide mechanisms to record
information related to service interaction activity such as message traffic patterns, security violations, and service contract and policy violations in a data store;
o security services that provide authorization and authentication
support, etc., which provide protection against common security threats in a SOA ecosystem;
o monitoring servicesthat utilise such infrastructure elements as hardware and software mechanisms
that both monitor the service actions, the performance of systems that host services and network traffic during service interaction, and are capable of generating regular monitoring reports.
2431
promote the effective creation and use of SOA-based services
Suggestion
promote the effective creation and use of services.
MP: support Boris here!
2680
The SOA infrastructure is likely composed of several families of SOA services that provide access to fundamental computing business services. These include, among many others,
services such as messaging, security, storage, discovery, and mediation. The provisioning of an infrastructure on which these services may be accessed and the general realm of those contributing as utility functions of the infrastructure are a traditional
IT governance concern. In contrast, the focus of SOA governance is how the existence and use of the services enables the SOA ecosystem.
By characterizing the environment as containing families of SOA services, the assumption is that there may be multiple approaches to providing the business services or variations
in the actual business services provided. For example, discovery could be based on text search, on metadata search, on approximate matches when exact matches are not available, and numerous other variations. The underlying implementation of search algorithms
are not the purview of SOA governance, but the access to the resulting service infrastructure enabling discovery must be stable, reliable, and extremely robust to all operating conditions. Such access enables other specialized SOA services to use the infrastructure
in dependable and predictable ways, and is where governance is important.
Suggestion
The SOA infrastructure is likely composed of several infrastructure components including messaging, security, storage, discovery, and mediation. The provisioning of an infrastructure
on which business services may be accessed and the general realm of those contributing as utility functions of the infrastructure are a traditional IT governance concern. In contrast, the focus of SOA governance is how the existence and use of these infrastructure
capabilities enables the SOA ecosystem.
By characterizing the environment as containing these capabilities, the assumption is that there may be multiple approaches to providing the business services or variations
in the actual business services provided. For example, discovery could be based on text search, on metadata search, on approximate matches when exact matches are not available, and numerous other variations. The underlying implementation of search algorithms
are not the purview of SOA governance, but the access to the resulting service’s infrastructure enabling discovery must be stable, reliable, and extremely robust to all operating conditions. Such access enables SOA services to use the infrastructure in dependable
and predictable ways, and is where governance is important.
MP: I have undelined the words I propose to change in the original tex:
The SOA infrastructure is likely composed of
several infrastructure elements [MP: see the use of "element" in 2253 and following bullet-points]
and families of SOA services that provide access to infrastructure.
This includes, among many others, messaging, security, storage, discovery
directories, and mediation supporting systems. The provisioning of an infrastructure on
which services may be accessed and the general realm of those contributing as utility functions of the infrastructure are a traditional IT governance concern. In contrast, the focus of SOA governance is how the existence and use of the services
enables the SOA ecosystem.
(MP: I agree with Boris in only one place in this paragraph:)
By characterizing the environment as containing these capabilities, the assumption is that there may be multiple approaches to providing the business services or variations in the actual business services provided.
For example, discovery could be based on text search, on metadata search, on approximate matches when exact matches are not available, and numerous other variations. The underlying implementation of search algorithms are not the purview of SOA governance,
but the access to the resulting service infrastructure enabling discovery must be stable, reliable, and extremely robust to all operating conditions. Such access enables other specialized SOA services to use the infrastructure in dependable and predictable
ways, and is where governance is important.
3087
· Common security services include:
o services that abstract encryption techniques;
o services for auditing and logging interactions and security violations;
o services for identification;
o services for authentication;
o services for authorization;
o services for intrusion detection and prevention;
o services for availability including support for quality of service specifications and metrics.
Suggested
· Common services security support include:
o encryption;
o auditing and logging interactions and security violations;
o authentication;
o authorization;
o intrusion detection and prevention;
MP: I suuprt Borin in here! BTW "services for availability including support for quality of service specifications and metrics"
do not relate to security. Also, encryption should be performed, not abstracted, and difference between authentication and identification will require a lot of explanations to justify their separation in the list.
3181
Combination Manageability
of a service addresses management of service characteristics that allow for creating and changing combinations in which the service participates or that the service combines itself.
Known models of such combinations are aggregations and compositions. Examples of patterns of combinations are choreography and orchestration. Combination Manageability drives implementation of the Service Composability Principle of service orientation.
Service combination manageability resonates with the methodology of process management. Combination Manageability may be applied at different phases of service creation and
execution and, in some cases, can utilize Configuration Manageability.
Service combinations typically contribute the most in delivering business values to the stakeholders. Managing service combinations is the one of
the most important tasks and features of the SOA ecosystem.
Suggested
Composability Manageability
of a service addresses management of service characteristics that allow for creating and changing combinations in which the service participates or that the service combines itself.
Examples of patterns of composability are choreography and orchestration. Composability Manageability drives implementation of the Service Composability Principle of service orientation.
MP: I would agree with Boris here.
MP: I disagree with Boris he and prefer keeping removed sentence.
Service composability typically contribute the most in delivering business values to the stakeholders. Managing service compositions is the one of
the most important tasks and features of the SOA ecosystem.
MP: I would agree with Boris here.
3240
In a deployed SOA-based solution, it may well be that different aspects of the management of a given service are managed by different management services. For example, the
life-cycle management of services often involves managing service versions. Managing quality of service is often very specific to the service itself; for example, quality of service attributes for a video streaming service are quite different to those for
a banking system.
Suggestion
In a deployed SOA-based solution, different aspects of management of a given service can be combined together. For example, the life-cycle management often involves managing
service versions. Managing quality of service is often very specific to the service itself; for example, quality of service attributes for a video streaming service are quite different to those for a banking system.
MP: suggestion:
In a deployed SOA-based solution, it may well be that different aspects of the management of a given service are managed by different management services. For example, the life-cycle management of services often involves
Version Control service that manages service versions. Quality Service Control service manages quality of service based on specifics of the service itself; for example, quality of service attributes for a video streaming service are quite different to those
for a banking system.
3426
Monitoring in a SOA ecosystem is enabled through the use of mechanisms by resources for exposing managed aspects. In the SOA framework, this mechanism
may be a service for obtaining the measurement. Alternatively, the measurement may be monitored by means of event generation containing updated values of the managed aspect.
Suggestion
Monitoring in a SOA ecosystem is enabled through the use of mechanisms by resources for exposing managed aspects. Alternatively, the measurement may
be monitored by means of event generation containing updated values of the managed aspect.
MP: I disagree with Boris' suggestion here.
3435
Management services must be capable of handling these different approaches to monitoring.
Suggestion
Remove the sentence
MP: I disagree with Boris' suggestion here.
3441
In the SOA framework, reporting is provided using services for requesting measurement reports. These reports may consist of raw measurement data,
Suggestion
In the SOA framework, reports may consist of raw measurement data,
MP: I disagree with Boris' suggestion here.
3448
Each managed capability imposes different requirements on the capabilities supplied by the infrastructure in SOA ecosystem and requires that those capabilities be usable as
services or at the very least be interoperable.
Suggestion
Each managed capability imposes different requirements on the capabilities supplied by the infrastructure in SOA ecosystem and requires that they will be interoperable.
MP: suggestion:
Each managed capability imposes different requirements on the capabilities supplied by the infrastructure in SOA ecosystem and requires that those capabilities
be accessible via specialized interoperable services
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.
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.
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.
|