Business Ecology Initiative & Service-Oriented Solution

Mr Poulin,

I'd like to offer some responses to your points above. First, I'm not sure how you make the leap from what Cory said about ServiceContract to SoaML being "a clear push of SOA into Web Service Oriented Architecture". In fact, we worked very hard to have it NOT be restricted to web services but be able to handle web services along with whatever else might be out there regardless of whether it's technology related or not (i.e. HW/SW or business). As I'm sure you know, web services provide no real mechanism for bi-directional or multi-party services - services where the consumer has responsibilities if they want to participate such as using a financial planner or buying a home. In these types of interactions, the consumer has to be able to respond to requests from the provider that are triggered by initial service request. Sure, one might say this is really just two uni-directional services but that misses the fact that they're actually related and I'd say THAT is more web service oriented. ServiceContract handles not only uni-directional but bi-directional, and multi-directional or multi-party interactions. Clearly the specification is much broader than "web service oriented".

Second, with regard to ServiceContract behavior, Service Contracts capture the responsibilities of all parties to the contract. In UML, those responsibilities are operations on roles (specifically the CollaborationRoles) in the ServiceContract (modeled as a UML Collaboration). Collaborations are used because these are the primary element in UML used to define reusable interactions. It's not the contract itself that behaves, it's just a way to define the choreography between Participants that play the roles defined in the contract. The contract only captures the responsibilites (interactions) of each party should they agree to "do business" using that contract.

This also goes to your point that "Consumers are not responsible for using given interface if they do not want it". Again, this is exactly why Collaboration was used for ServiceContract. Consumer is just a role, NOT the actual Participant that may or may not request a service. However, if a Participant DOES decide to request a service that is defined by a ServiceContract, then they must live up to the responsibilities defined for the consumer (which may not have any by the way). This is no different from contracts that include verbiage such as "Company x, herein referred to as 'the buyer', agrees to...".

With respect to your criticism of Cory's statement that "The service interface uses the interface of the consumer role...The service interface realizes the interface of the provider role", unfortunately this is a necessity given the UML semantics and our desire to support bi-directional and multi-party contracts. In order to define the behaviors correctly, a ServiceInterface (which is NOT a UML Interface per se) must Realize (in the UML sense) the (UML) Interface that has the operation definitions and Use (in the UML sense) an interface that the Participant that ends up playing the consumer role will provide. That just the only real way to capture the mutual dependency. Two points here. First, this is only for bi- or multi-party services. Simple services don't require this. Second, only the roles in the Contract are linked in this way. Participants are not coupled until they decide to interact via the Contract and take on those roles (described with a UML CollaborationUse). Coupling remains low and can be done on the fly.

Next, I think you're reading too far between the lines on ServiceInterfaces and ServiceContracts. ServiceInterfaces don't need to be used with ServiceContracts. There's no dependency between the two. However, we did make them compatible so that they can be used together and many expect to do this. However, this was not driven by Web Services. It's possible to generate web services either or both of these mechanisms.

Finally, I infer from your question "where is the service itself?" that you'd like to see a "thing" that represents the "service". Me too. Everware-CBDI includes this in our SAE Metamodel and Profile as "ServiceSpecification" (see http://cbdi.wikispaces.com/UML+Profile). Unfortunately, other folks see the ServiceInterface as the "service" and still others see the ServiceContract as the "service". In SoaML, we included Capability which is analogous to what ECI calls ServiceSpecification and this fits if you say that "a Service is Capability offered by a provider to a consumer through a well defined ServiceInterface". Again, this definition works whether you're talking business or web services or whatever.

I'd encourage you to take another look at the specification without assuming we were pushing to Web Services. That was not our intent though we certainly understood that many would use SoaML to model web services and so we needed to enable that use case. If you still have issues, please submit them to the OMG SoaML Finalization Task Force and we'll resolve them to the best of our ability. Thanks.

Here are my answers to Mr. Butler. I had to put some context to make some sense to them. So, I have quoted the beginning of each paragraph from the Mr. Butler comments.

"I'd like to offer some responses to your points above..."

