Friday, March 7, 2008

Guerilla SOA

Jim Webber has posted a very entertaining video presentation on Guerilla SOA which although I do not entirely agree with his conclusions, is well worth the watch.

One thing Jim fails to explain is how to achieve publish/subscribe with pure WS-* on the WCF stack. In order to achieve this message exchange pattern today, one needs some kind of service bus topology.

He also talks about implementing SOA based entirely on open standards (such as WS-RM), but doesn't consider the fact that in many cases we need transactional durable asynchronous messaging.

We want the sending of a message and its receipt to be transactional, but we want the sending to be decoupled from the receipt such that the receiver does not need to wait for the sending thread to commit its transaction before it can commit its transaction.

We simply cannot have a transaction spanning two services. This is going to couple our services unacceptably. We must leverage an asynchronous messaging infrastructure such as that provided by an ESB.

Something else Jim does not consider is the need for service virtualisation and message routing. We don't want each service to have to know the location of all other services with which it collaborates. We do not want to have to configure each endpoint independently. It is well accepted that point-to-point communications are an administrative nightmare. We want a decentralised distribution model with centralised configuration.

Where I do agree wholeheartedly is that ESB technology is particularly appropriate and useful for providing an EAI capability behind the service boundary.

I also agree that putting smarts in the network (in the ESB) is a very bad idea. With SOA, the service is the top level construct and all smarts must go behind the service boundary. Once you have smarts inside the network, you are really violating your service boundaries, bleeding functionality outside the boundary. There will be a separate post on this later down the road.

In my opinion, the ESB still delivers capabilities in the fabric between services not yet matched by stacks such as WCF. Not to say that we won't necessarily get there in the end.


flgb said...

RE: "We don't want each service to have to know the location of all other services with which it collaborates [...] We want a decentralised distribution model with centralised configuration."


Bill said...

DNS gives us location transparency at the network layer, rather than at the message layer.

What this means is that if we have a few different services running on the same machine and we now wish to move just one of those services, we cannot do this via DNS.

We would still need to update each of the collaborating services' configurations so they knew the new location of the relocated service.

Anonymous said...

Re: […] that if we have a few different services running on the same machine and we now wish to move just one of those services, we cannot do this via DNS.

If the services have different hostnames you can. There’s no reason why billing.service.corp and ordering.service.corp can’t be hosted on the same machine but with different hostnames. If you move one you just update your DNS, no?

Bill said...

Good point. Although this doesn't give us knowledge of the address of each service endpoint.

Let's say our billing service has multiple endpoints, one of which is at net.msmq://billing.service.corp/private/billing_endpoint_1

The sending service will need to be preconfigured with this URL. If we want to change the endpoint location or transport used then we would need to update the configuration of all sending services.

The billing.service.corp is only one part of the endpoint address, and the only part that DNS helps us with.

Message routing resolves more than just the name of the server on which the target service is running.

Anonymous said...

Hi Bill,

Pub/Sub on the WCF stack is best done with Atom I think, rather than any of the WS-* stuff.


Bill said...

Hi Jim,

Using Atom for publish-subscribe in an enterprise context is an interesting idea. It does suffer from a few issues though:

1. There is no centralised configuration of topics and subscribers - which increases the configuration overhead.

2. You have to handle "wildcard subscriptions" manually - that is, you have no notion of topic hierarchies.

3. Each publisher must implement its Atom endpoint content manually - there is no shared infrastructure here.

4. The approach doesn't work very well when you need near real-time messaging as it is a pull model rather than a push model.

5. The subscribers must remember what messages they have processed was so they don't process messages twice.

6. There may be issues in high volume scenarios as publishers are not aware when all subscribers have received a message so the message can be deleted. You'd need to hold onto all messages for an extended period of time which could lead to storage issues.

7. There is no standard mechanism for securing published messages.

8. The publishing service must be available at the time a subscriber wishes to retrieve their notifications, which means we have temporal coupling.

9. You lose additional services such as run-time governance and business activity monitoring provided by middleware products.

In simple enterprise scenarios, none of these issues may present a road block. I am certainly a believer in using the right tool for the right job.

However when the above restrictions could present a problem, I would suggest enlisting the aid of an appropriate middleware solution.