WebLogic Server Process Edition Overview
|
 |
 |
|
|
 |
 |
WebLogic Server Process Edition provides a set of out-of-the box controls that enable you to start integration projects with a portfolio of resources. WebLogic Server Process Edition integration controls provide easy access to enterprise resources like databases, file systems, etc., from within your application. You can also access other WebLogic controls like Enterprise Java Beans from within your application. The control handles the work of connecting to the enterprise resource for you, so that you can focus on the logic of your business process.
The following sections describe the WebLogic Server Process Edition integration controls and the other available WebLogic controls in more detail, before introducing asynchronous interfaces and conversations:
The following integration controls are described in this section:
A File control makes it easy to read, write, or append to a file in a file system. The files can be one of the following types:
When you create a File control, you must select the file type that matches the files present in the specified directory. The File control supports file operations such as copy, rename, and delete. You use these operations to manipulate large files, without having to read their entire contents. You can also list the files stored in the specified directory.
Normally, you configure a separate File control for every individual file you want to manipulate. You can specify File control settings in several different ways. You can set the File control's properties in Design view or you can call the setProperties method of the FileControl interface. You can change File control configuration properties dynamically. To get the current property settings, use the getProperties() method.
You can also use the ControlContext interface to access a control's properties at run time and to handle control events. Property values set by a developer who is using the control are stored as annotations on the control's declaration in a JWS, JSP, or JPD file, or as annotations on its interface, callback, or method declarations in a JCX file.
For more information, see File Control in Using Integration Controls in the WebLogic Workshop Help.
The Email control enables WebLogic Server Process Edition business processes to send e-mail to a specific destination. The body of the e-mail message can be text (plain, HTML, or XML) or an XML object. The Email control is customizable, which allows you to specify e-mail transmission properties in an annotation, or use dynamic properties passed as an XML variable. You can use the Email control to send a variety of content types and various combinations of body and attachments.
When you add an Email control to your business process, you can use an existing Email control extension file (.jcx) or create a new one.
For more information, see Email Control in Using Integration Controls in the WebLogic Workshop Help.
JMS (Java Message Service) is a Java API for communicating with messaging systems, which are often packaged as products known as Message-Oriented Middleware (MOMs). WebLogic Server includes built in messaging capabilities via WebLogic JMS, but can also work with third-party MOMs. Messaging systems are often used in enterprise applications to communicate with legacy systems, or for communication between business components running in different environments or on different hosts.
The WLI JMS control enables WebLogic Workshop business processes to easily interact with messaging systems that provide a JMS implementation. A specific WLI JMS control is associated with particular facilities of the messaging system. Once a WLI JMS control is defined, business processes may use it like any other WebLogic Workshop control.
The WLI JMS control is an extension of the JMS control, providing additional features such as RawData message type support, dynamic property configuration, and the ability to control whether to start a new transaction or remain within the calling transaction.
For more information, see WLI JMS Control in Using Integration Controls in the WebLogic Workshop Help.
The Service Broker control allows a business process to send requests to, and receive callbacks from, another business process, a Web service, or a Web service or business process defined in a Web Service Description Language (WSDL) file. The Service Broker control lets you dynamically set control attributes. This allows you to reconfigure control attributes without having to redeploy the application.
A remote Web service or business process is accessed using Web services and is described in a WSDL file. A WSDL file describes the methods and callbacks that a Web service implements, including method names, parameters, and return types. You can generate a WSDL file for any business process by right clicking on a JPD file in the Application pane and choosing Generate WSDL File.
For more information, see Service Broker Control in Using Integration Controls in the WebLogic Workshop Help.
The Hyper Text Transfer Protocol (HTTP) control is built using the features of the WebLogic Platform control architecture. The HTTP control source file is a wrapper around the Jakarta Commons HTTP Client package. The HTTP control enables WebLogic Workshop and business processes to work with HTTP requests and send responses to a specific URL. The HTTP control supports two HTTP modes for data transfer, namely HTTP GET and HTTP POST. By using the GET mode, you can send your business data along with the URL. By using the POST mode, you can also send Binary, XML, and string documents. You can specify HTTP properties in an annotation, or pass dynamic properties via an XML variable.
The HTTP control comes with the following features and functions:
The MQSeries control provides basic MQSeries operations like PUT and GET. You use this control to set and get MQMD attributes. The MQSeries control supports multiple message payload formats, such as XML, Binary, and Text.
The MQSeries control enables you to set MQMD properties for every GET and PUT operation. The GET and PUT methods take an xmlbean object as part of the signature. The xmlbean is represented by an MQMDHeaders schema which is present in the MQSchemas.jar.
The properties of the MQSeries control are:
This section describes the following application controls:
Java controls are reusable components you can use anywhere within a platform application. You can use built-in controls provided with WebLogic Workshop, or you can create your own. When you're building WebLogic Server Process Edition applications, Java controls provide a convenient way to incorporate access to resources and encapsulate business logic.
If you've used WebLogic Workshop, you may be familiar with built-in Java controls such as the Database control, EJB control, Web Service control, and so on. These are included with the IDE, but you can also create your own custom Java control. You can use controls from within the many kinds of components that make up WebLogic Server Process Edition applications. A good practice is to use the custom Java control to implement your business logic and call built-in controls when the implementation of the business logic requires this.
For more information, see Working with Java Controls in the WebLogic Workshop Help.
A Database control makes it easy to access a relational database from your application. Using the Database control, you can issue SQL commands to the database. The Database control automatically performs the translation from database queries to Java objects, so that you can easily access query results.
A Database control can operate on any database for which an appropriate Java Database Connectivity (JDBC) driver is available and for which a data source is configured in WebLogic Server. When you add a new Database control to your application, you specify a data source for that control. The data source indicates which database the control is bound to.
For more information, see Database Control in Using Built-In Java Controls in the WebLogic Workshop Help.
Some transactions and events require a certain amount of time to complete. Others can run indefinitely if not aborted, and eat up resources. Still others must occur at a specific time. The Timer control provides the developer with a way to respond from code when a specified interval of time has elapsed or when a specified absolute time has been reached.
A Timer control notifies your application when a specified period of time has elapsed or when a specified absolute time has been reached. All Timer controls are instances of the com.bea.control.TimerControl base class. Unlike most controls, a Timer control is declared directly in a JWS file; there is no subclass created for a Timer control.
For more information, see Timer Control in Using Built-In Java Controls in the WebLogic Workshop Help.
A Web Service control makes it easy to access an external Web service from a WebLogic Workshop application. You can create a Web Service control for any Web service that publishes a WSDL (Web Service Definition Language) file. A WSDL file describes the methods and callbacks that a Web service implements, including method names, parameters, and return types. It also describes the protocols that a Web service supports.
For more information, see Web Service Control in Using Built-In Java Controls in the WebLogic Workshop Help.
Enterprise JavaBeans (EJBs) are Java software components of enterprise applications. The Java 2 Enterprise Edition (J2EE) specification defines the types and capabilities of EJBs as well as the environment (or container) in which EJBs are deployed and executed. From a software developer's point of view, there are two aspects to EJBs: first, the development and deployment of EJBs; and second, the use of existing EJBs from client software. The EJB control makes it easy to use an existing, deployed EJB from your application.
For more information, see EJB Control in Using Built-In Java Controls in the WebLogic Workshop Help.
Java Message Service (JMS) is a Java API for communicating with messaging systems. Messaging systems are often used in enterprise applications to communicate with legacy systems or to provide communication lanes between business components running in different environments or on different hosts. The JMS control enables applications built in WebLogic Workshop to easily interact with messaging systems that provide a JMS implementation, such as WebLogic Server or Message-Oriented Middleware systems (MOMs).
The JMS control enables WebLogic Workshop Web services to easily interact with messaging systems that provide a JMS implementation. A specific JMS control is associated with particular facilities of the messaging system. Once a JMS control is defined, Web services may use it like any other WebLogic Workshop control.
For more information, see JMS Control in Using Built-In Java Controls in the WebLogic Workshop Help.
Web applications, including Web services, typically use the Hypertext Transport Protocol (HTTP) to provide communication between a client and a server (the application). HTTP is a request-response protocol. In a request-response protocol, each operation consists of a request message sent from the client to a server followed by a response message returned from the server to the client. The server must always send a response for the operation to complete successfully. Such requests are called synchronous because during the request the client is synchronized with the server; the client cannot continue processing until the server responds or the request times out (the client may time out if a response is not received within a specific period of time).
In a Web application, some of the operations the application performs may be long-running. If an operation involves human interaction such as approval by a loan officer of a bank, the operation could take days to complete. It would be a poor design if individual request-response cycles were allowed to span days; such requests would unnecessarily engage resources on both the client and server hosts.
With WebLogic Server Process Edition, you can design your application to be asynchronous, which means that the application notifies the client when the response is ready. This allows the client to continue performing other work while the application completes the requested operation. It also keeps each request-response interaction between the client and application as short as possible.
The following sections provide an overview of asynchrony and asynchronous interfaces:
Interactions between software components can be synchronous or asynchronous. An interaction is synchronous if the caller of a method must wait for the method's work to complete before the caller can continue its processing. An interaction is asynchronous if the called method returns immediately, allowing the caller to continue its processing without delay. An asynchronous interaction typically initiates a computation but does not wait for the result to be available, which means it must provide some way for the caller to obtain the results of the computation at a later time.
The distributed nature of Web applications introduces unpredictable and sometimes very long latencies, which means it may take an operation a long time to complete. If a business process executing over the network involves human interaction at the back end, an operation can take on the order of days. If all interactions over the Web were synchronous, clients with pending operations could consume resources on their host systems for unacceptably long periods of time.
WebLogic Server Process Edition provides tools that make it easy for you to build asynchronous Web services and Java controls that don't require clients to block execution while waiting for results. WebLogic Server Process Edition provides multiple approaches for returning results to your Web services' and Java controls' clients; you can choose the one that best suits each situation.
To create an asynchronous Web service, you provide one or more methods that accept requests from clients that begin an operation but do not wait for the operation to complete. Such methods typically return immediately, supplying the response portion of the initial request-response interaction but not supplying the actual result of the requested operation. In an asynchronous interface, you also provide a mechanism for the client to obtain the results of the long-running operation when the results are ready. There are two ways to accomplish this:
When you define a callback for a Web service, you are defining a message for the Web service to send to the client that notifies the client of an event that has occurred in your Web service. In this design, the client first calls the Web service with a request. This request call typically returns immediately (completing the first request-response interaction), meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks. When the Web service or Java control has finished processing the client's request, it sends a callback, that is, it sends a message back to the client notifying it that the request has been processed and/or providing the results. Note that a callback constitutes a second request-response interaction in which the request (not the response) is sent to the client. To learn more about the callback mechanism, see Using Callbacks to Notify Clients of Events in Getting Started: Using Asynchrony to Enable Long Running Operations in the WebLogic Workshop Help.
To use a callback, two requirements must be met. First, if a Web service defines a callback the Web service must be conversational. Conversational Web services keep track of the originator of a request and can therefore send the callback to the appropriate caller. Secondly, the client must be capable of receiving and interpreting the callback. If the callback is defined by a Web service, then in essence the client must itself be a Web service since it must be capable of receiving messages. It must also be capable of correlating an incoming message with a previous request that it initiated. To learn more about conversations, see Designing Conversational Web Services in Designing Asynchronous Interfaces in the WebLogic Workshop Help.
When the client of a Web service or Java control is not conversational, as is the case for Web pages and non-conversational Web services, callbacks cannot be used to notify the client of request completion. In addition, if the client of your Web service resides on a host that rejects unsolicited incoming traffic or is protected by firewalls, the host will reject callbacks because callbacks are, by nature, unsolicited, and the client will not receive the callback. To handle these scenarios, Web services and Java controls must provide a polling interface. In a polling interface, the client first calls the Web service or Java control so that an operation can be initiated. This request call is synchronous but typically returns immediately, meaning that the client does not have to wait for the operation to be completed. The client can now continue doing other tasks, but must periodically call the Web service or Java control to check the status of its pending request. When a periodic check shows that the request has been completed, the client then calls the Web service or Java control to obtain the result. To learn more about implementing a polling interface, see Using Polling as an Alternative to Callbacks.
Polling and callbacks are two different mechanisms to achieve asynchrony. Unless you are absolutely certain that the clients of your Web service or Java control will always require only one of these mechanisms, you may want to implement both approaches in order to handle all situations. Doing so provides the convenience of callbacks to those clients who can handle them, and a polling interface for clients who cannot accept callbacks.
This section discusses the best practices for creating and using Web services and Java controls with asynchronous interfaces. The first topic describes how to use polling as an alternative to callbacks. Then, various design questions for designing Web services and Java controls that can be called by both Web services and JSP (web) pages are answered.
Because callbacks are, by definition, separated from the original request to which the callback is a response, they appear as unsolicited messages to the client's host. Many hosts refuse unsolicited network traffic, either because they directly reject such traffic or because they are protected by firewalls or other network security apparatus. Clients that run in such environments are therefore not capable of receiving callbacks.
Another requirement for handling callbacks is that the client is persistent by being conversational. If the client is a Web application, that is, a JSP page, or a non-conversational Web service, it cannot handle callbacks.
In order to allow clients that can't accept callbacks to use your Web services, you can supply a polling interface as an alternative. In a polling interface, you provide one or more methods that a client can call periodically to determine whether the result of a previous request is ready. Although the Web service or Java control will still be asynchronous in design, the interactions with a client are handled with synchronous (unbuffered) methods.
A typical design of a polling interface will have these three methods:
null if the request could not be processed successfully. If the client calls a Web service, the get_results method will finish the conversation. Notice that a client using a polling interface needs to periodically check the status of the request, because the Web service or Java control cannot notify the client when its request has been processed. Also notice that the three methods will not be buffered. The check_status and get_results methods do not return void and cannot be buffered, while the start_request method cannot be buffered because you need to ensure that this method has been handled before the check_status is handled. (Remember that the relative handling order of buffered and unbuffered methods is uncertain. For more information, see Using Buffering to Create Asynchronous Methods and Callbacks in Getting Started: Using Asynchrony to Enable Long Running Operations in the WebLogic Workshop Help).
There are several other ways to implement a polling interface. The following example taken from the source code of the Conversation.jws Sample Web service shows one such variation:
public class Conversation {/**
/**
* @common:operation
* @jws:conversation phase="start"
*/
public void startRequest()
{
...
}
/**
* @common:operation
* @jws:conversation phase="continue"
*/
public String getRequestStatus()
{
...
}
* @common:operation* @jws:conversation phase="finish"*/public void terminateRequest(){ }
}
A client uses the startRequest method to initiate a request from a conversational Web service. The client then calls getRequestStatus periodically to check on the result. As before, the client is free to perform other processing between calls to getRequestStatus. The getRequestStatus method returns an indication that the request is pending until the request is complete. The next time the client calls getRequestStatus after the request is complete, the result is returned to the client. The client then calls terminateRequest to finish the conversation.
This section explores several typical design solutions that constitute a good design and create a successful and robust Web service or Java control.
The first question you might need to answer for a Web service or Java control is whether the service or control needs to be asynchronous. There are certainly cases where a non-conversational, synchronous service or control will suffice, especially when the functionality it implements is relatively small, the request handling is relatively short, and the underlying infrastructure supporting this Web service is solid; for instance if you are working on a fail-proof intranet or if your control is called by a (synchronous) Web service on the same server. However, if any of these factors are not true or uncertain at the time of design, you will want to make your service or control asynchronous.
Callbacks are a powerful approach to designing asynchronous Web services or Java controls, relieving the client from periodically checking a request's status, as is required with polling. Especially when it is unclear how long a request will take to process, or if processing times vary wildly, using a callback is likely the most elegant implementation of asynchrony and loose coupling. Using callbacks in combination with buffering of both methods and callbacks is particularly effective in dealing with high-volume traffic. However, callbacks require that the client is designed to accept incoming messages and is hosted in an environment that supports message delivery.
All asynchronous Web services and Java controls should provide a polling interface. If the Web service or Java control is asynchronous, a polling interface is required by any client that cannot accept callbacks; a polling interface is the only way such a client can obtain the results of operations initiated by asynchronous method invocations. You should think of a polling interface as the foundation interface of a Web service or Java control, and callbacks as "extra" functionality that is convenient for clients who can handle callbacks.
The exception to this guideline is a Java control for which the only clients will be conversational Web services or Java controls invoked by conversational Web services. Conversational WebLogic Workshop Web services can always accept callbacks. However, Java controls should be designed to be reusable. Assuming that the only clients a Java control will ever have are WebLogic Workshop Web services limits the reusability of the Java control.
To create an asynchronous Web service or Java control that is robust and handles all situations, it is recommended that you implement both a callback and a polling interface. Your design might (among others) include the following methods:
Other implementations of this design are possible. For a variation, see Using Polling as an Alternative to Callbacks.
For more information, see Designing Asynchronous Interfaces in the WebLogic Workshop Help.
A single Web service may communicate with multiple clients at the same time, and it may communicate with each client multiple times. In order for the Web service to track data for the client during asynchronous communication, it must have a way to remember which data belongs to which client and to keep track of where each client is in the process of operations. In WebLogic Server Process Edition, you use conversations to uniquely identify a given communication between a client and your Web service and to maintain state between operations.
Conversations are essential for any Web service involved in asynchronous communication. This includes Web services that communicate with clients using callbacks or polling interfaces, and Web services that use controls with callbacks.
The following sections provide more information on conversations:
A Web service and a client may communicate multiple times to complete a single task. Also, multiple clients may communicate with the same Web service at the same time. Conversations provide a straightforward way to keep track of data between calls and to ensure that the Web service always responds to the right client.
Conversations meet two challenges inherent in persisting data across multiple communications:
When a client begins a conversation with a service, WebLogic Server Process Edition creates a context in which to keep track of state-related data during the exchange. This new context is identified by a conversation ID, a string that uniquely identifies the conversation. The Web service uses this conversation ID to correlate messages to the client through each operation it performs. The conversation ID ensures that a message sent or received by the Web service is always associated with the appropriate client. You can see the conversation ID in action when you test an asynchronous Web service in Test View.
For more information, see Overview: Conversations in Designing Conversational Web Services in the WebLogic Workshop Help.
Conversations maintain a Web service's state-related data and correlate communications between the Web service, its clients, and other resources. You should implement conversations in any Web service design that is asynchronous or involves multiple communications with a client or Java control in connection with a single request.
When a client calls a service operation that is annotated to start a conversation, WebLogic Server Process Edition creates a conversation context through which to correlate calls to and from the service and to persist its state-related data.
When a conversation starts, WebLogic Server Process Edition does the following:
When WebLogic Server Process Edition performs all of these tasks, it creates a context for the conversation. Each piece of information—including the conversation ID, persistent data, idle time and age—is part of the conversation's context.
The conversation ID is a particularly useful item in the conversation's context. It attaches to each communication, which helps each of the resources, Web services, and clients involved in the conversation identify which communications belong to which conversation. To learn more about conversation IDs, see Overview of Conversations.
As you build services that support conversations, you should keep in mind a few characteristics of conversations. First, WebLogic Server Process Edition automatically handles correlation between two Web services that support conversations. In other words, if your Web service supports conversations and calls the conversational methods of another Web service that supports conversations, WebLogic Server Process Edition manages the conversation, including the conversation ID, automatically.
However, the scope of conversation context is limited to the service itself. You cannot assume that the state of another Web service is being persisted simply because your service calls one of its methods during the course of a conversation. The other Web service is responsible for its own state maintenance.
Also keep in mind that a Web service's state is only updated on the successful completion of methods or callback handlers that are marked with the conversation phase attributes start, continue, or finish. This excludes internal methods of your service, which are not operations and so can not be conversational.
For more information, see Implementing Conversations in Designing Conversational Web Services in the WebLogic Workshop Help.
For more information on conversations, see Designing Conversational Web Services in Designing Asynchronous Interfaces in WebLogic Workshop Help.
|
|
|