The IT practice "Enterprise Services Architecture" -- as opposed to the general concept of ESA as the SAP vision...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
of an industrial strength service-oriented architecture -- is about how companies can design and deploy enterprise services from a development perspective. Of course, many enterprise services are delivered by SAP and the partner ecosystem, but there will always be a need for custom service development. To that end, this practice describes in detail the options and processes for implementing such custom services.
An important aspect of ESA is that of model-driven development. Businesses today need to react to changing regulatory, market, and business conditions very quickly. Our goal is to transform IT from an "obstacle to change" to an "enabler of change." That cannot be done, however, if all changes need to be hand-coded in the traditional way. Hand-coding is time-consuming and expensive, and does not support the agile enterprise. What we need are an architecture (Enterprise Services Architecture), and the tools and supporting technology (NetWeaver) to support that architecture, that lets business users model processes and IT implement those processes quickly with reusable services based on Web standards and well-defined business objects. We will have more to say about business level modeling of processes in our discussion of the IT practice "End-to-End Process Integration;" here we will focus on the model-driven development and use of standards-based web services.
There is only one IT scenario associated with this practice, and that is "Enabling Enterprise Services." This practice, however, has several sub-variants, namely:
* Service-based development
* Point-to-Point service-based integration
* Brokered service-based integration
* Service Orchestration
* Service-based user interface development
We will examine each of these process variants in detail, so that that you understand the individual capabilities of each.
Service-based development offers the model-driven design of services using an "outside-in" development paradigm. In outside-in development, we start with the description of the interface in a language- and platform-neutral representation (i.e., Web Services Description Language or WSDL), and use this description to generate the programming stubs to implement the service. This is perfectly in accord with the service-orientation model, in which integration (the interface) is built in from the ground up and is expressed in a completely standard, non-proprietary way.
Based on the swimlane diagram below, we can see that three processes make up this scenario variant: Modeling Services (executed in the usage type "Enterprise Services Repository"), Defining Services (usage type "Application Server"), and Implementing Services (usage type "Application Client").
Scenario variant: service-based development
Service-based development starts in the Enterprise Services Repository (ESR), which is the natural evolution of the current Integration Repository (IR) of SAP NetWeaver Exchange Infrastructure. Like the IR, the ESR contains the interface objects (data types, messages types, interfaces, etc.), mapping objects (message mappings, interface mappings, imported archives), and process objects (integration scenarios, integration processes) that are used for system to system integration. Additionally, the ESR contains the object metadata and Business Process models that are used for Enterprise Service enabled systems.
In our development process, we start by defining data types and message types; we then define (model) the business object that will use those structures and which will be the base object for our service. Examples of business objects could be purchase order, invoice, customer, material, and so forth. Next, in the same interface, we design the interfaces and operations that act on the business object and define the nature of our service. The business object, the interfaces, and the data/message types are expressed in WSDL (with extensions to accommodate objects not currently supported by the standard. Since these extended objects are used only by the SAP development environment, there is no conflict with the standard and our ultimate service can be completely expressed in a standard-compliant way). It is important to stress that we are modeling these elements at this point and not coding.
Once we have modeled our objects and have the WSDL descriptions of these, we can use them in the Application Server to create the server-side service implementation. In this process we start with the WSDL from the definitions of the ESR, and then use that as the basis of generating the proxy code on the server. Because the SAP development contains the pre-built integration logic layer, we are able to generate a significant portion of the service code, leaving as little hand-coding as possible. Once the hand-coding is complete and the objects are ready for use, we can configure the interface. In this context that means defining a virtual interface to the service, which allows us to hide or rename service parameters and customize the "face" of the service as seen by consumers (and this should not be confused with configuration activities in the SAP NetWeaver XI Integration Directory). At this point the service has been created and is ready to be called by an Application Client; that leaves just the task of creating a client to access the service.
Of course, in order to call our service we must have a client application available to call it. The client has to be able to send a properly formatted SOAP message over a supported communication protocol (e.g. HTTPS) to access the functionality we have exposed in our service. Fortunately, many modern development environments have the capability to generate client stubs from WSDL. Once the service client has generated the proxy, the client can be implemented and the service accessed and delivered.
Point-to-point service-based integration
Point-to-point service-based integration is closely related to service-based development; it describes the runtime requirements of using the developed service from a client application. Because we are talking in terms of integration, we broadly assume that this is automated system-to-system communication, though it need not be so. In fact the service can be invoked from either an interactive or automated client. But we do draw a distinction between integration and development of UI clients for our Enterprise Services; this latter case is examined in our final scenario variant for this practice (see details below).
This variant entails using your SAP system as either the service consumer or service provider for web services. In either case, the NetWeaver application
There are also two subvariants of this scenario variant, one each for the synchronous and asynchronous cases. They are really the same in terms of the swimlane, except that the last two steps apply only to the synchronous case:
Scenario variant: point-to-point service-based integration
From the swimlane diagram it is clear that there are two processes involved with this variant: Service Consuming, and Service Providing.
The service consumer invokes the proxy that was generated in the previous variant; in other words, the calling application calls out to the proxy layer with the request parameters. The proxy layer executes its service logic to bundle the request parameters into an appropriate request message structure (SOAP-XML), and the runtime engine sends the request message via the appropriate communication channel (e.g. HTTPS). In the case of the synchronous sub-variant, the calling application waits for a response message; in the asynchronous case, at this point the service consumer is finished.
The request message is received by the service provider which calls the proxy layer to extract the request parameters from the message. The internal logic of the service is then executed by the service provider. If the request is asynchronous, then the process is complete once the underlying service code executes. In the synchronous case, a response message is generated and returned through the proxy and transport layers to the service consumer.
Brokered service-based integration
In the previous scenario variant, we saw that services could be delivered or consumed directly in the SAP NetWeaver Application Server in a point-to-point manner. Providing or consuming services in this way, however, means that collaboration knowledge is not centralized in a single repository, and that forces us to develop, configure, execute, and monitor interfaces independently in each application system. However, services can also be accessed or delivered through SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), the strategic middleware platform that provides process integration and business process management capabilities for SAP NetWeaver.
We call services delivered through SAP NetWeaver XI "brokered" services because, by leveraging the integration broker we are able to deliver "value-added" Web services -- that is, we can provide content- and context-based routing to one or multiple receivers, mapping, B2B wrapping, additional security, and process orchestration capabilities to our web services. The scenario variant looks like this:
Scenario variant: brokered service-based integration
In this variant, we still have the service consumer and the service provider; however, instead of being tightly coupled and directly dependent on one another, they are loosely coupled through SAP NetWeaver Exchange Infrastructure, which provides routing, mapping, and channel management services for the message exchange.
Consumer invoking service
The first step to this process is performed by the service consumer; the consuming application packages the parameters for the service request and invokes the proxy. The proxy constructs the SOAP message, which is then sent by the appropriate protocol (for instance, HTTPS) to the URL of the service, which is located at the Integration Server of the SAP NetWeaver Exchange Infrastructure system.
When the message is received at the Integration Server, the SOAP header is examined and the key fields (sender, sender interface, and sender interface namespace) are used to determine all valid configurations for the message. The first step is routing, in which the logically-decoupled receiver and receiver interface are determined. If the service consumer uses a different message structure, then a transformation must be executed to construct a message in the receiver format. Finally, the channel determination step selects the appropriate communication channel (including the protocol, address and security settings for the message), and the message is forwarded to the service provider.
Provider executing service
Once the message is received at the service provider, the payload is handed to the proxy layer, which extracts the call parameters and executes the service. The swimlane diagram shows the asynchronous case; if the service is executed synchronously, then the response message is returned back through the same path that the request message followed; inside the service broker, it may be necessary to execute another transformation step to map the response message back to the format of the service consumer.
In general, Web services represent atomic units of functionality. Each service should be self-contained and independent of other services. In business applications, however, it is often necessary to put several of these atomic services into a single process or flow definition. While this could certainly be achieved by coding an application., that approach does not leverage the advantages of web services, nor is it easy to maintain or govern on an enterprise scale. The scenario variant Service Orchestration offers the model-driven orchestration of services via the Business Process Management (BPM) capabilities of SAP NetWeaver. The variant swimlane diagram looks like this:
Scenario variant: service orchestration
Consumer invoking service
In the first process of this variant, the service consumer proceeds as in the last variant, invoking a proxy and sending a message to the URL of the service, located at the Integration Server. The sending service is logically decoupled from the process and does not need to be aware in any special way; thus, messages can be reused for different variants without any special effort on the send side.
As in the last variant, the integration broker provides routing and (perhaps) transformation services; however, because the configuration for the message has been created to call the business process, the message is then forwarded to the process engine of the integration server.
In service orchestration, the integration engine routes the message to the process engine, which instantiates a new instance of the process. This process has been modeled in advance using the business process modeler of SAP NetWeaver Exchange Infrastructure; and the message has been configured to instantiate this process. Of course, we could potentially have many instances of this process running at the same time, each of which is handling messages of the same type. For this reason, we need to be able to associate a running instance of the process with the correct messages, and to associate particular child messages with the correct parent messages. For instance, suppose our process is used to create a Purchase Order and to gather PO changes. Each time a PO change message is received it must be attached to the correct purchase order. To accomplish this, in our process definition, we provide a correlation using some unique identifier in the document. In the example just cited, the purchase order number would be an appropriate correlation field. At runtime the engine would examine the purchase order number field in a PO change message, and send it to the correct running instance of the process and associate it with the correct purchase order.
After instantiating the correlation container, the process engine executes the process logic. Of course, this may involve sending and receiving multiple messages, and these are all processed through the integration engine and process engine, as with our first message. For each of these (perhaps multiple) messages, the ultimate recipient of the message will be the service provider.
Provider executing service
From the point of view of the service provider, messages that are received out of a business process are handled exactly like messages in the previous two variants; the service provider calls the proxy and executes the service, just as before. Because services are logically decoupled, we do not need to do anything different in the service provider whether the service is accessed point to point, is brokered, or is part of an orchestrated message exchange.
Service-oriented UI Development
Services are defined independently of the service client; that makes them re-usable for both process automation and UI applications. As long as the infrastructure exists for invoking the service, it doesn't matter what is the invoking application. What is important is that the development environment supports the model driven development of the appropriate client, whether it is from a web service application, a business process, or a UI client. The scenario variant looks like this:
Scenario variant: service-oriented UI development
This variant starts with a model to access enterprise services or business objects, and proceeds through proxy and code generation, allowing UI applications to be developed as quickly as interfaces themselves.
In this process we lay out the foundation for the UI application, using Java and ABAP development tools to create a project structure and define a model to access enterprise services or business objects. First, in the Project Configuration step we define the project structure with our development tools and identify the views to be created. Then in the service modeling step we define the model type to access enterprise services or business objects and establish the communication channel.
Developing service-based UI applications
With this process we make sure that Java and ABAP development tools can generate proxy classes and import service and/or business objects to the development environment. There are two steps to the process: proxy generation and service definition. The proxies that are generated are the programming stubs for accessing the web service, that is, our UI application will call these proxies at runtime. In the service definition step we are importing the interfaces for the services or business objects that will be leveraged in our application. This process, and the previous one, are in the nature of prerequisites for doing the actual UI development.
This process is used to develop UI components as well as to provide the UI infrastructure needed to execute the service oriented UI. In the UI component development step we identify UI components for input and output -- such us UI elements, UI patterns and floor plans. These elements are often reusable and follow standard patterns. Furthermore, the development tools themselves are largely modeling tools, allowing us to manipulate symbols rather than writing code, from which the environment can generate appropriate code underneath. In UI configuration, we define mapping and coding extensions. Here we define layout preferences, flow control, view positioning and various customer specific preferences. Finally, the last step, which is optional, is UI services adaptation, where the customer can access various backend systems to display data on their UI.
In this article we have provided an overview of all components included in the IT Practice, Enterprise Services Architecture -- Design and Deploy. The practice uses many technical components within SAP NetWeaver and provides for the model-driven development of services and the applications based on them; it also describes how we can deploy or access those services and applications at runtime, and what are the processes and steps required to do so. We have also seen that key components of this practice include the NetWeaver Application Server, SAP NetWeaver Exchange Infrastructure, and the NetWeaver Developer Studio and ABAP development environment.
For more information on any IT Scenario, see http://help.sap.com. Select Documentation, SAP NetWeaver, select your language, then "IT Scenarios at a Glance".
Don't miss the other parts in this series!
Part 1: Using IT practices and IT scenarios to understand SAP NetWeaver -- introduction
Part 3: End-to-end process integration
Part 4: User productivity enablement