Web Services and User Interaction

By Kaj van de Loo, SAP Labs, LLC – October 20, 2003

 

Introduction

"What is a Web service?" A year or two ago, that was the most common question asked at any occasion where Web services were discussed. Today, most people in the IT industry as well as our customers have enough of a common understanding of Web services not to have to ask that question anymore. Once we knew what Web services were, we started asking ourselves: "What can I do with Web services? What are they good for?"

SAP entered that discussion with the Enterprise Services Architecture, a high-level blueprint for how a customer can build a service oriented system landscape, benefiting from Web services technology to increase the value of the IT platform while dramatically reducing the total cost of ownership. However, the introduction of the Enterprise Services Architecture brought with it the introduction of various types of Web services and the Enterprise Services Architecture also blurs the lines between individual applications and between service producers and providers.

In this paper we will explain what types of services exist in the Enterprise Services Architecture, analyze how these services relate to existing application interfaces, and take a look at what this means for our ability to create new user interaction models.

 

Services

Let us first get the term "Web services" out of the way. A Web service is any interface that is described and can be called through the Web services standards. The standards stack is continuously growing, with some standards, such as SOAP and WSDL, being widely accepted and supported while others still are merely proposals and neither accepted nor supported by the industry as a whole. The latter create a lot of confusion, but that need not bother us here. Important to us is that a Web service is an interface that is described and called in a standard fashion. In the Enterprise Services Architecture, we assume that all communication between components is based on Web services, and therefore all services are Web services. Interesting to us are the different kinds of Web services we encounter in the ESA.

Overview of the Enterprise Services Architecture

Figure 1: Overview of the Enterprise Services Architecture (click image for larger version)

In the Enterprise Services Architecture, we have two important kinds of services:

  • Enterprise Services
    An Enterprise Service corresponds to a business event, independent of any applications. The business event is described in business terms and is typically stable over a very long period of time.
    Example: Receiving an order from a customer is a business event that can be described using terms such as "customer", "order", "product", "price", "quantity" etc.
  • Application Services
    An Application Service is a service offered by an application, i.e. calling it corresponds to events inside the application. The application service is described using exact software terms such as data elements and state transitions and it changes when the application changes.
    Example: Creating a customer order in an application is an application service that uses data elements such as "CustomerID", "OrderID", "SalesOrg", "ProductID", "OrderPrice", "OrderQuantity" etc.

It is very important to understand that these are not mutually exclusive: Application services can very well be enterprise services. This is the case as soon as the application service covers all aspects of a business event that are relevant for a particular company. This may often be the case for comprehensive services offered by large, integrated applications such as SAP's. However, please note that whether an application service is an enterprise service or not depends on the system landscape within each enterprise. An application vendor like SAP cannot "build" enterprise services, we can only strive to build application services that, for as many customers as possible, will exactly match their desired enterprise services.

A special kind of application services will be important for the reasoning in this paper, so we introduce them here:

  • Point Services
    A Point Service is an application service that was specifically designed to be used in other applications and that only covers a very limited scope of functionality and data. Because the point service was designed to be used by a wide variety of applications, it is stable over a long period of time and it is described in business terms.
    Example: Checking whether a credit card is valid or not is a service provided by very few providers today; virtually all applications accepting credit card orders are using this point service.

An important thing to remember about the Enterprise Services Architecture is that it attempts to build a platform out of a number of independently designed applications. We cannot assume that all applications are SAP applications or even that the applications have been designed to work together. This fact has a significant impact on how the services have to be defined and gives us some criteria by which we can judge a service:

  • An enterprise service should cover a complete business event and only use business terms in its interface so that it can be called from any application.
  • An application service should perform a specific business function, i.e. avoid for example a generic "change" interface, and use only such data elements that can be mapped to business terms, i.e. avoid data elements that are specific to the particular application.

So where do the enterprise services come from? The answer is that they have to be defined by each enterprise. If the underlying applications offer a wide array of application services well suited to be promoted to enterprise services, this is a fairly straightforward task. Here we can see a future selling point for any packaged application: The more application services suitable as enterprise services the application offers, the lower the TCO and the more attractive the application to a potential buyer.

When enterprise services cannot be created by simply promoting application services, they will have to be composed out of several application services, provided by one or more applications, home-grown or packaged, hosted in-house or externally by a service provider. Here we can see another future selling point for any packaged application: The more application services that lend them selves to the composition of enterprise services the application offers, the lower the TCO and the more attractive the application to a potential buyer.

It is imperative for the success of the Enterprise Services Architecture that the composition of enterprise services on one hand is easy to perform and maintain and on the other results in adequate performance, stability, reliability, security etc. – In fact this is one of the major challenges of the Enterprise Services Architecture: Defining and providing the tools for composing enterprise services.

 

