SilverStream eXtend Composer is part of the SilverStream eXtend family that provides a visual development environment used to create service-oriented applications. Composer allows developers to create services that gather data from multiple disparate sources, apply appropriate business logic, and return the results. The finished components meet J2EE standards and will execute on compliant application servers. Composer explicitly supports SilverStream's eXtend Application Server, IBM's WebSphere, and BEA's WebLogic.

Composer itself consists of three components: eXtend Composer, eXtend Composer Enterprise Server, and eXtend Connect Family. eXtend Composer, the IDE for creating Web services, is the main focus of this review. The Enterprise Server, executing in the application server, provides the runtime environment for Web services created with Composer. The eXtend Connect Family provides connectivity to many types of enterprise data sources and applications, including EDI, CICS, Telnet, JDBC, 3270/5250 terminals, and JMS.

Tool Overview
Composer applications are objects whose inputs and outputs are XML documents built with basic predefined components. Since XML is the centerpiece of all operations, XML files can quickly proliferate and become difficult to manage. To remedy this, Composer provides a very nice process for managing and organizing the files. In Composer, XML objects, referred to as templates, ultimately define a component's inputs and outputs.

Templates may be grouped into categories that relate to high-level document types such as sales orders and inventory requests. Each template is assigned at least one sample XML file that's used to define the data structure for a component's input and output. Composer allows XML templates to be validated at runtime to conform to a DTD or schema. Finally, stylesheets may be added to the templates to automatically transform the XML into a more appropriate format for the developer's needs.

Composer resources are objects that are shared across multiple components within an application. The basic resources available are code tables and maps, connections, XML Schemas, custom scripts, terminal stylesheets, and WSDL. Additional resources may be available for specific eXtend Connect objects depending on that component's requirements.

The building blocks of all Composer applications are the components, also known as the eXtend Connect family. Components provide the connectivity to enterprise systems to execute business logic and retrieve data. When building a component, XML inputs and outputs are established from library of previously defined templates, and actions are defined to execute the business logic for a given component.

Finally, Composer services are the objects that define the business process to be executed by a collection of components. Service objects are pieces of code (defined and deployed on an application server) that define the external interface to an application.

Development
The development cycle in Composer is an easy-to-follow process that's consistent throughout the application. Figure 1 is a screen shot of the IDE. The upper-left panel displays the available services, components, resources, and XML templates. The lower left panel lists the available objects for the currently selected item. The right-hand portion of the screen is the edit area for an eXtend object. In this example, the upper panels define the inputs and outputs, while the lower section displays the list of actions a given component will execute. This section will vary depending on the requirements and functionality of the selected item. Finally, the lower portion of the screen provides logging and runtime information.

Figure  1:

For this review, I'll develop a simple Web service that extracts information from a personal movie and music system. The eXtend Connect family provides access to this information in a variety of ways, including direct database access through JDBC, execution of a Telnet application, interaction with a JMS system, and interaction with a Web-based front end.

The definitions for the XML interfaces must be in place before developing of any service in Composer. In this case, I've defined request and response documents for retrieving the details of an individual movie. These documents are loaded into XML templates and are available to all future components of this service.

For the first method, I'll use a direct JDBC connection. For JDBC, a connection resource to the host database must be created. Any database that supports JDBC will work; in this example, I've used Oracle 8i. The JDBC resource itself is created by defining the inputs and outputs using the predefined XML templates for a request and a response. The next step involves writing the appropriate SQL statement to retrieve the data. Finally, by dragging the necessary identifying elements from the input XML document directly into the Where clause of the SQL statement, an XPath link is established that causes the component to use the data from the incoming XML document as the value for the Where clause.

It's worth noting that the majority of the manipulation of components, actions, and parameters is done via drag-and-drop. This provides an easily understood and intuitive process for development.

As is the case with most services being developed in Composer, the input and output XML structures are more complex than the results from a raw data source. To solve this problem, Composer provides the capability to add a set of temporary XML files to a component. These may be used as a data-staging area to map data from one structure to another. Additionally, Composer includes an ECMA script engine that provides powerful scripting options when working with data.

Accessing the movie database through a Telnet connection highlights another connectivity option Composer provides. Using Telnet, Composer interacts with the host system based on a series of actions defined through a recording process. In Figure 2, the upper-right portion of the screen is a Telnet Terminal emulator. As the developer interacts with this window, the actions are recorded in the Action list in the lower right. As with all other types of components, the full complement of drag-and-drop operations and ECMA scripts is available to developers during the Telnet session. Composer then "scrapes" the desired results from the screen and maps them to the output or temporary XML documents.

Figure  2:

As noted earlier, several other options exist for working with data sources, each of which provides the same level of flexibility offered by the drag-and-drop, scripting, and action mapping.

Bringing It Together - Services and Deployment
Once the individual component development has been completed, a Web service must be created to deploy to an application server host. Ideally, the Web service should contain only calls to individual components to execute business logic, although Web services share capabilities for actions and scripting of components.

For deployment, Composer provides three options: first, a wizard can be used to deploy code automatically; second, the server administrator can manually deploy code into the environment; and finally, eXtend Workbench can be used for deployment. This option is recommended for large projects involving several types of components. All deployment methods require the appropriate Composer Server to be installed and running in the target environment. In this case I'll use the Composer wizard to deploy to a WebLogic server.

The deployment process involves several steps. First, the developer is required to specify the target server type, the staging directory, the JAR file in which to package the objects, and the deployment context (package structure - e.g., com.syscon.wsj.re view) in the JAR file. The next steps involve specifying the triggering mechanism(s) for the Web service.

Services may be triggered by servlets, EJBs, or SOAP-based HTTP requests. For servlets, the request type, output type, and URL path must be specified. Once deployed, all requests to the specified URL will invoke the Web service. EJB service triggers require a JNDI path and a Transaction attribute. The resulting EJB can be called by any Java application to execute the service. To provide an additional interface to the EJB triggers, a second type of servlet trigger can be created to call a previously defined EJB trigger. Finally, a SOAP trigger requires the SOAP binding style, an RPC return namespace (if applicable), and a URL path for execution.

Once all required information is provided, the objects are automatically deployed to the host server and are available for execution.

Summary
SilverStream's eXtend Composer provides developers with a powerful IDE in which to create service-oriented applications. Through the eXtend Connect Family, Composer enables companies to leverage investments in legacy applications and data while extending them to trusted trading partners. Composer offers an intuitive, organized work environment and is an effective tool for developing Web services.

SilverStream Software Two Federal Street Billerica, MA 01821 Phone: 1 888 823-9700 Web: www.silverstream.com E-mail: info@silverstream.com

Test Environment Windows 2000 Professional, Pentium III, 256MB RAM

About the Author:
Brian R. Barbash is a consultant for the Consulting Group of Computer Sciences Corporation. He specializes in application architecture and development, business and technical analysis, and Web design.

bbarbash@csc.com