Services and Agents

I often find myself thinking that "Service Agents" play an often under-estimated role in SOA. Something came up in my current consulting contract recently and it got me thinking about the importance of Service Agents in a SOA so I thought I'd share a few thoughts I have about them here.

Agents are not just proxies

When it comes to consuming many services, at least SOAP-based web services, most toolkits provide the means to generate a proxy to communicate with the service. So the first thing to clear up is that these proxies are not Agents; at least in my view, Agents have some kind of additional smarts, typically about how to interact with the service.

There are different kinds of agents

There are the I-am-working-on-behalf-of-the-consumer kind of agents whose responsibilities are centered around making life easier and/or more effective for the consumer of the service. There can be a whole host of reasons why you need a service agent to help consumers interact with the service, but the following are some very typical reasons:

  • Limited or unpredictable connectivity or simply that the consumer needs to operate in an offline mode
  • Performance problems associated with service calls that necessitates things like client-side-caching, batching requests, disassembly of aggregate results, etc...
Some very good articles on this kind of agent can be found here:

There are also the I-am-working-on-behalf-of-the-service kind of agents, whose reason for being in life is to do grunt work for the service. The perfect example of this kind of agent is Google's web crawlers: they are agents out there to help Google index the web and, in so doing, they periodically upload what they have gathered to the "search service". Sometimes agents can do a bit of both.

Now let me try to share the situation I came up with recently, and how the notion of a service agent played into the solution. Consider the following diagram:

SOA & Agents 1

This is a generalization of the real situation but the situation is, in my experience, fairly common: you have a new service you have introduced into the enterprise, in this case a "LeadManagementService" to help marketing and sales to coordinate the capture and then subsequent follow-up of sales leads. Now it is rare indeed that you can transform the whole enterprise overnight to make use of this service but it is also less than ideal if "leads" are captured in more than one place. As in this case where leads are captured in two disconnected stores: the LeadManagementService and the CallTrackingDB.

Now consider a new version of that same infrastructure with a new service agent (in orange) in place that solves this problem by retrieving "lead info" from the CallTrackingDB and uploads leads into the LeadManagementService based on what it learns from that retrieval:

SOA & Agents 2

This synchronization could happen at some regular info and likely wouldn't have to be too frequent; perhaps even daily would suffice. I see this kind of agent as an "I-am-working-on-behalf-of-the-service kind of agent"; in this case I see him as being out there gathering possible leads in other systems on behalf of the service, and then ultimately informing the service of those leads.

Also, note that I use the term "agent" loosely here. I had one situation like this before and the "service" was implemented using BizTalk and the "agent" was simply a SQL Server Job Agent that was run every night, doing a file drop based on results from a particular query it made, and the batch results in the file were then picked up by the BizTalk service via a File Receive location.

Although it doesn't show it, the "Product Web Site" consuming the service might well require the services of a pretty smart agent as well. If you consider sites like Amazon, they go to great lengths to monitor every click the user is making to determine what they might be shopping after; you could easily imagine any product/service web site doing some some detailed tracking of the user's movements in order to inform the service of possible leads; and it would likely only want to submit its leads after it has analyzed the user's full session. Sounds like an agent to me.

Agents are often services themselves

In a recent post about SQL Service Broker (SSB) I mentioned that at least one of the reasons it hasn't been as widely adopted as it should be is because of its lack of interoperability, but this doesn't have to be the case. Admittedly it's non-trivial work but SSB can still be a very powerful tool when one needs reliable long-running conversations involving open web services (i.e. either SOAP-based or perhaps RESTful). Consider the following diagram that illustrates how "Service Agents" can help:

SOA & Agents 3

That is, the "Service Agents" in this example, which are themselves services (i.e. SSB services), are responsible for helping the "Application Processing Service" carry out reliable long-running conversations with other services.

In the end, I feel that service agents are a crucial aspect to a good SOA, and are often under-utilized.