Applications and User Interaction

If Web services are all about application-to-application communication, what does all of this have to do with user interaction? The answer is that a modern user interaction component, such as an iView in the Enterprise Portal, is an application in itself. Such a user interaction component is an application where services are composed in such a way to provide the user with the best tool to perform his task. For many of us at SAP, it is sometimes difficult to fully understand the difference between an enterprise service and an application service and therefore it is difficult for us to fully understand service composition. Up to now, we have been trying to build user-interface driven transactions that correspond to a business event, i.e. that in a sense are "enterprise services." We have also taken this philosophy to the BAPIs: Most BAPIs are coarse-granular services, covering all aspects of a user transaction. It has not been of any particular interest to us whether different steps within such a transaction are available to other applications as services or not. So far we have been integrating services implicitly through coding and exposing the result as a user interface, not explicitly by actually modeling the composition, i.e. we have been building integrated UI-driven applications rather than developing services and composing different user interaction components out of them.

Integrated applications vs. applications composed of services

Figure 2: Integrated applications vs. applications composed of services (click image for larger version)

Our example of receiving a customer order and the credit card verification service will serve to illustrate the difference:

  • In the Integrated Application, all business logic needed when a company receives a customer order is built into the application in the form of a user-driven transaction (or at least that is what we try to do). One of many steps in the business logic may be to verify the credit card of the customer, but since this cannot be included in the application we call the service of the service provider from within the application. This call is typically significantly different from all calls we make within our application and it is typically targeted at a particular service provider.
  • In the Application Composed of Services, the business logic is broken down into services that can be offered by independent components. The composition of these services into an enterprise service (that may correspond to a user-driven transaction) that supports the receipt of a customer order is done through explicit modeling rather than implicitly in the coding. The point service to verify the credit card is treated just like any other service. Because we have to deal with issues like data mapping in the composition anyway, we will usually be able to consume a credit card verification service from any provider.

None of these approaches can take any complexity out of the business requirements, so we cannot expect one architecture to give us simpler applications than any other; if we have to verify the credit card we need to call a service to do that. The main difference is that the second approach, composing applications out of services, makes the composition, and therefore much of the complexity, explicit instead of hiding it in the application coding. The ability to re-use services also increases dramatically.

 

New Possibilities

The way knowledge workers work and especially the way they use computers in their work has evolved significantly since the 80's. Email probably is the most common form of spreading and gathering information and by far the most common workflow system, distributing tasks among employees and passing the tasks and their results on from one employee to the next.

Similarly, the user interface of today's Web-based business applications look very different from the green-on-black terminal screens of yesterday's mainframe applications. However, the way the user interacts with the application has not really changed a lot. In both yesterday's and today's business applications, the interaction is mainly predefined by the system and centered on transactions. Although the data the knowledge worker is handling is essential to the business applications, the design of the transactions usually has little or nothing in common with the way he performs his tasks.

With the advent of Web services and service-oriented architectures such as the Enterprise Services Architecture, we now have the toolset to actually build new kinds of user interaction components. First of all, since Web services technology enables platform interoperability, we can choose the front-end tool that is appropriate for each user interaction scenario we want to support. Perhaps a professional user who is familiar with an application prefers a powerful transaction implemented in the GUI technology specifically developed for this application with many powerful features, while an occasional user prefers to perform his tasks out of a familiar environment such as his email inbox. All popular front-end tools today support or soon will support Web services-based communication, so technology no longer is a major obstacle.

Secondly, because we now will have access to a catalog of available services and these services are defined in such a way that they can be used in different contexts, we can build user interaction components (or service consumers) that are logically independent of the underlying applications (or service providers). This is the definition of loose coupling! It allows us to combine the services we need for a particular task without having to change the back-end application.

Third and last, but not least, modern user interaction technologies such as SAP's WebDynpro fully support the development of user interaction components based on services. Services can be discovered in a registry and proxies are automatically generated. The services can be orchestrated into the appropriate interaction model, and additional logic added as needed. The resulting user interaction component can be generated for different run-time environments, again giving us the choice of the appropriate technology.

 

Conclusion

In this article we have explained how Web services technology and the concepts of service-oriented architectures are related. We have also seen how an application composed out of services is different from a monolithic one and how this gives us new possibilities to develop user interaction components tailor-made for specific tasks.

The good news is that we have all the tools we need to create the user interaction our users want. Now our creativity is challenged to make the best out of it. We need to think out of the box when it comes to user interaction, sometimes abandoning the traditional way of doing things and venture into new realms. We probably will make some mistakes along the way, but the potential rewards in the form of increased user productivity are tremendous. The winners will be those who combine the recent progress in technology and architecture with a good sense of what users really want and how users really interact with applications.

 

top top