We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

SoaML is about everything but SOA, part 1

Vote 0 Votes

I think I know why 'SOA' part of SoaML name is written in such unusual way. My theory is that the authors of SoaML Specification are ashamed themselves of the results of their hard work; they know that SoaML is not about orientation on service and is not fully architecture modelling language because it does not model the architecture entities in full but concentrates on the relationships between them (which is important but not enough).

We used to know that the core element of service-oriented architecture is service. OASIS SOA RM standard and OASIS SOA RA standard-draft define what SOA is, what Service is and how Service may be used in service-oriented environment. Why we need another definition of SOA/service in SoaML Specification if it refers to OASIS SOA RA already? SoaML states: "A service is a capability offered through a well-defined interface and available to a community (which may be the general public). SOA is an architectural paradigm for defining how people, organizations and systems provide and use services to achieve results." This definition roots several obvious questions like these:

- why service is offered through only one interfaces (singular 'a well-defined interface')?
- why service is available to undefined 'community' rather then to comprehensive service consumers? If there is an idea of wide use of the service behind the word 'community', why it is more important than a wide reuse of the service in different execution contexts by the same consumer (without a community)?

and one major question:
- why Participant (SoaML: "A Participant is a service provider if it offers a Service. A Participant is a service consumer if it uses a service - a participant may provide or consume any number of services") is the major role in SoaML, and where is the service if it is about service-oriented architecture?

The SoaML's definition of SOA emphasises on "defining how people, organizations and systems provide...services", which is a really new 'aspect of architecture'. So far we were concerned of WHAT, WHY and WHO with regard to architecture (i.e. about entities and their relationships), the HOW part was always delegated to the architecture implementation. It is clear that engaged MDA (Model-Driven Architecture) needs to answer HOW the service is realised but this cannot be the top priority in modelling SOA, this may be only a derivative from WHAT and WHO, in my opinion.

The stress that SoaML puts on Participant is very confusing. It appears that in SoaML the relationship between consumer and service provider is more important than the relationship between consumer and service itself. Well, if a person works for a car-maker and drives its car but it breaks every 50 miles, does the relationship between this person and the car-maker help to drive the car?

I guess that the emphasis on Participant is caused by positive intention to elevate the importance of Service Contract over the service interface that in technical jargon is articulated as a contract. Unfortunately, SoaML Specification still undervalues Service Contract.

In service-oriented environment, it is assumed that consumers interact with service based on an agreement with the service provider. In this case, 'service provider' may be a service owner, service steward, service manager, etc., while the agreement is the Service Contract.(According to OASIS SOA RM and RA-draft standards, Service Contract is based on Service Description, i.e. definition of particular service, which SoaML lacks totally.) After the Service Contract is set, the consumer does not care about the service provider but only about offered business functionality and service results - Real World Effect (RWE). That is, a service provider plays a secondary, supporting role if we are talking about architecture (business or technical). The phrase "SoaML enables business oriented and systems oriented services architectures to mutually and collaboratively support the enterprise mission" is absolutely correct but 'business oriented ... services architectures' should not be about the business (participant) per se but about the architecture of the business, i.e. about business services, functions, features and processes (all of which are almost invisible in SoaML).

To me, SoaML is a role/participant-centric model, not a service-centric model.

It is not a bold statement of mine - SoaML Specification announces a "Participant Services Architecture". I've said 'announces' because this 'architecture' is explained by the example instead of a definition; you can see it yourselves: "When a participant is "decomposed" it can contain roles for other participants that also provide and use services. In this way the services architecture can start with the "supply chain" ...and drill-down to the roles within an enterprise that realize that supply chain. The services architecture of such a participant is modeled as a composite component with both the «participant» and «servicesArchitecture» stereotypes." A «participant» stereotype is understandable but «servicesArchitecture» stereotype... I used to think that «servicesArchitecture» is just SOA itself. Also, decomposition of Participant into the roles does not necessary lead to the use of services; it is rather a business chart decomposition, which may have very little in common with the business architecture. We have a subject substitution here - instead of decomposing business model into the business architectural elements - services, functions, features, processes - SoaML plays with structure of authority, responsibilities and accountabilities. Moreover, making the roles in the enterprise a foundation of the service architecture instead of the business needs/tasks totally compromises the spirit of service orientation. In practice, the administrative role structure is one of the major obstacles on the way to realising the concept of service orientation because such structure is about authority rather than about business efficiency. That is, modelling it for the purpose of SOA is quite odd decision, I think.

However, this is not all about "Participant Services Architecture" yet. The SoaML Specification states: "In participant architecture there are frequently services connected between internal roles or between internal roles and external ports." At a minimum, I have to admit that the statement is inaccurate: it mixes roles with ports that are the items of different nature. In addition, there is no justification on "In participant architecture there are frequently services connected"; why services are here at all, why participants do not just communicate or interact by other means than services? I still do not see a necessity for any service orientation in the participant-centric 'architecture'.


Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives