        |  |
 |
 |
 |
 |
 |
 |
 |
 |
 |
|
Composer User's Guide
CHAPTER 2
Novell exteNd Composer allows you to build robust XML integration applications that can be deployed as Web Services. The applications you build with Composer can tie together diverse back-end systems, effectively XML-enabling data sources that are heterogeneous with respect to communications protocol, file formats, and/or operating systems.
A Composer service can include components that map and transform XML content, as well as other operations (such as sending email), while carrying out any kind of business logic that can be handled with Java or J2EE technologies.
The number of different types of back-end systems you can reach with Composer applications depends on how many Composer Connect products you have installed. Composer's core installation includes the JDBC Connect for reaching into database systems. Other Connect products allow you to exchange data with 3270/5250 systems, take advantage of CICS RPC operations, use JMS messaging, establish Telnet sessions, etc. You can also use EDI data and/or execute SAP functions.
Composer offers an intuitive visual interface for creating integration applications and testing them at design time via a powerful, interactive "step-through" debugging facility. Using simple drag-and-drop operations, you can build extremely sophisticated XML integration applications in minutes, without writing a single line of Java code. When you're done, your application can be deployed quickly to a J2EE application server (whether Novell's exteNd app server, or another J2EE-compliant server).
Your approach to using Composer begins the same way you begin any project: by capturing the requirements and by understanding the building blocks available to you to meet your requirements.
The building blocks that you'll use in Composer are:
You can think of Components as implementing the smaller units of work that will be collected into a Service. Resources are things like XML schemas, custom script libraries, and connection profiles that one or more components might need at execution time in order to do their work. Templates are typically XML stub documents needed by components and services.
Care should be taken when designing and building your components so that you can achieve the greatest amount of reuse. For example, you can create a component that uses a common XML document to access information from a legacy data source and call that component for each request. The component can be designed to preprocess incoming requests to particular format needs so that other components won't have to do the same thing on a component-by-component basis.
You'll often see the word "xObject" used throughout this Guide. An xObject is nothing more than a metadata definition of a Service, Component, Resource, or Template created by Composer. All of the data and instructions used in a Service, Component, or Resource are persisted to disk in XML form. Composer creates the corresponding runtime object(s) via the persisted metadata. The object that gets created is an xObject.
You won't need to worry about the low-level internals of xObjects per se. Composer handles that for you. From a terminology standpoint, you can think of xObjects as the XML-storable objects that make up a Composer application: namely, Components, Services, Resources, and Templates.
NOTE: If you're curious to see what an xObject looks like inside, open any of the XML files under your project's \composer directory structure, using your favorite XML editor. For example, to inspect a Connection Resource xObject, open any file under \composer\connection.
A Composer service is an xObject that calls one or more components designed to perform a logical unit of work. A service accepts one XML document as input, uses components to operate on the XML data, and then produces one output XML document. Services map, transform, or transfer data between data sources on an XML document level. Services are the runtime deployable units that integrate into an enterprise scalable application server environment (For additional information on deployment strategies, see the exteNd Server Guide). A service can execute other services or components. Examples of services that you can build include:
Sending status information to a trading partner based on an XML request
Retrieving data from legacy data sources in response to a Web browser request
A Composer component is a set of instructions or actions for processing XML document elements and/or communicating with non-XML data sources. Components accept one or more XML documents as input, performs activities on an element level, and then produce one or more XML documents. You can build simple or complex components of different types and link them together to carry out complete business operations. They map, transform, or transfer data between XML documents on an XML element level. They can also move data between XML documents and external data sources such as live 3270 transactions and SQL databases. Components can execute other components or services.
Components should be designed to perform discrete processes so that these common processes can be shared between services. Examples of components include:
As you will see later, components and services contain Action Models that execute the mapping, transformation, and transfer of data within XML documents. However, there are instances when the operations required are more specialized and complex than the Action Model's capabilities. This is where resources are used. Resources do not contain Action Models, nor do they contain input or output XML documents. Resources work like utilities to help components and services carry out their tasks.
Composer's resources include:
Code Tables—Code Tables store commonly used business code tables (e.g., State and Region tables)
Code Table Maps—Code Table Maps transform one set of codes from a Code Table into another set of codes (e.g., State to Region mapping)
Connections—Connections establish communications with specific sources of data in Connect transaction environments (e.g., JDBC connections).
Custom Scripts—Custom Scripts represent a library of user-developed functions using ECMAScript or Java language (e.g., String manipulations, accessing Java Business Objects)
An XML template contains the sample documents, definitions, and stylesheets that assist you in designing and testing the inputs and outputs to a component. In Composer, you use XML templates as the inputs and outputs for the components you build. It is important to note that XML templates are only used during design time; exteNd Server uses live documents during the actual execution of a service.
Your application development process should take into account the following basic steps.
Plan your service(s) before using Composer and gather the sample XML documents, definitions, and stylesheets you need
Your Composer application is based on the processing of XML documents. In planning your application you will want to write and analyze the requirements before designing the services. You will:
Determine input/output requirements. Where is the data coming from and where is it going to and in what format(s)?
Collect any existing XML documents including, if available, any standard XML documents from industry groups and business partners
In writing your requirements, the following questions will be useful to answer:
What does the input document look like? Does it conform to an industry standard? Do I need to define my own?
What does the output document need to look like? Where can I get samples? Are DTDs or XSL stylesheets required?
What processing components are required? Will the application need an XML Map component to transform XML data? Will the application need a JDBC component to connect to one or more databases? Can I reuse any components or resources that have already been built?
What additional resources does the application need? Are customized functions required?
There are many aspects of your project that you must consider when in the design stages.
You'll need to know the data sources to which you need to connect. You must know what data you'll need, where it will come from, and what the transmission mode will be. Among the other details you to consider are:
Authentication—Does the data source you plan on connecting to require authentication information, such as user IDs and passwords? Will you need authorization from an IT group? Will you need to coordinate with other departments?
Personnel—Will you need special help connecting to data sources? Is there someone in your organization with the skills necessary to understand, help create, and troubleshoot or debug the necessary external data source connections?
Legacy Applications—Will you need to contend with terminal data streams? Relational databases? Message queues?
Availability—Are the data sources with which you want to connect going to be available whenever you want to connect with them? Can you connect as often as you wish?
Transaction Control—Will your application need to incorporate rollback/commit logic?
XML Documents—Are there existing XML documents or schemas you need to obtain from industry groups, standards organizations, or business partners?
Logging and Notifications—Does your application have special progress-tracking or error-monitoring needs? Do notifications (via e-mail or JMS messaging) need to be sent when certain conditions arise? Does your service need to adhere to well-defined escalation procedures in case of problems involving credit limits, dollar amounts, supply chain difficulties, etc.?
Trading-Partner Requirements—Is your service going to be used by trading partners? Do they have their own security, audit-trail, timeout/retry, and/or other requirements that may put constraints on your application's design?
Once you've analyzed the requirements, it's time to design the service. Your design may now begin to take into account Composer's building blocks, as the illustration shows.
As described earlier, a service is comprised of components and is the unit of deployment in exteNd Server. You should have a good idea at this point how many components you will need to build as part of your service. For example, if you need to map data from one XML document to another and perform a code table conversion, you will need a component to perform that task. If you need to make a connection to a JDBC database and extract data, you'll need a component to accomplish that work too.
In building the service, you will:
Create needed resources for the service, such as Schema and WSDL Resources, plus others
Create executable building blocks (called Components) for the service, encapsulating the various stages of data retrieval and XML transformation unique to your service
You've created and tested your service. Now it's time to deploy it to an app server and put it into action. Composer includes a Deployment Wizard to step you through the process of taking your design time service through to execution by exteNd Server. Also, exteNd Director contains facilities for packaging Composer runtime objects into WAR files as subprojects of a larger J2EE project.
NOTE: Basic (but essential) deployment considerations are discussed in Chapter 15 of this guide. A more detailed discussion of deployment-related issues and procedures will be found in the Composer Enterprise Server User's Guide applicable to your app server.
Services and components pass information to one another during runtime processing by way of XML input and output messages and message parts. The messages and parts are parsed into DOM form (Document Object Model, used here to mean the in-memory object representation of a document). The XML output for one component or service is often the XML input for another component or service; however, services and components don't actually pass these XML documents as disk files, but rather pass "in memory" DOM images of the files. This is an important distinction, as these DOMs can be destroyed, changed, and recreated during processing to achieve your data integration goals without ever being written to disk or actually changing any disk files. Once an XML document is parsed and loaded into memory, it can be manipulated by the various mapping, transformation, and transfer features of the component editor and transaction environment each one accesses.
SOAP (Simple Object Access Protocol ) is an industry-standard XML messaging methodology in which XML and/or non-XML payloads and attachments are sent (typically) over HTTP. The protocol easily accommodates, although it does not actually specify, many common conversational modalities.
A SOAP transmission consists of an XML document structured as a header section and a body section, both of which are wrappered inside an envelope. The envelope and its contents are referred to as a SOAP message. The SOAP message may simply convey data, or it may contain the information necessary to invoke a remote service ( Remote Procedure Call).
SOAP is a convenient mechanism for encapsulating data and meta-information about the data. Its advantages over unstructured, non-standard exchange of XML data (such as sending arbitrary XML via HTTP POST) include the following:
SOAP is lightweight, which means it is simple, easy to implement, and adds little to the payload's size or handling requirements
It is well suited to simple text-based transports layers (such as HTTP)
It accommodates security layers unto itself (such as XML Signature and XML Encryption), independent of the transport layer
Composer includes a number of SOAP-enablement features, including the ability to send and receive SOAP messages from a service and the ability to control custom header information, apply (or decode) digital signatures, and use arbitrary attachments to SOAP messages.
For more information on SOAP-related functionality in Composer, see the sections on "Planning your Deployment" and "The Web Service (WS) Interchange Action" as well as Index entries for this book under "SOAP."
Composer provides support for XML security via mechanisms defined in the XML Signature standard (see http://www.w3.org/TR/xmldsig-core/).
The XML Signature specification addresses business requirements for:
Non-repudiation (irrefutable proof that an order was placed, or a transaction begun, by a specific party)
Certificate-based authentication (positive identification of transaction participants)
Composer lets you build XML integration applications that support digitally signed input as well as signed output, using the SOAP-header mechanisms spelled out in the XML Signature specification. (See above URL.) You can specify, for example, that a given Web Service must receive input that is digitally signed.
Refer to the discussion of the Web Service Interchange action (later in this guide) or the discussion of Composer-service deployment options for more information.
Copyright © 2003 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...