Rational Developer for System z, Version 7.6

Web service development scenarios: service flow projects

This topic describes bottom-up, meet-in-middle, and top-down development of Web services in the context of developing a comprehensive Web service that is capable of collecting and processing data from multiple CICS® applications, or from other Web services, or from both.
Service flow projects support the following development approaches:

These three development approaches are described in the following subtopics.

Bottom-up development

As previously noted, existing applications that have stood the test of time represent a substantial investment for any corporation. Reusing existing applications, while creating new value in their implementation as services, extends the usefulness of these applications and increases the value that they provide to the corporation.

You use a service flow project in a bottom-up approach when your objective is to create a service from an existing application.

In creating a service from an existing application, you recast or re-purpose the application for participation in a service-oriented architecture. The business function of the application is used in new ways, by new audiences. This type of intelligent reuse creates new value and extends the usefulness of existing applications.

One goal of bottom-up development would be to connect still relevant business functions in older applications with newer technology. For example, you might combine the travel industry and pervasive computing by transforming an existing travel application, exposing it as a service, and making the service available for use by various devices in a service-oriented environment. More specifically, you could extend the ticket reservation business function to new audiences, so that it could be accessed and utilized in new ways.

Developing a service based on existing assets is referred to as a bottom-up approach because you begin your development effort with the implementation (an existing application) as a foundation, and then you create an interface service definition "on top of" the implementation.

The interface service definition is the key component in transforming how the existing application will be utilized in an SOA. The service interface definition is derived from the programmatic interface of the existing application. Through service flow project development, the programmatic interface of the application is transformed to an interface that is suitable for service-oriented architecture.

In a bottom-up approach, you use a service flow project to capture the interface of the existing application and then you generate a description for the implementation as a screen operations file .

You can implement and package the contents of the screen operations file as nodes on a flow, where each node represents invoking a service operation, controlling the flow of the sequence, or performing reusable business logic.

In Figure 1, a 3270 application is the source that begins the generation of the service by the service provider.

The existing 3270 application represents data structures (screen images, BMS maps, navigation) on a CICS server.

At build time, developers use the service flow project tools to import the data structure of the 3270 application, and after a series of steps, they generate the WSDL, operations, and flow that define the application as a service.

In the case shown in Figure 1, an airline ticket reservation service is generated, since the CICS server contains airline reservation data.

Figure 1. Example of Service (Airline Ticket Reservation)
Diagram of service

The following steps describe a bottom-up development approach when using service flow project tools to create a service from an existing 3270 application.

