Section 12.1. The architecture of composite applications

12.1. The architecture of composite applications

This chapter is divided into two major sections. In the first section, we'll describe the architecture of composite applications in detail. In the latter half of the chapter, we'll describe the development tools you use to create composite applications.

12.1.1. What is the purpose of composite applications in ESA?

The world of composite applications in ESA goes far beyond generic definitions of service-oriented architecture (SOA) and composite applications. At the most basic level, a composite application is an application based on services provided by other applications. Using this broad definition, everything from a portal that consolidates information from several applications to an Asynchronous JavaScript and XML (AJAX) application that brings together services from many web sites qualifies as composite applications. But this definition leaves the door open for many different kinds of messes. Composite applications under this broad definition could have rigid UIs, hardcoded process logic, no systematic approach to defining services, and complex development tools. Under ESA, for composite applications to create value, our definition must be more detailed and exact.

Let's start with the UI layer. A composite application under ESA must not only have a UI layer but must have one that is easy to create, modify, and maintain. As the number of processes that are automated grows, so will the number of roles that people play in those processes, which will lead to an increased demand for UIs. If UIs are not easy to create and if the population of potential developers and modifiers of UIs is not somehow increased, then ESA cannot work. So for a composite in ESA, UIs must be easily created, adapted, and maintained, which in practice means they must be developed with modeling tools that use patterns.

The same idea holds for the process orchestration or choreography layer of a composite. If a composite combines services from service providers using spaghetti code that is undocumented and hard to maintain, the ESA promise will not be fulfilled. Changing such an application would be a slow process that could be performed only by experts. An ESA composite must perform process orchestration of enterprise services in a manner that allows the behavior of the application to be created, adapted, and maintained as easily as possible. In practice, again this means using model-driven development techniques that expand the pool of potential developers. Patterns at the process level also amplify productivity.

The service layer offers another challenge. It is possible to think of the application programming interfaces (APIs) of existing enterprise applications as services. What's wrong with using them to create composites? The problem is that first, they were not built to be reusable services, so frequently an API call has to work with several other API calls to do some useful work. Second, it may take time to figure out how an API call works and whether it has side effects. Third, API calls tend to be rather fine-grained. Each API call does a very specific thing. Tens or hundreds may need to be understood thoroughly to accomplish a particular task. A composite in ESA must be created using enterprise services at the right granularitythe right size to be a useful building block in automating processes. If the services are too small, the application using them becomes too complex. If the services are too large, they become hard to understand and cannot be easily recombined to solve new problems. Designing enterprise services is an art that relies on deep knowledge of business processes. To make ESA succeed, SAP is bringing all of the experience gained in the last 30 years of enterprise software development to this challenge.

Let's imagine that it would be possible to create services at the right level of granularity quite quickly. Another set of problems would then arise: how can you find the right service? How can you tell what a service does? How can you tell which other services are related to a particular service? Even if all of the previous problems were solved, development would not be easy or even possible without a mechanism to easily find services, understand what they did, and use them in development tools. For ESA to work, an Enterprise Services Repository must exist to fill this need and to allow developers to navigate and understand a large repository of services.

If we take a close look at services, another challenge appears. What if the customer data required by one service is different from the format used by other services? Or, even worse, what if four or five different formats for customer data are in use in a set of services? How will the translation and mapping between these forms take place? If you extend this challenge to all types of data used in enterprise applications, the translation and mapping tasks could become huge. In ESA, composite applications must use a standard set of global data types to solve this problem.

Finally, in order for development of composite applications to be possible, a large collection of enterprise services must exist and be ready to use. No matter how many tools are available for development, without an existing set of services that represent the core processes of an enterprise, composite applications cannot be created at a sufficient scale to solve a large number of problems for companies using enterprise software. Without a repository of enterprise services, composite applications are merely an invitation to a huge amount of greenfield development using a new paradigm. With a fully populated Enterprise Services Repository, composite applications become a dynamic force for evolving a business.

