In a service-oriented architecture, the ultimate goal is to quickly and easily build new applications as composites of existing services. Building out the independent services in a manner that supports reuse is itself very challenging. However, several tools are beginning to appear to easily bring applications together once the critical mass of applications is achieved. One such tool is the FusionWare Integration Server.

The FusionWare Integration Server is a suite of products that provides systems integration, workflow, and data transformation capabilities to build composite applications. The suite consists of the following:

• FusionWare Server: Java-based server application that provides the run-time environment for FusionWare applications
• FusionWare Designer: IDE for building and deploying FusionWare applications
• FusionWare Administrator: Management utility for use with the FusionWare Server
• FusionWare Client Simulator: Graphical utility for submitting and reviewing application calls to the FusionWare Server

Applications are stitched together via XML, database, and Java/COM componentry, and executed via XML over HTTP or through a file-based XML interface.

For the purposes of this review, I have created a Project Management application in FusionWare Designer to manage Time, Expense, Budgeting, and Invoicing for a fictional consulting company.

Building Applications
FusionWare applications are built in the Designer as a set of Business Processes that act upon an XML document submitted to the system either via an HTTP GET/POST operation, or from a designated file system directory that is constantly polled. Each business process is in turn a series of workflow steps that manipulate the submitted XML document, call external systems, reusable subroutines, Web Services, and databases, and return the results to the calling entity.

The Designer itself follows a Windows Explorer-like paradigm. As seen in Figure 1, higher-level objects are located on the left side of the screen with details and configuration information located on the right. While functional, this interface can at times be challenging because it does not show the business process model using the traditional flowchart or swim-lane diagrams. In complex business processes with many workflow steps, logic branches, and data manipulations, it can become difficult to keep track of the flow of data. While it's not something to disqualify the product from consideration, it may take time for a developer to become acclimated.

Figure 1 shows the model in the Designer for the sample application I've created. The left side of the screen represents the individual business processes defined in the application, the middle of the screen shows the individual workflow steps for the selected business process, while the right side of the screen shows the details of the workflow step currently selected.

In most situations, as with this example, models will contain multiple business processes. Therefore, developers must define recognition tests that evaluate the incoming XML document to determine the appropriate business process to execute. Recognition tests are simply XPath statements that define an XML NodeSet. If the XPath returns a NodeSet, the recognition test evaluates to True and process flow is directed to its associated business process. For example, the business process bpCreateClient in the sample application should be executed when the incoming XML document contains the appropriate Client nodes. Figure 2 shows the associated Recognition Test.

Recognition tests may also be associated with workflow steps independent of the parent business process (also shown in Figure 2). In many cases this capability is used to perform common operations such as logging, message archiving, transformation to canonical message forms, or message validation against Schemas and DTDs. In the case of the example in Figure 2, the incoming XML document is validated against a schema and supplemental documents are instantiated supporting other operations in the workflow.

Throughout the Designer tool, the manipulation and extraction of XML data via XPath statements is an important function of many of the available actions. To facilitate this, FusionWare Designer provides a very simple but effective XPath generation tool. Developers simply select the relevant XML nodes from sample instance documents. The generated XPath statement is then applied to the current action. These statements may be further tweaked manually to support more complicated operations.

One very powerful feature of the FusionWare solution is the ability to create and execute parallel tasks within a single business process. For example, if a consultant is submitting an XML document that contains both a Timesheet and an Expense Report, FusionWare may be configured to execute the individual business processes relevant to each type of data structure in parallel.

Systems Integration
FusionWare provides a set of systems integration capabilities to link together existing systems to form composite applications, such as:

• Database Access: FusionWare may access any database available via a JDBC connection
• Web Services: External web services calls may be made from within a FusionWare application
• Java/COM: Custom Java and COM objects may be called to provide connectivity and control to applications not accessible through standard FusionWare methods

For the sample Project Management application, two main types of integration will be required: database access to the system's persistent store and Web services access to external services for data validation.

The Project Management application requires address information when creating clients to support invoicing. To ensure valid addresses are submitted, a call to an external Web service will be made. Setting up a Web service call in FusionWare designer is very simple. Figure 3 shows the configuration screen for Web services. The developer must identify the URI to the WSDL file for the service and the desired operation. Once defined, all input parameters must be mapped to the service call. Parameter values may either be defined manually in XML format, or extracted via XPath from a run-time variable. Results of the service call are then delivered to a result document defined in the business process. Developers have the option of either saving the result as a whole in an independent variable, or targeting a specific node in a predefined result document using an XPath statement.

Defining database operations in FusionWare designer is a simple multi-phased process. Initially, the developer defines the Database Access properties. These properties establish the document containing the input parameters and the location to where results of the operation will be written. The second phase of the process establishes one or more Database Actions. These actions represent individual SQL and Stored Procedure calls. Within an Action, the developer defines the connection to be used, the SQL or Stored Procedure call to invoke, the XPath identifying where to retrieve relevant parameter values from the input document, and if applicable, the element names to be used for each row of the resultset.

Summary
Service-oriented architectures, in their ideal implementation, provide a catalog of services that may be brought together to support new business processes or functions. Governing the relationships, integrating data, managing transactions, and optimizing performance among the constituents of composite applications can prove to be challenging. FusionWare Integration Server provides a simple but effective tool for achieving this end goal. It is a solid offering to be considered for an SOA environment.