Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

Do we have an active SOA service?

user-pic
Vote 0 Votes

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.

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...

Reference Lable.JPG

10 Comments

| Leave a comment

Hi Michael,
In my eyes an active service means that there's at least one active thread in the service and it doesn't work just passively.

Regarding the problem you mention - that has to be solved the same way whether the service is active or passive - you need to "somehow" know which services you go to to provide the complete service functionality.

There are several strategies for that - one is to take that knowledge out of the service (e.g. using choreography or orchestration), providing a subscription and/or wiring infrastructure i.e. something that will tell you where to find certain contracts, hard coding , registry , using uniform interfaces (e.g. REST) etc.

The active service is a strategy to help lower the latency on calls to the service it doesn't in itself solve the problem of how to get the needed information

Arnon

user-pic

Arnon, thank you very much for the comment; I could only hope you noticed the post.

In what you said: "In my eyes an active service means that there's at least one active thread in the service and it doesn't work just passively", I see, at least, two things:
1) an active thread runs when service executes; when service is in between last response and new request, we cannot assume that there is any active threads. Does it mean the service becomes 'passive' in this state? In a passive services, there may be many active threads running during the service invocation.
2) what does mean "and it doesn't work just passively"? How does it work then?

I think that given description of an active service is not accurate unless you take just alive service (vs. dead, not working) in the registry as active.

As of strategies, I disagree (may be my definition of active service is quite different than yours but I tried to explain it in the post). You put all things as strategies while, e.g., registry is a place where to look into but I am talking about the intent to look (does not matter where); uniform interfaces also have nothing to do with active/passive looking.

My point was that a service-process has natural need/intent to look for process action providers and even in this perfect example of active service the 'look' ends up in trivial regular interaction and service contract with the intermediary that guarantees my service-process good quality of to-be-found companion services.

Sorry, but I have not got your last statement on "to help lower the latency on calls to the service"

-Michael

You mention in the post about the different definitions of active service but I thought it might be worth backtracking to Arnon's definition.

My reading of the active service pattern in Arnon's book was that it was about designing services that were able to trigger their own behavior as required. So it might be as simple as making the service do something periodically (calculate fees monthly), or it might be for it to do something that its other quality characteristics require (go out and get client information every 5 minutes and cache ithe results). In each case the service just has to ensure it has a thread around and that the behavior is triggered as and when required.

It is obvious, even in this short discussion we have two approaches and definitions of ‘active service’:
a) service view - a service that actively looking for companions to complete its own task
b) consumer view – a service which triggers its own execution by itself

From the service view, there is a nuance: if a service knows up-front what companions to be used and just invokes them (as current definition of choreography suggests), it is not an active service. However, if the service is looking up for the companions when/if their functionality is needed, we can say it is an active service.

From the consumer view, self-triggering (live thread) is not enough for the definition of active service, IMO. Like Colin Jack described, a service can “go out and get client information every 5 minutes and cache the results?; should we assume that the service is looking for the consumers (‘clients’) following its own initiative (which is horrible because it compromises the idea of service) or should we assume that this service was initially invoked by the consumer? In the latter case, it is a regular passive service with a call-back feature. The only case I can imagine for the active service that starts working by itself is the scenario where the active service ‘talks’ to an intermediary that, in turn, is accessed by implicit service consumers. That is, if consumers do not initiate the service execution and, at the same time, the service stars to execute, the consumers and the service need an intermediary to interact. The Pub/Sub service interaction pattern fits into this scenario very well.

Thus, from the consumer view, why we need additional ‘active service’ pattern if we have Pub/Sub already?

It is obvious, even in this short discussion we have two approaches and definitions of ‘active service’:
a) service view - a service that actively looking for companions to complete its own task
b) consumer view – a service which triggers its own execution by itself

From the service view, there is a nuance: if a service knows up-front what companions to be used and just invokes them (as current definition of choreography suggests), it is not an active service. However, if the service is looking up for the companions when/if their functionality is needed, we can say it is an active service.

