what Infrastructure runs SOA solutions

Lets talk about the context of what Infrastructure is needed to design and run SOA in all its totality. Note that here we are talking about more than 20 services at least in a complex business organization.

First lets take a classic look at what drives the service lifecycle before commenting on the Infrastructure:

SPECIFICATION TREE STATUS – ENTERPRISE ARCHITECTURE OWNERSHIP - Starts with “start state” and takes it to “Specified State”

PROVISIONING TREE STATUS – DEVELOPMENT & EA Team shared OWNERSHIP - Being provisioned composite state – start from Specified and takes it to Certifiable state

TRANSITION TREE STATUS – SERVICE TRANSITION TEAM OWNERSHIP - Takes from Certifiable state to Published State

OPERATIONAL TREE STATUS – SERVICE DELIVERY OWNERSHIP - Takes from Published State to Operational Composite and then to eventual retirement

Lets look at what pieces are now involved in these lifecycles:

(1) Specifications: We have come to the conclusion that an IDE is not the best place to start doing SOA service specifications. The best way to do this and keep appropriate linkages is to start off in an EA repository – which keeps the enterprise business and IT strategy, process models, application models but also service descriptions as per richer service specifications and maps both upward and downward components. Keeping this solely in an IDE is not possible

(2) Provisioning Tree: This is typically done mostly in an IDE if custom developed or proprietary development tools. But it is not uncommon to have externalized tooling to support functional testing and performance testing of service operations

(3) Transition Tree Status: This typically requires two service registries – one wherein the service specifications as well as service UDDI compliant model is pushed to which acts as a complete repository of searchable and browsable service artifacts, appropriate links are published out so that link back to service components, technology models, infrastructure models or upstream to business processes can be shown straight off the EA repository. The other registry just maintains a discoverable service list for runtime consumers and is updated back with Policy management tools on achieved QoS. CMDB deployments to cover element level linkages are down now to services. The repositories maintain status of all version of services and service specifications with their status. It is possible to do simple stuff with newer registries to automate the approval process for state movements manually or automated checks.

(4) Operational Tree Status: This is the really complicated piece and expect to have following components:

a. Business Process Orchestration or State machine engine and the related Business activity Monitoring engine

b. Enterprise service bus for mediation, routing, transformation and core messaging (as an anti-pattern for applying policies)

c. Runtime Policy management engine which can centrally manage security, performance, availability monitoring of deployed services

d. It is not uncommon to have Business rule engine separately, a complex event processing engine which can take immediate feedback loops to understand patterns amongst all the stuff which goes around and can trigger intelligent pattern recognition and somewhat cognitive behavior.

e. Sometimes large complex SOA implementations will come with Master data management solutions which publish out certified golden record as a message or provide data services from their repositories.

f. Many organizations, but not all, will have WSRP or JSR 168 compliant Portal engines which provide end user mashed-up web 2.0 interfaces as well. It is but expected that service implementations will be residing and delivered from some application server and their own database servers.

g. Monitoring all this complex infrastructure is a set of Monitoring tools – typically starting with an end user response time monitor, element monitoring, Tracer monitor, event correlations etc.

h. Since SOA also focuses on external world so much, most organizations integrate with suppliers, partners, customers etc using electronic system to system interfaces leveraging B2B Transaction engines capable of supporting EDI as a basic minimum with digital identities and certificates, transformation back to canonical formats, or even domain specific B2B protocols like RossetaNet, HL7 etc.

Note that situation can get complicated when there are more than one process orchestration engines or ESBs within an enterprise – not uncommon – and has happened fast which may or may not talk to each other very well.