indaField

Service Oriented Architecture (SOA) is all about architectural agility and re-use. In order to facilitate the highest level of flexibility and re-use, it is best to follow strict principles. These principles should be governed by means of SOA design time governance. But what are these principles, how do they apply to a BizTalk Server ESB and how can we categorize the different types of services?

 

The 8 principles of SOA Service Design (Principles of Service Design, Thomas Erl, 2008, SOA Systems Inc. ISBN: 0132344823, Prentice Hall) are:

• Reusability – Services contain and express agnostic logic and can be positioned as reusable enterprise resources (think about the future uses and make them generic)
• Autonomy – Services exercise a high level of control over their underlying runtime execution environment (there are no other services making use of the underlying components)
• Discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted (if nobody knows about the existence of services, they will never be re-used)
• Composability – Services are effective composition participants regardless of the size and complexity of the composition (break-up larger components into smaller, more manageable and composed ones)
• Loose coupled – Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment (contract-first development of services; don’t generate contracts)
• Abstractness – Service contracts only contain essential information and information about services is limited to what is published in service contracts (the contract does not contain system level information on underlying systems)
• Standardized Service Contract – Services within the same service inventory are in compliance with the same contract design standards (by using a uniform language and applying standards notations for creating contracts, discoverability, reliability and application of governance of services will improve)
• Statelessness – Services minimize resource consumption by deferring the management of state information when necessary (keeping excessive state can undermine the availability and scalability of services)

Designing and developing services by means of a BizTalk Server based ESB according to the 8 principles of Service Design means the following per principle:

 

Principle	Applied
Reuseability	Services exposed by or published on the ESB should not be made too complex. Functionality has to be broken up into smaller pieces of functionality in order to make sure the pieces of functionality can be combined into composite services. Re-usability should always be taken into consideration.
Autonomy	Services exposed by or published on the ESB are the only services invoking the underlying components directly.
Discoverability	Services exposed by or published on the ESB should be accompanied by a WSDL containing at least all the mandatory meta data that has to be listed in the service catalogue.
Composability	Services exposed by or published on the ESB can be used to create composite services. This generally means that services should not become “monolithic”.
Loose coupled	Services exposed by or published on the ESB should use standard (WCF based) web services interfaces and not use direct API calls.
Abstractness	Services exposed by or published on the ESB should not have interfaces that require knowledge of the underlying technical systems. For instance, passing SQL query language as a parameter to a service is forbidden.
Standardized service contract	All services exposed by or published on the ESB should be described through a WSDL. BizTalk Server generates standard WSDLs (including XSD schemas) for services exposed through the bus.
Statelessness	The use of complex Itineraries or Orchestrations that keep (excessive) state should be kept to the bare minimum.

 

In order to be able to categorize services and identify their potential re-use, the standard naming conventions for the types of services should be used.

 

The following types of services can be identified in a SOA architecture:

• Utility Service (a.k.a. “Application Services” or “Infrastructure Services”); fine-grained service that performs a single function that is highly re-usable. (Examples: “send email”, “log trace”, “exception handling”, “notification”, “transform message”)
• Entity Service (a.k.a. “Business Entity Service”); business centric service that may model one or more entities in the organization such as Order or Customer, often supporting CRUD operations. These types of services are highly re-usable within the context of the organization (Example: “employee”, “purchase order”)
• Task Service (a.k.a. “Task-centric Business Service”); models a specific function that is less re-usable. It controls composition of other services. (Example: “create purchase order”, “revenue analysis”)
• Orchestrated Task Service (a.k.a. “Business Process Service” or “Orchestration Service”); models a specific process that composes or orchestrates other services. Hosted within an orchestration platform. Less re-usable because the function is very specific. (Example: “handle purchase orders”) 

Services whose functional contexts are independent of any particular business process, e.g. entity and utility services, are good candidates for increasing their autonomy (less dependence on the execution environment) and thus their re-usability.

A BizTalk ESB Toolkit Itinerary or Orchestration can be exposed as an Orchestrated Task Service (because they are hosted in an orchestration platform; BizTalk).

 

Task Services and Entity Services are services provided by BizTalk Server or by Applications (for example MS Dynamics CRM or SAP HR). Sometimes read-only access to data in databases is made possible through data (provisioning) services. These belong to the same category. Most of the times these are (read-only) Entity Services.

Utility Services are typically provided by the (Windows, Exchange, BizTalk, SQL Server, SharePoint) platform.

A well designed and architected service landscape can greatly help building and exposing agile business processes, as depicted below.

Services make use of components that are not directly exposed. Examples of components are:

• Stored Procedures and Views in a database
• .Net classes in an assembly (a.k.a. DLL)
• The pub/sub engine in BizTalk Server
• A Send Port or Receive Port in BizTalk Server

A set of services and components can be combined in a “BizTalk Application”. For example the “Order handling” application that handles purchase orders, cancellations and returns, containing all the ports, pipelines, schemas, transformation maps, orchestrations. Some of these artefacts are exposed as components, some as services.

 

Some out-of-the-box functionalities in the BizTalk Server ESB are also provided as Utility Services, such as:

• Transformation Service (invoked from within Itineraries)
• Routing Service

Once we have a clear understanding of all of the above and have educated the customer in this regard, it is time to set up SOA design time governance for the customer by means of clear guidelines for the architects and development teams. Well before we start architecting, designing and building stuff.

 

For getting enough insight in the repository of services to enable optimal re-use and being able to track (design-time) dependencies, relevant information is required to be registered in the service catalogue, per service. In a next post I’ll describe what information is needed and how you could set it up and manage & monitor it.

 

Cheers, Gijs