Dotmad.net

I went to a presentation organized by SRL and delivered by Mr. Brent Carlson, CTO and co-founder of LogicLibrary, on “New methodologies and governance in SOA implementation“.

The event was well-organized, and the Mr. Carlson focused on explaining how to avoid SOA becoming ABOS (A Bunch Of Services), by managing (governing) the process of creating those services and making sure the organization re-uses it’s pre-existing resources.
Of course the presentation led to the Logidex application, with which the governing mentioned above can be done. It seems this is relevant to very large organizations, not medium and small companies.

Although he gave me some ideas to consider, I was missing two things:

1. An actual demo of the Logidex product
2. How it fits with TFS (I got the impression it takes over “higher functions”, using TFS as a plain source control solution)

I looked around, and found a webcast from 2004 explaining the product itself, an article containing some of the material he presented, and what looks like a previous version of the presentation.

I took a couple of photos, but it seems my cell’s camera can’t handle semi-lit rooms very well.

Update: Arnon’s post regarding the event reminded me one of the key ideas from the presentation - you should think of each service as a complete product, which users/customers etc.

Something I heard in few SOA lectures I have been to was the question “how do I decide which services are in the system?”, to which there was never an easy answer.

Breaking the system into those services is not an exact science, so two architects may come up with a completely different set of services for the same system.

Udi Dahan talked about a simple method in an ARcast he did few months ago, mainly using transactions to define services - since distributed transactions are complex by nature, you should avoid them, so if you need a transaction for a set of actions, you should bundle that set into a service.

I think most developers in the .Net world have already heard about Service Oriented Architecture (SOA), which is the idea of breaking the system into individual autonomous components, each one in charge of handling specific tasks.

A SOA buzz phrase I recently heard a lot about is the Enterprise Service Bus (ESB).
Basically ESB is a middle ware which handles all message traffic to/from the services in the system, so each service only needs to be connected to the ESB and needn’t worry about communication stuff.

Microsoft is currently pushing the use of their Biztalk product the the ideal ESB technology, but there are many alternatives, including building your own custom ESB.

ESB is not a silver bullet, using it will not solve every possible problem in a system designed with SOA, but sometimes it may make your life easier.

Here is some reading material on the subject:

Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture (IBM article)

Microsoft on the Enterprise Service Bus (ESB) (MSDN article)

Microsoft’s Enterprise Service Bus (ESB) Strategy (Blog posts of a Microsoft architect)

ESB vs. Biztalk