MP: Service Contract, according to OASIS SOA RM and RA-draft, is agreement between service provider and service consumer(s) about the use of the service. The obligations of participating parties are expressed via policies referenced in the Service Contract; the policies may be contributed by both service provider (primary contributor) and consumer(s). Service Contract is not about dialogue between parties, this task belongs to the service collaboration sphere. This is why I think that ServiceContract represented in SoaML is not in sync with referenced OASIS SOA RM and RA-draft.

"Second, with regard to ServiceContract behavior, Service Contracts capture the responsibilities of all parties to the contract..."

MP: Sorry, but this is the same issue I addressed already. I think that SoaML mixes Service Contract about the use of particular service with much wider mechanism of service collaboration.

"This also goes to your point that ..."

MP: I believe that SO environment is a consumer market, i.e. it is the consumer who decides to go with this or that service. If service cannot provide for promised SLA, consumer switches to another service. That is, in OASIS SOA, consumer is the actual Participant. It seems that SoaML (based on your comments) concentrates on the service collaboration but I sill would like to see a unidirectional service use defined clearly before going with more complex organisation of collaboration.

"With respect to your criticism of Cory's statement that ..."

MP: We are shifting into discussion bout service collaboration model here. I consider two major types of service collaboration – orchestration and choreography. The “bi- or multi-party” collaboration you describe seems like choreography because in orchestration engaged services do not need to know about the collaboration they are used in. I have my personal view on choreography with regard to service collaboration; I’ve wrote about this recently (http://www.ebizq.net/blogs/service_oriented/2009/05/service-oriented_chess_game_choreography_or_orchestration_part_1.php) and, in short, concluded that this was the worst form of service use (exactly because coupling between participating services), by it is my opinion only.

"Next, I think you're reading too far between the lines on ..."

MP: It is very simple: by OASIS SOA, Service Contract contains a list of service interfaces agreed to be used by particular service consumer. Since ServiceInterfaces and ServiceInterfaces are, probably, different entities than defined in OASIS SOA, but sound very similar, this does confuse me (and, I am afraid, can mislead other people). I have expected that SoaML would preserved the relationship defined in OASIS SOA.

"Finally, I infer from your question "where is the service itself?" ..."

MP: Indeed, I see a very strong influence of Web Services in SoaML, which, I think inadequate to the task of SO. Yes, I’d like to see a service as a ‘thing’ that works providing business functionality and RWE utilising the Capability. A Capability itself, without the ‘thing’ is clear Web Service model and strongly against it because it is just an interface technology (good for integration that has nothing to do with service orientation).

"I'd encourage you to take another look at the specification without assuming we were pushing to Web Services. That was not our intent though we certainly understood that many would use SoaML to model web services ..."

MP: I am glad we have clear understanding now. Still, I think that enabling Web Services might be done at the level of enabling ANY interface, not promoting Web Service mistakes into modelling of service oriented solutions.

As one of the authors of SoaML and the presenter Michael Poulin referenced I thought some response would be in order. One of the things that became clear in the SoaML standardization process is that there are a lot of qualified experts with different views of SOA. There was a lot of discussions about these different viewpoints, and SoaML attempts to provide a modeling framework that can encompass various methodologies and viewpoints.

One thing that we found invaluable in these discussions is examples, it would be great if Michael could provide some examples of what SOA concepts he is trying to express so we can see if they can or can’t be represented using SoaML. This will allow us to understand Michael’s methodology and make the connections to the terms and concepts of SoaML – many of which may already be provided for. In this response I will try and understand what Michael is trying to express and relate that to SoaML.

Participant: One of the concepts that seems to be at issue is participant. In the many discussions we had (and there where quite a few!), participant was one that had little controversy. Some of the SOA methodologies label people, organizations or system components as a “provider” or “consumer” – the SoaML team came to the consensus that this is overly simplistic, a particular person, organization or system can provide or use many services. The participant is the type of such a person, organization or component. The participant can play the role of providing or consuming these services. The “port” is the part of the participant where they provide or use a particular service – there are kinds of ports for the “ServicePoint” where a service is provided and the “RequestPoint” where a service is used.

Michael asked where we understand the relationship between a consumer of a service and the service – this would be the participant. The port (and the port type) describe everything the participant needs to know about providing or using the service without regard for the details of the other participants or their internal processes. What it doesn’t do is say anything about how they provide or use the service. I hope the last 50 years of architecture have taught us to separate the what Vs. the how. How the participant uses the service, inside their business or technology process, is independent of SoaML but can be described by combining the SoaML constructs with standard UML constructs for process and implementation. So the implementation – the how, is not part of the services architecture but how a particular participant may decide to provide or use a service can be expressed as part of the model – UML activity diagrams are typically used for this purpose. I’m not sure if this kind of implementation Michael was requesting, if so it is available. If, on the other hand, Michael is asking for what the participant needs to do with respect to the service, that is well described by the ServiceInterface as the port type.

Another question is the relationship between “the service”, the service contract and the service interface. It turns out that “the service” is a multi-faceted thing – it includes everything from the service actually being used at runtime to its description, offering and context. So use of the unqualified term “service” as part of the model did not seem wise. The ServiceContract & ServiceInterface are the service description (corresponding to the Oasis concept). As part of the service contract there are service interfaces that represent the provider and consumer responsibilities – by using one of these interfaces we are saying that we are playing a role in that service – either offering the service or consuming it. In that SoaML supports rich services with interactions going in both directions (or even multiple directions), the consumer of a service may have some responsibilities – just like the provider does. This gives us the possibility that both the providers and consumer have interfaces. Rich, multi dimensional service conversations are essential to support enterprise SOA.

The same service description can be used with any number of participants and participants can participant in any number of architectures. Michael seemed to suspect there was some expectation of a service only being offered in one place or by one interface – this is not the case.

Michael also distinguished between interacting with “the service” Vs. interacting with the provider or consumer of the service. While it is true that within the implementation of service consumer the identity of the provider may or may not be significant, it is still the provider that provides the service – the service contract is the description of the relationship between these parties, expressive to the extent that all you need to know is the contract, not the internals of the provider or consumer. That there is a “community” of providers and users of services provides the context for services – a crucial piece of the SOA architecture but it may not be crucial to the internal implementation. The Services Architecture looks at the “system” of participants and services rather than the implementation of any one provider or user – to us this is the essence of an architecture, to understand a system. In the case of SOA the system can be very distributed and there is no single point of control – SoaML gives us the capability to express this open collaborative system. Sometimes such a system is “inside” of a participant – which is why we use a participant architecture, SOA is not and should not be “flat”.

However, if the architect feels they know all the context this system viewpoint is not important the services architecture is not required and they can just focus on describing services and how participants provide and use them. It was also noted that this idea of architecting services draws on role analysis – on this I would plead guilty, the work on role analysis and collaborations going back over the last 25 years has been very significant in our understanding of systems and is a well grounded approach to systems of services, participants and systems of systems.

SoaML is certainly not perfect and there is certainly more to do, the way we will make progress is by understanding the methodologies that have influenced SoaML and those that should be supported. But SoaML is not intended to “lock down” any one methodology but to provide the modeling framework to unify and represent the resulting architectures. We welcome an open dialog contributing to improving our capability to architect services.

I am thankful to Cory Casanave for such concrete response and explanations. On one hand, it is a credit to me that Cory has recognised my attempt to express an SOA concept unknown to him, from another hand this concept is nothing else than the concept described in the OASIS SOA RM and RA-draft standards, which I co-author. And it is quite disappointing because the SoaML referred to those standards but, it seems, did not apply them. That is, the SoaML quotes many words from the SOA RM but either misses or transforms their sense and spirit.

For example, if we talk about Participant, I totally agree with Cory on his paragraph started with “Participant:”. Unfortunately, the paragraph addresses concerns that I did not have and does not answer my question. I believe that in service-orientated environment, including SOA, “A service is a mechanism to enable access to one or more capabilities” (OASIS SOA RM), i.e. service is the first class entity in SOA. For example, if you need to wash clothes, you go the laundry; you, as a Participant, negotiate your discounts and pick-up/delivery schedule, i.e. you negotiate the Service Contract with the provider of the service – the Reception Person – who is another Participant. However, after the Service Contract is set, neither Consumer-Participant nor Consumer-Application care about Service Provider; the only things the Consumer wants to know are: offered business functionality, results (Real World Effect or RWE), how SLA is preserved and communication interface(s). In other words, after you agree with the Reception Person, you do not deal with this person, laundry owner, laundry workers or managers; you care only about the pick-up/delivery to be done as agreed and about quality of washing. Service-oriented architecture is about services; Participant-oriented architecture is about Participants. I have found a lot about the latter and very little about the former in the SoaML specification.

Returning to the “the relationship between a consumer of a service and the service” I strongly disagree with Cory’s statement that says “The port (and the port type) describe everything the participant needs to know about providing or using the service”. To me this is a typical interface (Web Service) centric view. In the OASIS SOA spirit, the port (port type), as a part of the service interface, is the last thing the consumer needs to know because it is a technical detail describing only HOW the service may be accessed. The most important things “about providing or using the service” are WHAT the service provides, i.e. business functionality and RWE, WHY it provides these things and WHO is supposed to use them. This information exists in the Service Description, which I will talk about in a moment.

I do understand and appreciate the SoaML efforts to address the HOW part for the purpose of modelling. It is not a trivial task. Nonetheless, the positioning of the solution for this task may be done in service-oriented manner or in interface-oriented manner, which is not the same thing, and I see the interface-oriented manner in many places in the SoaML ( we know that service ¦= interface).

This leads us to the discussion of “Another question is the relationship between “the service”, the service contract and the service interface. It turns out that “the service” is a multi-faceted thing – it includes everything from the service actually being used at runtime to its description, offering and context. So use of the unqualified term “service” as part of the model did not seem wise.” I think that if one bases the work on existing standards instead of opinions (this time has passed 2.5 years ago), it is quite clear that the service is very concrete thing: it is an entity (automated, semi-automated, manual) that has its communication interfaces and its executing body (in different implementation, which are not really important until they have to be implements in this or that way); this is it. The service body utilises the capabilities” to realize one or more real world effects” (OASIS SOA RM). The service is better be accompanied (to be useful) by the Service Description. For the sake of service consumer convenience, several Service Contracts may be derived from the Service Description and adjusted by consumer’s policies, if needed. The Service Description and Service Contracts may include may different things such as execution context(s), SLA, policies, etc. – all these are not parts of the service but its constraints. That’s simple.

To me, term ‘service’ is quite qualified (vs ‘unqualified’ by Cory) but this does not mean that everybody agrees with this. The problem I see in the SoaML is in that it ‘standardises’ opinion that service is ‘unqualified term’, which I cannot agree with by all means ( especially having the OASIS SOA standards already).

Here are a couple examples: the statement like “ServiceContract & ServiceInterface are the service description (corresponding to the Oasis concept)” is simply wrong – Service Contract is NOT a part of Service Description. Another statement “As part of the service contract there are service interfaces that represent the provider and consumer responsibilities” - it is inaccurate or it changes the meaning of Service Contract. If we do not define what responsibilities are, we, at lest, must define who is responsible to whom. In the service-oriented environment, consumer does not have any responsibilities whatsoever to the service provider or to the service; it is a consumer world. For instance, if a consumer has requested the service, the service has executed and now returns the result, the consumer is not obliged to accept it (consumer can get off-line or stop listen to the service);at the end, it is the service’s responsibility to survive the case and do not hang-up due to the absence of a receiver on the opposite side of communication line.

As of “the possibility that both the providers and consumer have interfaces” is very strong and, IMO, unrealistic assumption. I would not insist on that all service consumers are services on their own and must have communication interfaces accessible by services. Even if Cory has meant service collaboration, the aforementioned statement is, at least, inaccurate.

It looks we, Cory and I, have more points of disagreement that based on service orientation vs. participant orientation approach. In particular, Cory says: “That there is a “community” of providers and users of services provides the context for services”. As a member of the OASIS SOA TC, I can confirm that this is not the meaning of service context defined in SOA RM/RA-draft standards; it is, probably a meaning of context in the Participant-oriented environment. In the OASIS SOA meaning, the service execution context is defined (standardised) as a set of business and technical policies that affect service invocation (communication with and executions of the service), it does not matter what Participants agreed on the service usage. I can go on pointing on differences but I think it is contra-productive; I hope you have got the picture already.

At the end, let me repeat what I said before: if the SoaML eventually shifts from the Participant-oriented into the Service-oriented model, I will be among the first proponents of this standard. The Participant-oriented model, probably, has its audience and objective needs, but it is not really about SOA, I think.

Michael,

I have been using SoaML in Rational Software Architect for 12 months now. Unfortunately I'm struggling to understand some of your arguments in your article and your comments.

It would be useful if you could provide diagrams that can help illustrate your points.

IBM's Jim Amsden has written a set of articles on modeling SOA using SoaML.

Part 4 of the series contains a number of screen shots that capture the key SoaML concepts.

It would be helpful if you could provide your versions of some of the key diagrams so that we can directly compare your point of view with the SoaML approach.

Some figures to consider: Figure 1, Figure 2, Figure 3, Figure 6, Figure 11

Jim's article:
http://www.ibm.com/developerworks/rational/library/10/modelingwithsoaml-4/index.html

Tony,

thank you very much for your comment.

I've read referred article and have found a little trick. If you recall what I criticised in the Cory Casanave presentation and in the standard were about:
1) definition of the Service Contract
2) inaccuracy of terminology used
3) incorrect interpretation to the OASIS SOA standard

