Archive for July, 2009

muSOAing for 7/28/09

July 28, 2009

Ok enough of Pontification. In all these preceding posts we have talked about various aspects of SOA focusing mainly on the strategic aspects such as Governance and Design. We haven’t spoken at all about actual services development. As they say there cannot be any Object Oriented Programming without any real objects. Similarly there cannot be any SOA without any real services that are available for consumption.

So you have traveled some distance on this SOA journey and you have come to a point where you have identified service candidates so now it is time for the rubber to meet the road, the nuts and bolts etc. How do you actually go about developing your services. There are several aspects you will have to consider for this a few of the important ones are,

– Building new services from scratch
– Reusing legacy functions thru service wrappers (EJB, Servlet etc.)
– Canonical or other Schemas
– WSDLs
– Service types (RPC or Document style)
– Service granularity (Coarse or fine grained)
– Composite services thru service composition using BPM

These are not ordered in any fashion so as to indicate priority but in the following posts, I will take them up in the order or relevance.

muSOAing for 7/22/09

July 22, 2009

Continuing our talk on SOA Governance, one may wonder where exactly does the scope lie. In my previous posts, I have discussed about the various approaches for SOA being top down/strategic efforts, bottom up/tactical and a Hybrid approach. So is the organization straight jacketed into choosing one approach before attempting SOA. The answer is an emphatic NO. The beauty of SOA is the organization can choose to implement all three approaches. There are certain aspects of the SOA, each of which can be addressed individually by one of the three approaches. But one very important fact you should always remember is, SOA is for starters, a strategic effort where business and business processes are always on the forefront.

Business needs should always be overarching and should be on the forefront in an SOA effort. When you have chalked out a broad based, enterprise wide SOA strategy then you may want to implement them using a mixture of the three SOA methodologies (strategic, tactical and hybrid).

An example of a strategic effort is SOA Governance as this affects all the aspects of SOA and lays down the rules and guidelines for all future SOA initiatives. An example of a tactical effort is a project/pilot initiative where you are dealing directly with technology. A hybrid approach is having two paralled tracks, one being service composition and development and the other being a project that uses these services.

muSOAing for 7/20/09

July 20, 2009

As mentioned in my previous post, there are several aspects to SOA Governance. There are design time considerations such as Service Design and Composition strategies. Runtime considerations such as Service versioning strategies for deployment.

Let us examine Service Versioning. As innocent as this term may sound, believe me if you have to support myriad departments and if one service is used by at least 3 or more departments, you will need a well thought out service versioning and deployment strategy.

Shared services are always tricky business. You might start out with well thought out intentions but with shared services, there are some peculiar problems. Invariably, it will always be the case where version 1.1 of the service will not be adopted by all three depts, there will always be one that will want to stick with v1.0 of the service so how you version services and how you deploy them and have two versions or n versions of the same available is very critical. Remember here that there are several tools that help you in implementing good service versioning but that is the least of your worries. The main point you have to note here is your versioning and deployment strategy. So you need very good design time and runtime tools to support you in this process.

muSOAing for 7/13/09

July 13, 2009

Governance. Before we delve into the gory details of SOA Governance, let us take a moment and examine this term at a very high level. What is Governance? This has several connotations, for some it could mean something very tactical and trivial such as implementing an ACL for a particular service to ensure controlled access. For others it could mean something very strategic such as how do we control the development and deployment process for services.

So Governance can mean different things to different people and the quirky part is each and every member of an SOA implementation takes part in and contributes to Service and SOA Governance so it is extremely important that you have a well thought out Governance Strategy.

So let us start defining what Governance is. SOA Governance touches various aspects of SOA but it’s critical constituents are,

– Service Versioning strategy
– Service Deployment strategy
– Service access control strategy
– Service composition strategy
– Service development and cataloging strategy

There are specialized tools available that let you control all these critical governance aspects. SOA Governance is so important that it has it’s own practice and tools within the SOA domain.

In the next few muSOAings we will examine in detail what these individual constituents mean and how one can go about implementing and managing them.

muSOAing for 7/4/09

July 5, 2009

What the heck is this guy doing, blogging on the 4th of July that too about SOA. Freedom from bad SOA implementations I say 🙂 No seriously, this warrants not one but several blog entries. Believe me, I have been there and there is a lot you need to know about these wrong paths to SOA.

As I would like to say, when doing SOA use the words caution and moderation liberally. It is very easy to overdo and go overboard on some of these things. The reason is, the tools make this so easy to do. When it comes to the ESB, it could be transformations, orchestrations. One thing I cannot stress enough is the need for Canonicals. A good canonical can greatly reduce the need for transformations at any level ESB or elsewhere. Same is the case with Orchestrations. One can understand that Orchestrations are needed in certain scenarios especially when you need coarse grained services or service composition but again bad service design can lead to over composition and services that are too heavy or coarse grained so give a lot of thought to service design. Over decomposition of services will lead to too much composition for orchestrations and that is a big danger.

Next, I want to focus on Governance another important aspect of SOA.