The details of how to perform the following tasks are documented in the applicable help topics.

  • Create a service flow project

    Your service flow project is a repository and organizational structure for the resources that you import, capture, or record using service flow project components.

  • Create a connection to the host

    Your host connection contains the properties that enable you to access the system on which the 3270 application runs.

    Service flow project tools support connecting to 3270 and 5250 terminal applications.

  • Connect to the terminal application using the host editor
    Connecting to the terminal application allows you to navigate the application and to discover and understand the sequence of screens and the general flow of the business function from which you want to create a service.
    Note: Connecting to a terminal application is required only when you are working with terminal-based applications. You can use Service flow project tools with nonterminal applications as well.
  • Capture the ticket reservation business function

    Service flow project tools provide several options for capturing a business function from existing terminal applications.

    The method that you choose to capture the business function from an existing terminal application often depends on the complexity of the application that you are transforming.

    • Capture ticket reservation business function automatically from the host editor
      The automatic technique could be composed of the following tasks:
      • Use the host editor flow record function to capture the flow of the business function and to record the screen operations all at once.

        Using this automated approach, you can:

        • Incorporate messages from previous screen capture operations, or previously imported BMS maps, or you can set service flow project preferences that enable the flow record function to capture screens automatically as you navigate the host application.
        • Generate input and output messages that can be used as the service interface.

      Flow record is the quickest way to create a flow, but it does not necessarily promote reuse of host artifacts.

      You can use the resources that you create through the flow recording to produce flows rapidly, but additional editing of these resources may be required.

      Using the record function from the host editor to create a flow of an application is best suited for users who have limited knowledge of the back-end systems that host both data and information for service flows.

    • Capture ticket reservation business function manually.
      The manual technique for capturing a business function from a terminal application could be composed of the following tasks:
      • Capture the screens

        Use the host editor to navigate to each screen encountered and used in the ticket reservation business function, and perform a screen capture operation.

        When you capture host application screens, they are saved as messages in .sfmxsd format.

        Depending on the server runtime to which you deploy your service, you may need to add more detailed recognition criteria to the messages resulting from the screen capture operation.

        The service flow project tools include a screen message editor for enhancing screen message descriptions.

      • Record a screen operation, incorporating the screens that you have captured

        A screen operation represents a set of screens, with no more than one operation corresponding to a given screen description.

        In this example, a screen operation represents all the valid paths through the application screens that are part of the ticket reservation business function.

        These paths in a screen operation are stored in a WSDL document and can be used as input to a flow of the application.

      • Build a flow of nodes based on the operations you created through the record screen operation step.

        The flow is a graphical representation of the composed service, in this case an airline ticket reservation business function.

        The flow is composed of a sequence of operations, assignments, and conditionals.

        Building a flow manually may include the following steps:
        1. Wire the connections and map the data on the flow

          A flow has a WSDL operation interface (output from the record screen operation step), which directs actions from a beginning point (Receive or Input node) through a number of operations to an end point (Reply or Output node).

          In a service flow project, the flow represents the recasting of an existing business function application as a service.

          You use the flow editor to wire the nodes together into a finite path that processes a request message (ticket reservation) and results in a response message (your reservation is processed).

        2. Create the service interface
          This step could be accomplished in a number of ways:
          • Import existing COBOL / C structure(s) that define the input and output message for the service.
          • Create the input and output messages manually.
          • Create a new WSDL operation (using these messages) and select it for use in the flow.

          The flows that you create using service flow project tools can be exposed as a service themselves, to be driven externally by a Web service or by a J2EE Connector (J2C) resource adapter, such as CICS ECI.

    • Configure generation properties

      Use the Deployment Properties wizard to set generation properties for your flow.

    • Generate Runtime code wizard

      Use the Generate Runtime Code wizard to create the code for the supported server runtime environment.

The bottom-up approach outlined (see Bottom-up development) begins with the application function that is being encapsulated, with the last step resulting in a service interface (containing an input and output message) that can be invoked.

In the airline reservation example, the input message might contain customer information and travel information details, while the output message might contain reservation information and a confirmation number.

In the bottom-up approach, the interface is created at the end of the process, after you have created the flow that represents graphically those existing host application screens that are processed to make the ticket reservation.

Meet-in-middle development

You use a service flow project in a meet-in-middle approach when you have an existing WSDL file and implementation component (application) at the start of your service flow project, and you need to create the additional support code that maps between the WSDL file and the implementation component.

You might have access to a preexisting service interface if it had been deemed necessary to develop an interface in order to satisfy a specific business need. As part of the analysis that resulted in this service interface, you would know that service consumers would be issuing requests in a particular format and that the format of the replies sent back would also be known or predetermined.In such a scenario, you would use service flow project tools to build the flows that invoke existing CICS applications and then "map" the sequences to the existing service interface definition.

Such an approach might also apply when your business has prebuilt services. For example, your business might have created a GetCustomerInfo service with a defined request response model.

The phrase meet-in-middle denotes that there are simultaneous development efforts ongoing, that at one end of the spectrum there are developers creating service operation interfaces, while at the other end of the development spectrum there are business analysts who are creating the flow and then mapping it to the existing service operation interface.

Top-down development

Using this method, you can create a new service that conforms to an existing service interface. This type of service interface is usually part of an industry standard, which can be implemented by any number of service providers.

The service provider must find the service interface, implement the interface contained in this definition, and then deploy the new service. The service interface cannot be owned by the service provider.

The top-down approach will become more relevant as industry groups begin to agree on standard WSDL interfaces to common business functions.

Although theoretically service flow project tools can be used in a top-down approach, it will not be discussed in the help topics or in the sample.


Terms of use | Feedback

This information center is powered by Eclipse technology. (http://www.eclipse.org)