Being in close contact with IBM, I know that some of their tools (due to commercial nature of their business) implement standards that are not necessary in line with the their own major line of thoughts. For example, Rational Software Architect and the article state:
“A specification component defines a contract between service consumers and service providers that decouples them from particular provider implementations.”
and
“The service channel connector between the invoicing request port of the orderProcessor consumer and the invoicing service port of the Invoicer provider establishes the contract between the participants. “

The first statement fully contradicts IBM's SOMA v.3 methodology and OASIS SOA standard because Service Contract is not a specification and is not programmatic entity (yet). The 'contract' as it is articulated in the statement is about INTERFACE (“that decouples them from ...”) while stnadardised Service Contract includes much more information than interfaces and much more reasons than decoupling.

The second statement, again, equals communication details to the contract, which is not Service Contract by SOMA and OASIS.

In both cases the word 'contract' is a speculation with regard to SOA. If SoaML cannot properly define and use the fundamental element of architecture, why we agree to call it SOA standard?

As a result, the standard confuses simple programmatic interface, which is a programmatic contract but nothing more, with Service Contract defined in SOA. If we use a programmatic contract like a Web Service only, we may not claim that we are doing SOA: implementations of SOA are arbitrary and none of them constitute the architecture – this is a trivial truth.

So, working with SoaML, even in Rational Software Architect, may or may not lead to the conclusion that you do SOA, sorry about this but it is the fact. However, I anticipate that you do SOA outside of Rational Software Architect' SoaML, maybe with other tool's features and implement (design for implementation) your SO solutions with SoaML

"... while stnadardised Service Contract includes much more information than interfaces and much more reasons than decoupling."

The modeling of services in an SOA solution that I am typically working on serves two purposes: 1. capture and articulate the design 2. transform design to code artefacts (using UML to SCDL, UML to WSDL etc transformations). Can you describe what additional information (other than interfaces) you suggest should be present in the model and how it would be represented both in data and in diagram form. For example, would Quality of Service be one of the additional data? How about other Non Functional dimensions - security? availability? response time?

Whilst I appreciate the fundamental need to establish standardised definitions for expressing SOA, I would be a little skeptical of its value if it did not lend itself to practical application. Thus I am trying to relate your points of view to how they would be represented in a tool such as RSA. I trust this is reasonable.

"The first statement fully contradicts IBM's SOMA v.3 methodology..."

I haven't been able to find anything in SOMA v3 that defines "Service Contract". I looked in the SOMA meta model, service specification work products and IBM SOA Reference Architecture. The IBM GBS tool SOMA-ME's meta model also does not have a representation of Service Contract. So I'm not sure where the contraction lies. I believe Jim is merely putting forward a notion that the implementation of the interface can be abstracted by a separate component to the participant.