Service-Oriented Architecture

As technologists today, we face a uniquely challenging paradox. On the one hand, Web services have created renewed excitement for service-oriented architectures (SOA) as the answer to common integration problems; on the other hand, today's application platforms (J2EE & .NET), used to implement SOA applications, are often deemed overly complex, and a barrier to widespread SOA adoption. While the primary goal of the industry is to make the concepts and benefits of SOA mainstream, we must recognize that SOA itself must evolve to facilitate such widespread adoption. Fundamentally, we must move from focusing on the integration aspects of SOA (the "band-aid") to focusing on how to build applications based on the principles of SOA (the solution); that is, applications that are inherently interoperable. In this article we discuss how the convergence of several key technologies is essential to taking SOA mainstream, and how process-oriented architectures (POA) are evolving to meet this need by providing a more detailed version of SOA that derives its fundamental purpose from a process-oriented view of application development.

SOA Defined

SOA describes an approach to distributed computing based upon three primary entities: a provider, a consumer, and a registry; and seeks to maximize certain desirable characteristics for networked resources called services. Services are the single construct used to represent a given system and are expected to be loosely coupled, modular, interoperable, compose-able, coarse-grained, network-addressable, and discoverable.

While the importance of these concepts and characteristics cannot be overstated, they are by no means new. RPC, CORBA, DCOM, and RMI are all examples of past SOA-based implementations that, though successful to some degree, were not and are not adequate for making SOA a prevailing practice. Very few IT shops had (or could maintain) the resources and skill sets required to develop enterprise applications using such technologies. The technologies were simply too complex for the majority. Or rather, resource constraints often dictated a more rapid (UI-centric) approach.

Learning from the Past

While Web services has indeed generated much excitement and debate around SOA, can it succeed where its predecessors did not? Some would argue that Web services were an inferior technology to alternatives such as CORBA or DCOM because those technologies already provided many of the enterprise-level features that are currently being developed for Web services. Yet much of that debate has subsided, as Web service specifications have been created to address those concerns. Furthermore, Web services has the distinct advantage of support by all of the dominant vendors in the software industry to an unprecedented extent.

Still, we are plagued with the problems of the past, in that Web services and SOA alone do not overcome the complexities and challenges of developing applications on today's platforms. Moreover, the industry is still focused on "band-aiding" stovepipe applications, rather than providing the solution for not building them initially. Just having a standard distributed computing technology does not make it substantively less complex for developers to design, build, deploy, and maintain enterprise applications that are inherently interoperable. We still need to implement the business processes behind the services. Today, that means writing code on either the J2EE or .NET platform.

Convergence: Process, Forms, and Data

Another distinct advantage that Web services have is timing…meaning that we are now at a point in time where several key technologies- including Web services - are converging, with XML serving as the common basis. Integrated into a single platform these combined technologies can significantly drive the adoption of SOA concepts into mainstream application development.

Back-End Service Orchestration (Process)
The most notable of these technologies is business process management (BPM), which is concerned with the design, deployment, execution, maintenance, and monitoring of business processes. Business Process Management Systems (BPMS) are design-driven environments for adding functionality to the organization. They execute business processes that consist of one or more activities which may span across multiple systems, with the purpose of achieving a particular goal for the organization. Web services are a natural fit with BPM. Processes designed in a BPMS can be automatically published to a registry and made available as a Web service, making the BPMS a Web service container. Alternatively, processes designed in a BPMS can consume coarse-grained Web services as a step in the process.

Several XML standards are being worked on concurrently that focus on the orchestration of Web services. The front runner is the Business Process Execution Language (BPEL), submitted jointly by Microsoft and IBM to the OASIS standards committee. It is said to have combined the best of both Microsoft's and IBM's prior technologies (XLANG and WSFL, respectively).

It is important to note that BPM has not traditionally been used within the scope of application development. Instead, BPM technology has focused on a subset of business processes - "integration" processes. The core processes that exist at the application level have been left behind, hard-wired into stovepipe applications.

Figure 1 shows how the combination of BPM and Web services can affect the traditional application stack.

