You use a service flow project in a bottom-up approach when your objective is to create a service from an existing application.
You use a service flow project in a meet-in-middle approach when you already have both the WSDL file and the implementation component (application) and you need to create the additional support code that maps between the two.
You use a service flow project in a top-down development approach when you already have the definition of a particular Web service specified in a Web service definition file (WSDL format) and you want to generate high-level language source files (in this case, COBOL source files) containing: (1) COBOL versions of the XML schema definitions that are specified in the WSDL file for the inbound message and the outbound message of the Web service; and (2) COBOL program modules that copy ("map") the contents of the COBOL versions of the inbound message and outbound message to the XML schema definition versions of the inbound message and the outbound message, and vice versa.
These three development approaches are described in the following subtopics.
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.
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.
Your service flow project is a repository and organizational structure for the resources that you import, capture, or record using service flow project components.
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.
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.
Using this automated approach, you can:
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.
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.
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.
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.
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).
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.
Use the Deployment Properties wizard to set generation properties for your flow.
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.
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.
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.