To further enhance the development of SOA (service-oriented architecture) applications, IBM® WebSphere® Portlet Factory provides additional features that simplify and speed development.
Disconnected support by stub service models
By pressing a button in the Service Definition builder, you can automatically create a stub service model. This completely generated model 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, IBM Lotus® 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. Automatic service testing
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.
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 easily validate your back-end functionality with complete independence from any presentation layer, and without having to build a separate test harness. You 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
Service interface support
This powerful 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 published application. The only requirement is that the selected model implements the same service provider interface.
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 you 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 WebSphere Portlet Factory to implement the service with alternate formats.
Parent topic: Building a serviceoriented application: wpf7