The business logic layer as we know it is split into two layers: the process layer and the service layer. The latter still manages the majority of business logic and may contain both coarse-grained Web services that initiate long-lived processes, and fine-grained services that execute within the container. The process layer, however, provides a new layer that contains the logic used to orchestrate services in the lower layer. This logic was previously scattered within both the business logic and presentation layers.

Front-End Information Gathering (Forms)
The Web services and BPM combination provides a perfect solution for back-end service orchestration, but falls short in a key area of application development - gathering information from front-end users. Electronic forms (E-Forms) technology fills that gap by treating user interactions as componentized, reusable assets that collect information from end users to be validated against business rules, utilized for routing and controlling the flow of work, parameterized and marshaled into service calls, and then rendered in yet another form. E-Forms typically offer:

• Design-driven environment
• Platform and device independence
• Offline capabilities
• Richer data structures than name-value pairs offered in HTML
• Security features, including encryption and digital signatures
• A predictable on-screen and printable appearance
• Component-oriented capabilities

E-Forms will be essential in driving widespread adoption of SOA in application development for the following reasons:

• Interoperability: Development tools have historically relied upon various presentation technologies, whether a host programming language such as Visual Basic, or a tag-based framework such as Java- Server Pages, to create forms for user interactions. For developers this reliance on a particular presentation technology introduced the problem of constructing multiple versions of a form - one for each presentation technology/layer used in a single application. Creating different versions of a form for different technologies and devices that in the end interact with the same underlying business processes engenders extra development and expensive maintenance costs related to cross-platform consistency, and complicates the problems of configuration management.
• Orchestration: Development tools currently lack an effective way of managing (other than hard-wiring) the relationship between forms and back-end services. Similar to Web services, forms should be treated as componentized assets that can be reused across various contexts. A BPMS provides an effective solution for utilizing these assets to model complex flows of interactions that involve one or many users, either sequentially and/or in parallel. Leveraging both Web services and E-Form technologies, a BPMS could weave together various front-end user interactions with back-end services to form one or more business processes.

There are three primary competing XML-based technologies in this area, including Adobe's PDF/XML Data Package (XDP) technologies, the W3C's X-Forms specification, and Microsoft's InfoPath product. Adobe's experience and breadth of technology in this area gives it a clear advantage; various vendors of all sizes are looking towards and implementing X-Forms-based solutions, while Microsoft can definitely be expected to integrate its InfoPath product deeper into its office and back-end solutions.

In Figure 2 we add E-Forms to the Web services and BPM mix to further extend the application stack. The key distinction here is that front-end user interactions used to gather information are separated out of the presentation layer as componentized assets in the interaction layer to be orchestrated by the process layer.

Business Objects (Data)
If you are developing enterprise applications, you inevitably have to store the data related to the objects that your underlying processes are utilizing and/or affecting. These objects, often termed Business Objects, are typically complex data structures used to store data that is needed by the process, part of the process, or used to notify management about the status of a process. The design and management of these objects was, in the past, left to the sole discretion of the database administrator. However, as database technology has advanced in both speed and ease of maintainability the lines between database design and application development have blurred. This has largely been driven by the need to develop and adapt applications more rapidly, but also due to the more complex data structures and constraints needed in today's environment.

Two technologies are of keen interest in this area. The first, business object modeling tools, has evolved from pure relational modeling tools used by database administrators into design-driven environments supporting newer object-oriented methodologies used in application development. The second, object/relational mapping frameworks, provides a runtime environment for managing and storing objects used in applications by mapping their properties and relationships back to relational (and sometimes nonrelational) data stores. Together, these technologies can be used to facilitate both the design and runtime aspects needed to support the growing complexity of data structures and constraints needed in today's enterprise applications.

Several XML standards, including XML Schema, XPath, and XQuery will play an essential role with respect to business objects. While XML Schema is used for defining complex data structures, XPath and XQuery provide a standard means of querying against those data structures.

POA: The Next Step for SOA

