How Service Oriented Architectures
Enable Business Process Fusion (part II)

by Max Dolgicer

May 2006

Connectivity

Another important aspect of a SOA is the protocol used for establishing connectivity between the client and the service. With other technologies (CORBA, DCOM, J2EE) these protocols are platform specific (i.e. Internet Inter-ORB Protocol (IIOP), Microsoft RPC (MS-RPC), and Java Remote Method Protocol (JRMP) respectively) and could not interoperate. As illustrated in the figure below, client and server are tightly bound to the same type of middleware. In fact, they have to be developed and deployed on the same commercial middleware product. Today the protocols of choice are SOAP over HTTP, which are both universally accepted, and do not create any middleware dependencies on the service consumer and provider.

In practice - of course – things are not quite that simple. Seamless interoperability requires compatibility of more than just these two protocols (it also requires, for example, message formatting based on a given WSDL file), and there have been problems connecting products from different vendors. However, progress has been made resolving these issues, in particular through the work of the Web Services Interoperability Committee (WS-I).

Coming back to our question how SOA supports fusion, universal service access protocols are another piece to the puzzle. They provide us with the capability to establish connectivity to business processes that run on virtually any type of platform. Once we have connectivity, we can then focus on the composition of a fused process that spans these platforms.

Business Process Management (Orchestration)

The development of business processes is another area where we can distinguish a SOA-based approach from object-oriented technologies. In order to address this question, we need to have a look at the different options for implementing business logic. Business logic can generally be divided into two categories. The first consists of logic that requires coding in a conventional programming language, like Java, C#, etc. Examples include numerical calculations or text manipulation, database access, and user interfaces.

The second category deals with the “fabric” of an application, i.e. the logic that ties together a number of functions into a coordinated flow of activities; in other words, the logic that makes up a business process. As depicted in the figure below, building a solution with CORBA, DCOM, and J2EE implies that this type of business logic is also implemented using a conventional programming language. Using Web Services, however, we can separate the flow logic into an orchestration layer and take advantage of graphical tools. Since there is no coding involved, these tools enable us to rapidly compose new business processes or make changes to existing ones.

Registry

The final piece of a service oriented architecture is a registry for services that allows services to publish their interfaces and access points (i.e. URL’s), and that provides clients with the means to search for the services that they would like to use. The registry approach taken by Web Services is very different compared to previous technologies. Theoretically, a Web Services registry would allow a client dynamically (i.e. at runtime, not at development time) discover the capabilities of a service and then construct the appropriate service invocation request and make use of the service.

With CORBA, DCOM, and J2EE, all we had was a name service that provided basic name to address resolution. In other words, a client could obtain the physical network address of a target object based on some abstract artifact like a class name or interface identification. Practically speaking, however, the dynamic lookup capabilities of Web Services are not very feasible in real projects, at least for now. This is due to a number of reasons that go well beyond the scope of this article.

Currently, a standardized service registry is more important at development time, when we build fused processes. They key to fusion is the integration of multiple, previously isolated business processes that span organizational and management boundaries. As a result, we have to deal with a heterogeneous development organization, i.e. application development teams that typically do not share a common development environment. These teams need a well-defined way of exchanging information about services that could be reused to build fused processes. This is where the registry is most applicable today.

Service Oriented Development Of Applications (SODA)

So far we have discussed the advancements in standards and technologies that indicate that the time is finally right for today’s SOA. Yet, in order to successfully compose services into fused business processes, the development of services must also adhere to SOA design principles. The following lists some of the key principles:

• Simplicity – a service should provide clear and well-defined functionality;
• Self-containment – a service should provide a complete business function, without involving the client in complex, interdependent conversations across multiple services;
• Statelessness - a service should not remember information about a client from previous times that client invoked the service;
• Granularity – don’t design services that are “too small”, in other words, don’t turn objects into services; at the same time, don’t make them too large, i.e. don’t create monolithic services;
• Separation of concerns – a business service should be separate from infrastructure services and it should use the infrastructure services to perform standard tasks like authentication, logging, printing, etc;
• Policy/contract – a service should have a defined policy/contract that deals with issues like security, Service Level Agreement (SLA), escalation procedures, etc;
• Focus on business value – a service should perform a function defined on a business level, and not by constraints on the IT level.

In addition to following the guidelines for service design, we also have to consider how services are combined into fused processes. In order to successfully address these issues, we need a new development paradigm. This is where SODA comes into the picture.

SODA is the development paradigm for building applications within the context of a service oriented architecture. It is focused on the composition of process flow that orchestrates services into a fused business process. This is a distinction from object-oriented development, where the focus lies on component design and coding. In contrast, SODA takes a process-centric approach to development: developers build models that closely resemble the processes that the business requires. Since the composition of fused processes is mostly accomplished through the use of graphical tools rather than coding, solutions can be created significantly faster and are much easier to change. SODA therefore helps us achieve the goals we had set out initially - moving towards the real time enterprise, and providing the business with agility and adaptability.

Conclusion

In summary, the key issue for enabling business process fusion is the move towards a service oriented architecture, supported by service oriented development of applications. Fused processes cut across the enterprise, and in order to develop them we need building blocks in form of services that have the right level of granularity. They must be accessible through universally accepted protocols that provide us with platform independent connectivity. Being able to adapt a fused process to changing business requirements mandates a loose coupling of the services, which is an important characteristic of Web Services interfaces. Finally, we need a process-centric development approach that is focused on the composition of services into fused processes that are closely aligned with the business requirements. The following diagram puts all the pieces of the puzzle together:

In closing, a word of caution: while SOA is certainly a good basis for implementing business process fusion, it also comes with new challenges. For example, service providers and consumers can fail independently, and error recovery in a network of independent services can become a complex endeavor. Change management also becomes more complex - what happens when a service that is used by a fused process changes? Also, security and management of enterprise wide processes that span organizational boundaries have to be addressed with a new approach that significantly extends the scope of how most organizations deal with these concerns.