Implementing the OpenEdge® Reference Architecture (2nd Edition) - Presentation: OpenEdge Service Adapter - Wiki - OpenEdge Architecture - Progress Community

Implementing the OpenEdge® Reference Architecture (2nd Edition) - Presentation: OpenEdge Service Adapter

Implementing the OpenEdge® Reference Architecture (2nd Edition) - Presentation: OpenEdge Service Adapter

OERA_prl_2 (420).JPG

The OpenEdge Service Adapter is a Presentation Layer component of an application that is responsible for exposing the existing Service Interface from the Business Components Layer in a client expected form.

This paper, along with the accompanying sample code, shows a design of an OpenEdge Service Adapter together with a possible implementation in Progress ABL. A portion of the paper is shown below. A link is provided at the end of the page to the entire document.

Introduction

The Service Adapter was introduced in the ‘Service Adapter – Definition’ paper of the OpenEdge® Reference Architecture.

This paper, with the accompanying sample code, will discuss a design and implementation of an OpenEdge Service Adapter.

Requirements

The requirements for the OpenEdge Service Adapter in the OpenEdge Reference Architecture are listed below:

·    Make the service interface from the Business Components Layer available to the client application in a form the client application expects.

·        The service adapter should be extendable and customizable.

Design

Before the design of the OpenEdge Service Adapter is shown, the generic adapter pattern (or wrapper) is presented to explain the adapter concept.

What is the Adapter pattern?

The Adapter pattern is one of the structural patterns listed in the reference book Design Patterns by the Gang of Four (GoF – Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides). The Adapter pattern is very common to a situation in which you have one class that you wish to reuse, but the application interface doesn’t match the class interface. For this reason, you use an adapter to convert the application interface to the existing class interface. In other words, the adapter maps the interface of one class to that of another. The adapter is also often referred to as wrapper.

Figure 1 shows a UML class diagram of the adapter pattern. The classes that participate in the adapter pattern are:

·        Target: defines the domain specific interface the Client uses.

·        Adapter: adapts the interface Adaptee to the Target interface.

·        Adaptee: defines an existing interface that needs adapting.

·        Client: collaborates with objects conforming to the Target interface.

Adapter Pattern.gif

Fig 1. Adapter Pattern UML Class Diagram.

Logical Design (Structured View)

The logical design (using a UML Class Diagram) shows the design structure of the service adapter without the use of technology specific information. Using UML to create the design makes it object oriented in nature but the implementation of this OO-based design can be non-OO as shown in the Physical Design section where Progress ABL is used to create the actual implementation of this logical design.

The logical design of the service adapter is shown in figure 2 below.

OE_Service_Adapter(500)1.jpg

Fig 2. Service adapter UML Class Diagram.

Looking at the UML Class Diagram the following information can be derived:

·        The client application (ClientApp abstract class) uses the ClientServiceInterface class to perform its duties. The ClientServiceInterface has a number of operations defined which are being used by the client application.

·        The OEAdapter class inherits from the ClientServiceInterface class and makes use of the ServiceInterface class to execute the services. This way, the ServiceInterface class is reused and presented to the client application as a ClientServiceInterface class with the operations the client application expects.

Behavioral Design (Dynamic View)

The following paragraphs each show a single operation defined for a service adapter and how this could be implemented from a behavioral point of view. These UML sequence diagrams try to convey a ‘story’ or concept and do not contain the complete implementation details. Sometimes a description is used to conceal the implementation details as they do not really matter at this stage.

Client Login Request

When a client makes a clientLogin request to the client service interface, it is picked up by the adapter which performs some additional logic and executes the service through the available service interface defined for the business services to perform the actual login service.

The UML sequence diagram in figure 3 shows the sequence of events when the client makes a clientLogin service request through the adapter.

Client_Login_Request(500)2.jpg

Fig 3. UML sequence diagram showing the clientLogin request events.

Looking at the UML sequence diagram the following information can be derived:

·        The client application makes a clientLogin request passing the appropriate set of parameters.

·        The request is picked up by the OpenEdge service adapter which creates the required clientLogin data structure for the ServiceInterface call.

·        The OpenEdge service adapter calls the ServiceInterface using the appropriate set of parameters to perform a client login request.

·        The ServiceInterface object performs the requested service and returns results using the standard set of parameters.

·        The OpenEdge service adapter queries the result(s) of the ServiceInterface operation call and performs some local data manipulations that are required to support the client application (e.g. setting context information).

·        The clientLogin operation ends and a login result is returned to the client application.

Reading Data

The client application uses an operation called fetchWhere() to perform data reads using a set of parameters to influence the operation. A context data structure is used to pass context information to the service that is to perform the actual data read.

The UML sequence diagram in figure 4 shows the sequence of events when running a data read request.

Data_Read_Request(500)3.jpg

Fig 4. UML sequence diagram showing the fetchWhere request events.

Looking at the UML sequence diagram the following information can be derived:

·        The client application makes a fetchWhere request passing the appropriate set of parameters (entity name, wherestring in context etc.).

·        The request is picked up by the OpenEdge service adapter which prepares some data structures that are required for execution of this operation (things like passing sessionID, checking local cache to reduce data traffic etc.).

·        The OpenEdge service adapter calls the ServiceInterface using the appropriate set of parameters to perform a data read request.

·        The ServiceInterface object performs the requested service and returns results using the standard set of parameters.

·        The OpenEdge service adapter queries the result(s) of the ServiceInterface operation call and performs some local data manipulations that are required to support the client application (e.g. setting context information, caching data returned from the server etc.).

·        The fetchWhere operation ends and the read results are returned to the client application.

Writing (Saving) Data

The client application uses an operation called saveChanges() to perform data writes using a set of parameters to influence the operation. A context data structure is used to pass context information to the service that is to perform the actual data read.

The UML sequence diagram in figure 5 shows the sequence of events when running a data write request.

Data_Write_Request(500)4.jpg

Fig 5. UML sequence diagram showing the saveChanges request events.

Looking at the UML sequence diagram the following information can be derived:

·        The client application makes a saveChanges request passing the appropriate set of parameters (entity name, dataset containing data etc.).

·        The request is picked up by the OpenEdge service adapter which prepares some data structures that are required for execution of this operation (things like gathering the actual changes to be passed on, passing sessionID, checking local cache to reduce data traffic etc.).

·        The OpenEdge service adapter calls the ServiceInterface using the appropriate set of parameters to perform a data read request.

·        The ServiceInterface object performs the requested service and returns results using the standard set of parameters.

·        The OpenEdge service adapter queries the result(s) of the ServiceInterface operation call, checks the returned data for errors and performs some local data manipulations that are required to support the client application (e.g. setting context information, caching data returned from the server etc.).

·        The OpenEdge service adapter merges the changes back into the original data structure passed by the client application.

·        The saveChanges operation ends and the changed data structure is returned to the client application.

OE Service Adapter - Design.pdf

Comments
  • remove Introduction from description.comments on document sent separately to Frank

  • Frank,Please put more substance/detail into the content in the Jive document to give users idea of what is in the attachment.Phil

  • Yes, we are working on some sort of description standard level to accompany these items. I just do not want to edit it a zillion times so I'm waiting until that is done. I will then update it and move it on...Ciao!Frank

  • Changes look good. Approved

  • This document needs to go to: categoryID=290