Together these technologies are representative of the three dimensions of Model-View-Controller (MVC), a popular software design pattern. MVC has typically been limited solely to the presentation aspect of applications, but when applied within the context of these technologies it produces a powerful design-driven platform for orchestrating both services and user interactions. The end result provides the blueprint for a more detailed version of SOA that derives its fundamental purpose from a process-oriented view of application development. This evolved architecture has been termed process-oriented architecture (POA) and is the key to taking SOA concepts mainstream. POA differs from SOA in the following respects:

• Focuses on both the "what" and the "how" with respect to services
• Is an application architecture not an integration architecture
• Focuses on the constructs that make up an application, not only the connection points
• Affects our methodologies used for application development, not just the underlying technologies

POA picks up where SOA leaves off by facilitating the rapid application development of complex enterprise applications that inherently exhibit SOA characteristics such as interoperability, modularity, reusability, and scalability. While these have always been desired characteristics of enterprise applications, past application architectures have simply been too complex for them to become a reality. As a result, organizations have purchased hard-wired packaged applications, developed their own stovepipe applications, or simply chosen to do nothing because an implementation may not have been economically feasible.

A fundamental notion of POA is to address this complexity, the root of which stems from translating business requirements into the underlying technology of the day. There are at least two primary points of translation in enterprise application development (see Figure 3).

The first represents an impedance mismatch, a semantic difference in how a business domain expert and an application developer view an application. The second represents the translation between an application developer's view and the underlying (but often disjointed) technologies required to support enterprise applications.

J2EE and .NET have been somewhat successful in making enterprise application development less complex. With these platforms, more people today can participate in building enterprise applications that leverage what were once very specialized technologies. They succeeded in bringing cohesiveness to many of the underlying technologies required for enterprise applications by providing an application model that abstracted away many of the complexities and better correlated the underlying technology with the IT perspective (see Figure 4).

Still, a problem exists in that these platforms are still too complex for mainstream developers. Many applications are being developed with process and business logic scattered throughout the presentation tier and with little forethought into the basic tenets of SOA: interoperability, modularity, reusability, and scalability.

POA implementations build upon and leverage the success achieved by current platforms to make those basic principles of SOA available and feasible for the majority rather than the few by:

• Defining a process-oriented application model that formalizes and integrates the relationships between processes, forms, and data.
• Providing additional run-time and design-time services to support that application model.

Figure 5 depicts a POA platform from a high level.

The important difference when compared to mainstream platforms is the direct correlation between the business perspective and the underlying technology. In reality, the IT perspective is still there, but the two perspectives are merged along with both of their respective techniques and methodologies. The end result is an architecture that enables organizations to build applications in a design-driven environment using business - rather than software - constructs.

Looking at the various levels of convergence occurring in the market today, one can see that movement toward this vision is already underway.

Conclusion

While the convergence of BPM, E-Forms, and business object technologies into a single design-driven platform for developing and executing enterprise applications has many inherent benefits, such as reduced application development time, decreased application TCO, and overall increased business automation, we will limit this discussion to a topic particularly relevant to today's environment - bringing control back within the organization.

It is no secret that organizations across the globe have dramatically stepped up outsourcing the development of enterprise applications. And, based on the inherent complexities in application development we highlighted here and the economic realties they cause, it is no wonder why this phenomenon is occurring. However, outsourcing does not come without a price. As companies become highly dependent and coupled with external development organizations that may not have the same interests or goals in mind, they will lose a significant amount of control and knowledge with respect to the processes that are being outsourced.

Based on the material presented here, we should ask ourselves several questions: What if developing interoperable, scalable, and maintainable applications did not have to be complex? What if you could actually see the "best practices" in your packaged application? What if these "best practices" were no longer hard-wired processes, but instead templates for businesses to customize? What if you could see and manipulate the processes within any application at any point in time? And finally, what if the business value gained by organizations having real-time control of their enterprise processes exceeded the cost of developing and deploying the related applications? These are the questions we should be trying to answer and that form the objectives of POAs. No one debates the importance of SOA; however, it does not begin and end with integration. The beauty of Web services is that it answers the integration question for us, allowing us to instead focus on how we implement our business processes and bringing control back within the organization.