Overview: Working with data services
In this topic ...
Related Topics ...
Portlet Factory s Service-Oriented Architecture (SOA) defines Service Provider Models that access back-end data and services and Service Consumer or Presentation Models that provide the front end web user interface. The Factory automates the generation of both these layers as well as all the necessary artifacts to enable loose coupling between them.
This clean separation of layers, combined with a set of SOA-specific Factory features, allows you to de-couple implementation and testing of the UI from the back-end access and to streamline SOA development and deployment.
The goals of the Factory s supporting features for Service-Oriented Architectures are to:
- Enable independence and flexibility between the presentation and the services layers, both at implementation and in deployment.
- Speed SOA application development with increased levels of automation, including generating appropriate service testing pages.
- Make the most common service creation scenarios (SQL, packaged apps, WSDL/SOAP) easy, including eliminating the need for back-end access during implementation of the UI (presentation layer).
- Support a formal Interface to speed the creation of alternate service implementations, for swapping out back-ends or providing backup services.
The Data Service Models
To implement an SOA application, you create Models that are either Service Providers (back-end data access) or Service Consumers (front-end presentation) and then combine them (flexibly) both for application testing and for deployment. Using this methodology, teams of developers can work independently on the layers without the need to constantly coordinate and adjust to modifications made on the other side. Additionally, development can proceed without requiring access to the targeted back-end systems, simplifying life considerably for all, especially for the UI team.
Service Provider Model - Defines Service
These Models define a service within the WebApp; the Model (and thus the service) is then referenced by Service Consumer Models. The service can provide one or more operations (similar to the operations within a WSDL service). The service can return whatever results are required within an application, including gathering data from multiple back ends or databases and combining it in whatever form is required.
It is often useful to define a service with multiple, related operations, even if the data sources represent more than one back-end system. For example a Customer Information Service might define operations to return a customer list (based on search criteria), customer detailed information, customer orders, customer complaints, etc. A Product service might define operations for products by category, products by price, product inventory, product costs, product sales performance, etc.
Service Consumer Model - Invokes Operations
As their name implies, these models use one or more Service Consumer Builders to invoke the service operations made available by Service Provider Models. Usually (but not necessarily), a Service Consumer Model will generate UI, obtaining data via the Service Provider and then using whatever other Builders are needed to generate pages with the forms, views, graphs, etc., that comprise the presentation layer. The Provider/Consumer Builder set provides insulation to UI Models, and loose enough coupling between UI and service Models to allow substitution of an alternate Service Provider Model at runtime.
Building a Service Layer
There are two core Builders used to create a service layer. They are:
- Service Definition Builder - This Builder creates underlying support for an initially empty service, provides an option for exposing the service via WSDL and names the service.
- Service Operation Builder - This Builder adds an operation or method to the service defined by the Service Definition Builder. The operation can invoke any data access support available in the Model. Data access is usually provided by using one or more back-end integration Builders, such as SAP Function or SQL Call, but can also be provided by a Linked Java Object (LJO) or any data-returning method.
Note that the Service Provider Builder does not invoke the external data access API. Other Builders (such as integration Builders or an LJO Builder) in the Provider Model or in another included Model, make the calls and bring the data into the WebApp. Service Providers are built on top of those primitives. The Service Operation Builder can also transform data from the structures used by the back-end system Builder calls into the desired structures for the service being defined.
Building a Presentation Layer
There is one core Builder for the presentation layer:
- Service Consumer Builder - This Builder makes all the operations defined in a Service Provider Model available for use. It enables other Builders to reference all the information provided by the service, including the input and output schemas, the operations and the associated variables. With the Service Consumer Builder making the data available to the Page Automation system, we can use the entire array of Page Automation Builders to generate pages. For example, the View & Form Builder can reference service information, including the input and result schemas, and automatically generate complex presentation elements such as forms and list views.
Example - Building an SOA Application
This example uses a pair of simple Service Provider and Service Consumer (presentation) Models. It uses a JDBC database connection in the service layer (SQL Call Builder), although the service could just as use any Factory integration Builders such as SAP, Domino, PeopleSoft, Web Services, or any integration Builders created for proprietary back-ends.
Essentially only two steps are required to build the application:
- Create the service Layer (Service Provider Model) with three Builders:
- Integration Builder (SAP, SQL, Domino, etc.) or method
- Service Definition Builder
- Service Operation Builder(s)
- Use the service operations in the Presentation Model, with these Builders:
- Service Consumer Builder
- Various Page Automation Builders (View and Form, Record, List and Details, etc.)
Once these core pieces are in place, we can add other Builders to enhance the service or consumer side as desired.
Additional SOA Features Available
To further enhance the development of SOA applications, the Factory provides additional features that simplify and speed development. These include:
- Disconnected Support via Stub Service Models - By pressing a button in the Service Definition Builder we can automatically create a "Stub Service Model." This is a completely generated Model that has an identical interface to the original Service Provider Model, but includes an entirely self-contained snapshot of operations, schemas, and sample data. The Stub Service Model eliminates the need for you to be connected to the data source, reducing the hassle of configuring your system and eliminating the need for connecting to a real system such as SAP, Domino or PeopleSoft or ensuring the local presence of a "developer s" version of the system. If desired, the sample data can be automatically captured from actual result data obtained by invoking the service just once, and then using the disconnected support after that.
If your back-end system is slow in responding or has limited availability, you will save considerable time by using this disconnected development approach. Using a Stub Service Model means that the generation process does not need to access the slow back-end for every regeneration cycle.
Automatic Service Testing - The Service Test Builder lets you automatically generate the pages and code required for testing all the operations defined within a service, including the specification of default inputs for testing each operation. The Service Test Builder allows you to validate your back-end functionality with complete independence from any presentation layer, and without having to build a separate test harness. We can also generate "headless" methods that call the service operations directly, a capability that is useful for establishing automated testing of services, without having to view browser pages.
Simple Service Documentation - The Service Documentation Builder automatically generates services documentation on both sides of this dual architecture. It will create information about the service and its operations, including inputs and results, for services created by a Service Provider Model or for services used by a Service Consumer Model. Alternatively, a separate documentation Model can be used to generate the doc for any services within the WebApp.
Dynamic Service Mapping - This feature enables you to dynamically manage equivalent services, by letting you swap the actual Service Provider Model used whenever a service is referenced, either at design-time or at runtime. A "Service Mapping Registry" (a simple XML file) is used to specify which Model should be used to supply the referenced service. This Service Mapping capability automatically supports scenarios such as:
Using a Stub Service Model for much of the Provider implementation effort and swapping in actual connectivity only to test out what you have built.
Using a Stub Service Model for the development and testing of the presentation Models, then simply modifying the Service Mapping file to enable the real service (with real connectivity) to be used.
Switching to an alternate service implementation (for example, to use a different back end) at any time, without needing to modify any of the presentation Models. This enables substitutable services, either during application development or for a deployed application. The only requirement is that the selected Model implements the same Service Provider Interface.
- Service Interface Support - To facilitate swapping of Service Provider Models, Data Service Builders support the notion of a Service Interface, similar in concept to a Java interface. The Service Definition Builder allows you to specify the name of another Service Provider Model that you want to use as the Interface definition. The Interface concept is very useful when you want to develop alternate Service Provider implementations that all work with a common set of presentation (Service Consumer) Models. It ensures that we can swap between Service Provider Models without breaking the presentation Models.
The Service Definition and Service Operation Builders automatically provide assistance and verification for accurately implementing the specified Service Interface (the alternate implementation is not automatically generated). The service name, operation names and the number and names of operation parameters are verified. Since input and result types are not included in the verification, you could leverage the adaptive features of the Factory to implement the service with alternate formats.