So, with a clear picture of how composite applications in ESA have to overcome many more challenges than the generic definition of composites, we can quickly understand the role of composites in ESA. Simply put, composites in ESA are the way that each layer of the architecture comes together to create business value. Composites in ESA are built to overcome the likely challenges that stand in the way of rapid evolution and process flexibility. Whether it is the ability to quickly create a new application based on existing parts or to fine-tune composites provided by a vendor, composite applications built according to ESA standards transform the nature of IT from a bottleneck into a strategic weapon. That is their most fundamental and most important role.

12.1.2. What is the architecture of composite applications?

How, then, do composites live up to the higher standards that ESA requires of them? The most condensed answer is that composite applications do their job through a well-designed separation of duties in each layer that allows for recombination and reuse of building blocks. Second, the construction of the building blocks in each layer relies on modeling amplified by patterns to simplify development. But how exactly does this work? Figure 12-1 gives us a complete picture.

This view of composite applications identifies the building blocks in each layer and begins to show how they work together. Our tour will start at the top of the graphic at the work center and move down to the service provider.

Figure 12-1. Anatomy of a composite application

12.1.2.1. Roles and work centers

Composite applications use patterns and building blocks in the UI to meet as many needs as possible. A user may play many different roles in many different processes. For each role, a work center exists to provide the information and functionality needed to do the work of that role. Without the standardization and common approach that a work center creates, each UI would become a training burden. Work centers may include application components such as iViews, guided procedures, analytic views, and search capabilities, all working together to help the person playing a specific role to do his job. One central element of work centers are task lists that provide the user with a clearly defined unit of work to be done. These tasks are supported by business objects in the composite or in the service provider. The work center assembles a task-specific view of certain functionality from one or more business objects so that the user can just worry about the capabilities relevant to the task. Any single user may work with a large collection of work centers. A control center provides a summary of all the work centers for a user and helps keep track of what is going on in all the work centers. (You can find a more detailed explanation of the UI layer in Chapter 5.)

Let's imagine a team management work center that a manager would use to carry out all of the tasks and activities related to a group of direct reports. The starting point for this work center would be a list of tasks that are related to the team. The list could include requests for vacation, approval of changes in benefits, or creation of new positions. Each task in the list would be supported by an activity in the work center that would be constructed to take into account how frequently a user would perform the task. Frequently performed tasks might look like a complex UI with all the functionality on one or two pages so that all the work could be performed without having to move too frequently from page to page. Tasks performed rarely would probably be implemented as guided procedures that were constructed to walk a user step by step through a process and provide assistance about what should be done in each step. A guided procedure for creating a job opening might have actions for entering a job description, approval of the job description by upper management, and assigning a hiring expert from HR to fill the job. Activity in the team manager's work center would then result in activity in other work centers playing different roles. Upper management's task list would receive any job description approvals. The task list of hiring experts in HR would get the task of hiring for a newly created job description. The control center would show an aggregated list of all of the tasks from each work center with urgent tasks highlighted, along with important information gleaned from each work center as needed.

If we take a step back from this functional description, a surprising thing occurs. We are no longer dealing with the UI as an undefined realm of unlimited flexibility. The constructs of work centers using activities, tasks, and actions built around roles provide a reusable approach to meeting the interface needs of many different applications and linking the activity of one role to another. In this manner, the work center pattern serves to reduce a huge amount of the complexity and therefore the maintenance burden. The pattern makes development much easier than starting from scratch. Developers do not worry about designing the structure and context for the UI and the information flow. Instead, they focus on how to fit the work at hand into a well-understood structure. Simplified tools based on this pattern allow business analysts to build and modify work centers.

One should remember that the work and control centers are just the beginning of SAP's use of patterns in composites. As we will discuss shortly, patterns will be used not only at the UI layer but also at the process orchestration layer. And more patterns at every level will be added as they are discovered and implemented.

12.1.2.2. Composite processes and business activities

The next level down from work centers in Figure 12-1 contains composite processes. Composite processes are those that walk a user step by step through the actions needed to perform a task or business activity. Composite processes is the generic name for the sort of automation provided by SAP's guided procedure mechanism. These processes are composite in that they use actions that may come from a variety of different sources. The first step or action in a composite process (or guided procedure) might invoke an Adobe Interactive form. The next action might use an iView from the mySAP Customer Relationship Management (mySAP CRM) system. The next might use an external web site or a UI built specifically for a composite.

The guided procedure mechanism allows the order of the steps to be changed on the fly if need be, for new steps to be created, or for new users to be assigned to tasks to handle special situations. Guided procedures help users through any sort of repeated activity, whether it be the normal set of steps to do the work of a task in a composite or a set of steps designed to handle exceptional conditions.

Guided procedures are created using model-driven development techniques. When they show up in a work center, they use UI patterns that show the user a visual representation of the step-by-step process.

12.1.2.3. Actions

The term action gallery encompasses the actions and action-UI levels of Figure 12-1. Actions are reusable abstractions of either UIs or service calls that simplify the flow of a process and associated data from step to step. An action consists of a UI or service call and the corresponding import and export parameters that specify what data is coming into that step from the previous one and what data is coming out of that step to the next. Within the guided procedure, a process flow is built out of these actions by bringing them in the right sequence and defining the data flow via the import and export parameters. Within each process step, exactly one action is executed.

Actions decouple process steps from services and UIs to allow business experts to model processes on a nontechnical level and extend steps with additional process-relevant information such as attachments or additional actions related to the steps.

Why do we need actions for guided procedures anyway? The reason is to conceal messy details involved in invoking UIs or other callable objects in a guided procedure and to provide the opportunity to add additional functionality if needed. Specifically, actions allow:

• Decoupling of the interface from implementation

• A separation of the language of business experts (Action) from the language of developers (Callable Objects)

• Reuse of one Callable Object in several different scenarios

• Addition of attachments, info actions, or permissions, which are handled on the Action level

The simplicity of actions makes it easier for business analysts to engage in process modeling.

12.1.2.4. Composite application business logic and abstraction layer

It should be clear that the mechanisms described so farwork centers, composite processes, and the action gallerycould automate a wide variety of processes, which is of course why these mechanisms were created. Composite applications must also be able to create new functionality, which is the purpose of the business objects and services layer in Figure 12-1.

Business objects in composites are used to encapsulate reusable functionality, the same role they play in service providers. And, just as in service providers, business objects may have services created on top of them. Such services would be called local services if they were going to be used by just one composite and were not going to be published for reuse by others. The term remote services refers to those provided by other service providers. Through a process known as service composition, business objects themselves can be constructed out of existing services.

The business objects and services layer is not required for every composite. It frequently appears, however, because many remote services may need to be recombined into a simple-to-use local service. Or the composite may need its own persistent data. Or some external functionality may not be available as a service and the composite may need to use an API to convert that functionality into a service. In general, the more complex the composite, the more development will occur in the business objects and service layer.

12.1.2.5. Service providers

The Exchange Infrastructure and service provider layers in Figure 12-1 show how the composite application can use remote services. The service providers expose enterprise services for reuse. Service providers also can present functionality for reuse using the Web Service Infrastructure, services based on messages defined in SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), BAPIs, or in other ways, but as time passes, enterprise services will become the most common method.

12.1.3. What are the main categories of composite applications?

Composite applications come in several different forms. It is useful to understand the differences when analyzing how to put a particular composite to work in your organization.

The first thing to understand when examining a composite is the level of complexity. Some composites are very thin and have just a UI that combines services from several different service providers. In this way, simple composites are similar to portal applications. But as more of the mechanisms of composites are added, they become more complex. Using the work center patterns and guided procedures adds another level of complexity. Adding business objects and services adds another. Sometimes you may read of a distinction between lightweight and heavyweight composites. The more that is implemented in the stack in Figure 12-1 and the more functionality in each layer of the stack, the heavier the weight of the composite.