From the consumer view, self-triggering (live thread) is not enough for the definition of active service, IMO. Like Colin Jack described, a service can “go out and get client information every 5 minutes and cache the results?; should we assume that the service is looking for the consumers (‘clients’) following its own initiative (which is horrible because it compromises the idea of service) or should we assume that this service was initially invoked by the consumer? In the latter case, it is a regular passive service with a call-back feature. The only case I can imagine for the active service that starts working by itself is the scenario where the active service ‘talks’ to an intermediary that, in turn, is accessed by implicit service consumers. That is, if consumers do not initiate the service execution and, at the same time, the service stars to execute, the consumers and the service need an intermediary to interact. The Pub/Sub service interaction pattern fits into this scenario very well.

Thus, from the consumer view, why we need additional ‘active service’ pattern if we have Pub/Sub already?

"should we assume that the service is looking for the consumers (‘clients’) following its own initiative (which is horrible because it compromises the idea of service) or should we assume that this service was initially invoked by the consumer?"

I'm thinking of scenarios where to complete some piece of work we'd be invoking service A and where to service the request service A would go and ask for something from service B. If service A was an active service, and the situation suited it, we could have service A get what it needs from service B in advance of any consumer making a request to service B.


"That is, if consumers do not initiate the service execution and, at the same time, the service stars to execute, the consumers and the service need an intermediary to interact. The Pub/Sub service interaction pattern fits into this scenario very well."

To make sure I'm following, you are saying it can work in situations where the consumer accesses an intermediary, in those scenarios the active service would be active in updating the intermediary.

Yes, Colin, "the active service would be active in updating the intermediary". Here is an example: a service sends messages to the MOM Destination - intermediary (Topic or Queue); the service does not know who and when subscribed to the MOM Destination. The service consumers get messages from the MOM Destination.

The difference between real MOM and SO Pub/Sub is in that service consumers better have Service Contracts with the service provider about the service (beforehand); in MOM, sender and receiver may know nothing about each other.


Getting back to the first example of A and B services, I consider service A as passive. It is unclear in your scenario when and why service A would go for service B w/o any actual needs, i.e. requests. If you think about a process with services as process actions, the process may just know about companion service up-front but until the process starts (by external trigger), no services are actually invoked, IMO.

I stated writing a comment but it got too long so it ended up as a post - http://www.rgoarchitects.com/nblog/2009/05/28/DoWeHaveAnActiveSOAService.aspx

user-pic

@Arnon (Repost of reply on your blog in the interest of discussion)

Is it possible that what you refer to as "active service" is really a service host? albeit a specialized service host.

IMHO, I think this kind of active service/service host is really a BEPL engine of sorts. I see Michael's point about not liking the service view and consumer view mainly because it doesnt answer some important questions
1. How will such an active service scale i.e. How is a load balancer to determine which service is ready based on its completion of prefetch of cachable data?
2. How can one manage/govern an active service i.e. what if it decides to match up with a rogue service that takes up all of its cycles. Plus it violates the autonomous aspect of the service,how is a service to determine a reasonable SLA without knowing about the campanion service.

Also When would you say the constantly spinning CPU cycles in the service is justifiable?

Dilip,
if I have understood you post properly, you target it to Arnon.

On my side, I can say that 'BEPL engine of sorts' is reflected in my post as service-process - the strong example of active service but I do not see any analogies with service hosting...

As of your question 1, I think it relates to Arnon's case where a service 'magically' pre-loads its stuff (while service consumers have no idea about when such process ends and when the service is ready to serve THEM).

In my post, I tried to answer your question 2 (please, read it again). To avoid 'rogue service', I require the active service having a Service Contract with every potential companion service beforehand. However, such Service Contracts expose companion services up-front. If an active service should not preliminary know its companion services, the only way to mitigate 'rogue service' risk is to delegate control of the companion service status/quality to an intermediary. But using an intermediary is another service pattern.

My point is that there are active service in SO echo-system but there is not Active Service pattern, it is not needed because other patterns address all needed concerns.

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

 Subscribe in a reader

Recently Commented On

Categories

Monthly Archives

Blogs

ADVERTISEMENT