From The Founder and Senior Analyst of ZapThink

Ron Schmelzer

Subscribe to Ron Schmelzer: eMailAlertsEmail Alerts
Get Ron Schmelzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine

SOA & WOA: Article

Service Orienting BPM

Service-Oriented Process Management

In an ideal case, an enterprise architect would like to engineer the business process and the applications from scratch, but that is not the reality. Mapping the required services onto an existing application is an important activity.

If an application exists that supports required functionality, then the functionality needs to be wrapped to provide interfaces that can be exposed and used outside of the application. Service implementation will typically delegate execution to one or more existing applications and supplement it with new code.

Application Perspective
Every service can be independently designed, constructed, and maintained; hence, services provide a loosely coupled system landscape. The use of services makes the application portfolio easy to maintain. Figure 1 shows a typical application architecture that consists of services. The application architecture is composed of disparate services communicating with one another over the service bus. The salient features of this architecture are:

  • Business Process Engine: Allows for the externalization of the business process. The introduction of a separate business process engine provides a separation of business process definition and execution from service implementation, thus allowing for loose coupling in the application architecture.
  • Service Locator: Allows for externalization of the service location, thus supporting service location transparency.
  • Business Services: Encapsulate the actual business functionality.
  • Utility services: These are special kinds of business services that don't belong to a firm's core business, but can still be accessed by any client.
  • Common Infrastructure Services: Provide system and infrastructure support for business services.
Business process modeling followed by design, development, deployment, and maintenance of a robust service-oriented application infrastructure often results in upfront investment, as compared to stand-alone application development. However, the maintenance of point-to-point communication between stand-alone applications results in higher maintenance costs.

Information Perspective
The SOA implementation introduces two data repositories:

  • The data models to support service implementation(s)
  • A data dictionary for service messages, the defining message semantics of the SOA
This separation of the information perspective simplifies the enterprise data and information strategy. In an SOA implementation, the data model exposed by the enterprise application portfolio and used by internal and external processes is actually the messaging data dictionary. So there is a decoupling from the data model used by the services, hence the services can in fact use completely different internal data models as long as the data semantics they are exposing adhere to the semantic data dictionary of the enterprise. The messaging data dictionary is often much simpler than the internal data models used by the services, so integrating services through messages becomes significantly easier.

Technology Perspective
The technology perspective is the most important perspective because it forms the foundation for building enterprise scale services. It provides the framework for the development and maintenance of services. SOA requires developing an infrastructure that can be shared by many services delivering against diverse functional requirements.

It is almost impossible to throw away existing IT services and start on a clean state. In reality, services are created by integrating and extending existing applications. Components are aggregated to wrap existing applications into services.

Figure 2 shows a typical service implementation that exposes existing legacy system functionality. Like a typical EAI implementation, this implementation does not expose the functionality directly, but encapsulates the functionality in its own implementation. This enables:

  • Extending the legacy system functionality without modifying the existing legacy systems
  • Making the service more granular by combining the functionality of multiple legacy systems (or multiple interfaces of the same legacy system) and implementing additional functionality
The SOA approach differs from traditional EAI initiatives. Most EAI initiatives are driven by IT and lean more towards point-to-point connectivity of an enterprise application portfolio. SOA encapsulates existing applications into services, thereby facilitating the convergence of IT with business. Such an approach typically leads to an enterprise architecture blueprint for an organization that is aligned with business objectives without requiring the overhaul of existing applications. It is always possible to create business process through EAI using existing applications. But this leads to making the applications a part of the business process. A service as described above introduces a layer of abstraction between existing applications and processes. Figure 3 shows an example of a service-oriented architecture for an organization.

Orchestrating Service Interaction
The goal of an enterprise SOA is to build a flexible, durable infrastructure that makes it easy to integrate any set of applications at any time to solve business challenges. The SOA must make it possible to dynamically add and reconfigure services on the fly and to alter the logical flow between services as processes change. It must also be possible to use multiple interaction models between services. For example, it should be possible to use messaging semantics such as publish-subscribe to collect logging data from several sources while using BPM-style orchestration to implement long-running automated business process. In an event-driven SOA, a service is not aware of these interactions; it simply consumes and emits messages that represent events.

The enterprise service bus (ESB) provides the necessary unified middleware and the framework for hosting commercial and custom services. ESBs use message-oriented middleware (MOM) as a primary means of communication. In an ideal ESB, the messaging capabilities can be used without requiring the services to include messaging logic in their code. The messaging capabilities are configured outside of the applications.

ESBs also include intelligent routing capabilities through content-based routing. Most ESBs also come with service-oriented process engines that support complex, stateful orchestrations. In its 2003 Predictions Series, industry analyst firm Gartner Inc., said:

A new category of integration middleware called the enterprise service bus (ESB) has emerged to support the proliferation of service-oriented interactions between enterprise applications. An ESB is a standards-based integration backbone that combines messaging, Web services, transformation, and intelligent routing to reliably connect and coordinate the interaction of hundreds of application endpoints spanning a global organization.

In the same report, Gartner predicts that a majority of large enterprises will have an ESB running by year 2005.

Data transformation occurs in several different places across an SOA. Data is normalized into canonical form as it enters the SOA and manipulated via transformation as it is routed between applications and services. The normalized data format across an SOA is mostly XML. All ESBs support XML transformation through configurable XSLT-based service.

Tracking, auditing and logging are very important functions in an SOA. This is commonly referred to as BAM. Auditing data as it flows within and between organizations is a legal requirement for an increasing number of processes. ESBs can provide several service-oriented capabilities and frameworks for tracking, auditing, and logging. An enterprise SOA shares data and business logic between departments within an organization and across organizations. It creates automated processes that span multiple security and administrative domains. Several issues surrounding security arise while implementing SOA. Most organizations and departments within an organization have their own schemes for authentication and authorization of users. Similarly, there may be different encryption requirements either at the data or the data channel level. The SOA infrastructure must be able to route data across multiple security domains and support various security schemes.

More Stories By Neeraj Kulkarni

Neeraj Kulkarni is a senior technical architect with the Technology Consulting Group of Infosys Technologies Limited. He has several years of experience in product development and implementing projects that involve EAI and Web services.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.