The second distinction that sometimes is useful to consider when analyzing composite applications is the difference between frontend and backend composites. While there is no hard dividing line, frontend composites are focused on user interaction and collaboration using the work center and other patterns. Frontend composites are conversational and user-centric. But imagine instead that a composite had almost no UI layer but a huge amount of development of business objects and services, all knit together by Business Process Management modeling techniques. This is a different, more backend kind of composite. Backend composites are process-centric. They are focused on processing huge volumes of messages or managing complex, long-running transactions. Backend composites are key to the creation and development of event-driven architectures (EDAs) that greatly increase automation and only occasionally require user intervention.

Composites of any weight will appear most frequently in one of three ways:

• As custom composites built by SAP, Independent Software Vendors (ISVs), or companies for their own use using SAP NetWeaver

• As xApps, packaged composite applications that are sold by SAP or ISVs as separate products

• As part of the mySAP Business Suite solutions, which will use composite applications to extend their functionality

Other categories of composites will no doubt be invented, but knowing these categories can be useful in discussions of how to put composites to work.

12.1.4. How are processes modeled in composite applications?

The big picture of composite applications and ESA in general starts to make more sense and become more exciting when the hierarchy of modeling is more clearly understood. So far, we have talked about how in composite applications, UIs use guided procedures, a form of composite process automation created through modeling. SAP NetWeaver XI offers another modeling tool known as Cross Component Business Process Management (CCBPM), which is used most frequently in more complicated backend applications.

Guided procedures cover the simpler user-centric sort of modeling, and CCBPM handles more complicated process-oriented modeling that has less user involvement.

Another sort of business process modeling is used inside both service consumers and service providers to perform tasks that usually start and finish inside one application. These mechanisms, which exist both in ABAP and in Java, are grouped under the term business workflow.

In ESA, modeling is used at every level to simplify development, improve communication, and bring more people into the process. The modeling we have discussed so far in this chapter is focused on modeling of processes that are being automated inside an application. This sort of modeling is known as process execution modeling. It is important to keep in mind that modeling in ESA also takes place at a higher level of process components and process configuration.

Process architecture modeling is the highest level. In process architecture modeling, the larger processes of a business, such as order to cash, are broken into process components. The relationships between the process components are specified (integration scenario models), as are the interactions between them (process interaction models). The behavior of each process component, of the structure of the processes, process steps, enterprise services, and business objects, is also modeled (process component models). (Chapter 5 has a more detailed explanation of this sort of modeling.)

Another sort of modeling called process configuration modeling is used in the SAP Solution Manager to help configure processes that exist in SAP products.

12.1.5. How do composite applications use patterns?

The patterns we have discussed so far have to do with the UI. The work center pattern is a general structure for how a certain type of UI works. It turns out that patterns also appear in the processes automated in composite applications. The process patterns simplify development and amplify productivity the same way that UI patterns do, but they apply the internal structure of the application.

Patterns at the process level are continually being discovered, but there are three that will likely show up frequently in the first generation of composite applications:

• Analyze, Take Action (ATA)

• Multi-User Guidance (MUG)

• Single-User Guidance (SUG)

• Request, Process, Approve, Update (RPAU)

The ATA pattern starts with a dashboard presentation of information that allows problems to be noticed. Once the problem is discovered and analyzed, the application allows action to be taken to fix the problem.

The MUG pattern is used to guide many users working together through the steps of a complicated process. Each step can come from a different source, and the users are provided with a lot of hand-holding and contextual information to help guide them through the process. SUG is similar, but as the name suggests, SUG guides a single user through a process.

In the RPAU pattern, a request for information is sent out. Once the information is collected, it is processed or enhanced and then approved so that updates to systems of record can occur.

Warranty registration is a perfect example of a process that fits into the RPAU process pattern. The request would be a warranty card or online form filled in by the user. This information could be brought into the system and then enhanced with other information. The enhanced information could then go through a quality control step to be approved before it is used to update many different backend systems.

Another version of the RPAU process pattern for updating store-specific prices in the retail industry is shown in Figure 12-2.

UI patterns and process patterns are only the beginning. Many more patterns will be applied at all levels of composites as time goes on.

Figure 12-2. The RPAU process pattern: store-specific consumer prices