|
|
WLI provides a set of controls that you can use in integration projects to access external resources.
| Note: | WLI applications can access external resources through the high-level controls of Workshop as well. Workshop provides a consistent mechanism for interacting with resources across all the components of Workshop, WLI, and WLP. |
Figure 6-1 shows the WLI controls.
WLI controls are based on the Apache Beehive open source framework (http://beehive.apache.org/). Beehive is a light-weight component framework that helps programmers encapsulate application logic and leverage metadata annotations into their programming model. Developers can create custom controls or use the prebuilt system controls.
| Note: | WLI controls are available in Workshop only if you have a license for WLI. |
The following sections describe the controls delivered with WLI.
WLI processes can access AquaLogic Service Bus (ALSB) proxies by using generic Workshop controls such as web service control, JMS control, and HTTP control. The ALSB control serves as an ALSB proxy-specific control that ensures efficient communication. It can be used regardless of whether WLI and ALSB are on the same or separate servers. The control exposes an ALSB proxy and its metadata to WLI processes.
The ALSB control operates in two modes:
The dynamic transformation control provides the ability to select, at run time, the transformation that must be invoked. The format of the input and output data need not be specified while designing the process. Instead, the process identifies the input data and transforms it to the desired output format at run time.
The dynamic transformation control uses transformations that are already defined and tested, such as those created with the transformation control. This control has base methods defined for various transformation types such as XML, XSLT, and MFL. Custom methods for executing different types of transformations can also be created. At run time, the transformation type is identified and executed using these methods.
The ebXML (e-business XML) protocol is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. It is sponsored by UN/CEFACT and OASIS. For more information about ebXML, see http://www.ebXML.org.
The ebXML control enables processes to exchange business messages and data with trading partners using the ebXML protocol. This control supports both ebXML 1.0 and ebXML 2.0 messaging services.
This control enables processes to send e-mails to a specific destination.
| Note: | To receive e-mail, you must use the Email event generator, which then publishes incoming e-mails to message broker channels. |
The file control enables processes to read, write, or append to files that are either in the local file system or on remote systems (FTP or SFTP server). In addition, the file control supports file manipulation operations such as copy, rename, and delete. You can also retrieve a list of the files stored in a specific directory. The files can be one of the following types: XML, binary, and string.
The methods available to a file control depend on the type of data in the file. For a string or XML type file, you can specify the character set encoding. While processing a file, you can specify the delimiter for the file as the record size. If no delimiter is specified, the file is processed one line at a time. In the case of string type files, you can also specify the number of bytes or any character as a delimiter.
The HTTP control is used to provide outgoing HTTP access to Workshop clients. This control can be used to work with HTTP requests and process responses. The HTTP control supports the Get and Post request methods for data transfer. By using Get, you can send business data along with the URL. By using Post, you can send large documents (binary, XML, or string) to the server within the body of the request. You can specify HTTP control properties in an annotation or pass dynamic properties through an XML variable. Using this control, you can send an HTTP or HTTPS request to a URL and receive specific HTTP response header and body data.
The message broker resource provides a publish-subscribe, message-based communication model for WLI processes, and includes a powerful message filtering capability.
The MB Publish control is used for publishing messages to message broker channels. You bind a message broker channel to the MB publish control when you declare the control, but the binding can be overridden dynamically. You can add additional methods to your extension (subclass) of the MB publish control.
The MB Subscription control is used to dynamically subscribe to channels and receive messages. When you create an instance of the control for a process, you bind the channel and, optionally, an XQuery expression for filtering messages. The bindings cannot be overridden dynamically. The MB subscription control interface includes methods that allow your process to subscribe to and unsubscribe from the bound message broker channel.
In addition to the dynamic subscriptions that you design at control nodes in your process, you can design static subscriptions at the start nodes to receive messages from message broker channels. In other words, a process can be initiated by subscribing (synchronously or asynchronously) to a message broker channel and started through an event.
MQ Series is a messaging service queue provided by IBM, which enables message transfer between applications. The sending application puts a message in a queue and the receiving application gets the message from the queue.
The MQ Series control enables WLI processes to send and receive messages using MQ Series queues. Using the MQ Series control, you can send and receive binary, XML, and string messages. You can specify MQ Series control properties while configuring the MQ Series control or dynamically at run time. By default, the MQ Series control handles transactions implicitly for each Put and Get method individually, without having to set an explicit transaction boundary. Transaction boundaries can, however, be set explicitly.
Using SSL, you can enable one-way authentication (server-side only) and two-way authentication (client- and server-side).
WLI provides and supports integration of the MQ Series messaging service queue (now known as WebSphere® MQ) through the following options:
For more information, see WLI JMS Control in Using Integration Controls.
For more information, see Event Generators in Using the WebLogic Integration Administration Console.
For more information, see Async Binary Update Sample.
For more information, see MQ Series Control in Using Integration Controls.
For more information, see BEA WebLogic Adapter for MQ Series 8.1 Documentation.
| Note: | The WLI controls and adapters rely on use of the MQ Series APIs. To resolve issues in an MQ Series control or adapter that is not part of WLI or is specific to IBM WebSphere MQ, the APIs might require workarounds. JMS-based MQ integration, however, does not have the same support-related limitations as IBM WebSphere MQ APIs. |
| Note: | For information about BEA products that IBM has explicitly stated it supports in conjunction with WebSphere MQ, see the following URL: http://www-306.ibm.com/software/integration/wmq/requirements/index.html |
A process control is used for sending a request to and receiving a callback from another process. This control is typically used to call a sub process from a parent process. Process control invocations are RMI calls.
You can create a process control by either selecting it from the list of WLI controls or generating it from the process file. When you insert the process control, you can specify the target process and the start method associated with that process. Optionally, you can use the query builder to decide, at run time, the specific subprocess that the control must call. When you generate the process control using the process file, a control extension file is created automatically for the control. You can double-click the control extension file to view the control in the design view or drag it to the data palette and use any of the methods associated with the control.
RosettaNet is a protocol that enables enterprises to conduct business over the Internet. For more information, see http://www.rosettanet.org.
The RosettaNet control enables WLI processes to exchange business messages and data with trading partners using the RosettaNet protocol. You can use this control only in initiator processes to manage the exchange of RosettaNet business messages with participants. The RosettaNet control supports RosettaNet version 1.1 and 2.0 of the implementation framework.
For more information, see Introducing RosettaNet Solutions in Introducing Trading Partner Integration.
The service broker control allows processes to send requests to and receive callbacks from other process or Web Service Description Language (WSDL) files.
The service broker control does not support the latest version of web services standards such as WS-Addressing, WS-Security, and SOAP 1.2. To access web services that support these standards, use the web service control delivered with Workshop.
The task and task batch controls are worklist controls that enable you to introduce user-assigned tasks and task management to WLI, so that you can build a worklist system. These worklist controls enable the automated manipulation, creation, and management of tasks.
Rendezvous is a messaging software provided by TIBCO. It enables exchange of data across applications running on distributed platforms. The TIBCO RV control in WLI enables seamless connection to (and transfer of data with) TIBCO Rendezvous using the Rendezvous daemon. It enables communication through many of the features provided by TIBCO Rendezvous, including certified message delivery and distributed queue. The sending and receiving applications can be on multiple platforms as long as the Rendezvous daemon is running on the host machine or is remotely accessible to the host.
| Note: | Use of the TIBCO RV control and event generator with WLI in no manner confers or grants the right to use TIBCO Rendezvous, including “dynamic libraries.” To use TIBCO products, you must obtain a valid license from TIBCO. For more information, see http://www.tibco.com. |
The TPM (Trading Partner Management) control enables WLI processes and web services to query (read-only access) for trading partner and service information stored in the TPM repository. Information such as the trading partner’s name and business ID, default trading partner, basic and extended trading partner properties, default bindings (ebXML or RosettaNet), services, service profiles, and service profile bindings (ebXML, RosettaNet, or web service) can be queried and retrieved from the TPM repository. However, only active profile services and active trading partners can access this repository.
| Note: | Since access to the repository is read-only, you cannot change trading partner and service information. These details can be changed only by using WLI Administration Console. |
Java Message Service (JMS) is a Java API for communicating with messaging systems. The WLI JMS control enables processes to easily interact with messaging systems that provide a JMS implementation.
Each WLI JMS control is associated with a specific facility of the messaging system. Once a WLI JMS control is defined, processes can use it like any other Workshop control.
This control is used by processes to access and retrieve XML metadata maintained in the XML metadata cache. This cache is managed by WLI Administration Console or the MBean API, which allows users to create their own NetUI-based consoles.
The XML metadata cache is a global, domain-wide cache. Data that is maintained in the cache can be accessed by any process that is deployed in that domain. The cache can also be used for sharing data within a cluster. The cache is used primarily for maintaining configuration metadata. Data is stored in the cache as key-value pairs where the key is of type String and the value contains XML data. Data from the cache is made available permanently through file-based storage. For each XML document that is added to the cache, a new XML metadata cache file is created. The XML metadata cache control in a process uses the key to retrieve XML metadata associated with the key value from the cache.
For more information about WLI controls, see Using Integration Controls.
|