Do we have an active SOA service?

In one of the Internet discussions about "the Future of SOA" that felled into talking about Web Services and ESB (wanted to do the best but it happened as usual...), one old IBM article was quoted: "Services advertise capabilities, both offered and requested, by declaring interfaces they implement or expect other services to implement". The idea about 'requested capabilities by declaring interfaces' was, probably accidental because even in four years it is not that easy to figure out how to do this. If the authors just meant that a service interface might be requested by others, it is, probably, my fault that I have read what was not in there.
##CONTINUE##
So far, I can mention two approaches that close to the idea of 'requesting capabilities from others': one is implemented by IBM WebSphere Dynamic Process Edition and another one is developed by Ashley McNeile in the form of mathematical model of entity collaboration. IBM has used a registry where services announce requirements for particular business functionality they need a help with; those services that have appropriate capabilities can make contra-offers and be engaged into the interaction. The collaboration mathematical model assumes that collaborating entities announce their readiness to be involved into the particular collaboration; the entities can also announce their disability of unwillingness to be involved into interactions in particular time. All mentioned activities are performed by messages via interfaces, not by interfaces.

In both cases, we see a bit unusual service behavioural pattern - active service. Following the stereotype of Web-based client-server custom, we expect a service to play a passive role waiting when a consumer/requestor invokes it. But, according to Arnon Rotem-Gal-Oz and Udi Dahan, service can pro-actively search for available companion services. It is obvious that service-oriented infrastructure has to be friendly and supportive for active services to make companion finding happen. Some people think that service-oriented infrastructure has to provide a kind of registry/repository, others offer an ESB for this purpose. To me, the major question is not in how to find a companion service (though it is not a trivial task because, at least, semantic barriers may be too 'high' for successful finding) but in how to be sure that the found service is the right one, how to set an appropriate service contract with the service provider (owner/steward). What the portion of the negotiation of the service contract may be performed off-line vs. on-line, manually vs. automatically, and should I, as the active service, do it by myself vs. delegating it to a third party?

Let us assume that the service-oriented infrastructure provides for the companion search support, i.e. there is a place in the infrastructure where a 'searcher' can look up for a companion service. Now, we can look at what kind of service are likely be active and what risks are associated with an up-front service contract negotiation versus service contract negotiation within an invocation request. Before we start, I have to mention for clarity that the reason of an active service to search for companions in my interpretation differs from the reason specified by Arnon and Udi. They stay that the active service pattern responses the question: "How can you increase service autonomy and handle temporal concerns?" I believe that the essence of autonomous service is in the independence from other services, i.e. autonomous service does not need to look up for companion services, it can provide offered business functionality by itself, without external help; this is why it can work autonomously, stand alone, in isolation.

It seems to me that active services are the ones whose business tasks are set around organising different business functionality toward one 'common' goal. Actually, different pieces of business functionality may have no idea that they are used to provide for particular goal, i.e. the 'common' goal is not necessary the internal knowledge of the business functionality. The typical candidates for such organisational role are:

• business service that is implemented via process implementation (hereinafter, service-process),
• business service that is implemented as aggregations of other services,
• business service that manages collaboration (e.g., orchestration) of other services.

When we deal with aggregate or composite services, the participants of the aggregation are usually known. That is, we have an opportunity to perform the service contract negotiation up-front, off line and, thus, mitigate the risks of inability to reach the 'common' business goal. When it is a service collaboration, i.e. predefined procedure with one or several business goals, the knowledge of this goal may be as in each of the collaboration participants (type of choreography) as in the organising entity only (type of orchestration). In both cases the participants are pre-known and the service contracts may be agreed up-front as well, i.e. the risk incompleteness for the overall goal may be mitigated (a discussion about reliability of choreography vs. orchestration from the goal attainability may be found here).

A service-process is more interesting for our case. Such service has a business goal that is the business goal of underlining process at the same time but, as any other processes, the service-process does not care how its process actions are implemented and who does it. From another hand, inappropriate provider of the process action, e.g., unreliable, disrespectful, competitive, incompetent, volatile, associated with undesirable side-effects, etc. companion service can easily screw the entire process. In other words, a risk of involving a companion service to provide process action without preliminary due diligence is very risky. Even in the same organisation, if a potential companion service is under different ownership or administrative authority, the process may not blindly relay on such companion service.

Therefore, a service-process that has announced its functional needs to others has one of the following choices:

a) the service-process has all companion service pre-defined with appropriate service contracts for the cost of loosing flexibility of the solution (the flexibility is in the process ability to take an arbitrary provider as the process action implementation),
b) the service-process has only those potential companion services (gathered in some place(s)) that already have appropriate service contracts, i.e. 'trusted' services,
c) the service-process can negotiate service contracts with potential companion services on-the-fly, during the invocation requests of a companion services.

The option c) leads to the risk of search/negotiation failure. Available at the moment potential companion services may be not suitable in some aspects for the service-process. The option a) is clumsy; a lost of flexibility in service-oriented solutions is unacceptable. We have left ourselves with the option b) only.

For this case, the service-process can submit its functional needs to an intermediary or to a third party (within the service-oriented infrastructure) and delegate it the task of negotiation with potential companion services ahead of the service-process execution (or deployment). The only service contract the service-process must have is the contract with the intermediary. In turn, the intermediary becomes an authorised agent for all companion services it represents. In other words, such intermediary becomes a 'trading' or dispatching aggregate service whose task is to find suitable companion services and agree with them on the business functional needs obtained from the service-process.

Summarising the discussion, I can say that the active service has to have service contracts with either pre-defined collection of companion services or a service contract with an intermediate aggregate service responsible for the companion services. In both cases the activities of the active service get narrowed to traditional up-front service contracts with companion services. So, considering the risks in common goal achievement, do we really have a pattern of 'active service' or it is an unrealistic model? Or it is the intermediate aggregate service becomes an active service now...

-----------------------------
BY Michael Poulin
Source：ebizQ

Michael Poulin is an enterprise-level solution architect working in the financial industry in the UK and USA.

He specializes in bridging between Business needs and Technology capabilities with orientation 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. Michael contributes to OASIS SOA standards as an Independent Member; he is listed in International WHO's WHO of Information Technology (Historical Society) for 2001.

Copyright © ebizQ. All rights reserved.