The process integration functionality of WLI enables you to model, test, deploy, and maintain complex business processes that integrate diverse enterprise systems, cross-enterprise applications, and end-user decision makers.
From the BPM perspective, the enterprise is a set of business services that are accessed through controls and can be orchestrated to model a business process. WLI supports synchronous and asynchronous communications, and stateless and stateful processes.
As you design business processes using the graphical tools (Design view), Oracle Workshop for WebLogic generates the source code automatically in a process file. When you need to write and edit Java code, you can switch to the Source view with a single click.
Table 1 lists the key process integration features of WLI.
Processes are created as Java classes. The process files contain the metadata describing the business logic. |
|
WLI leverages web services, asynchronous communication, and XML messaging at the enterprise level. These services can be used across internal and external integrations, giving application developers the tools to simplify development and integration of loosely coupled and asynchronous applications.
WLI provides native support for web services, including security and reliable messaging. Web services can be invoked from within a WLI process, and processes can be exposed as a web service and made available as resources to other applications and application components.
A business process can be designed to be synchronous or asynchronous based on the method that is used to invoke the process.
Note: | A synchronous process can also contain asynchronous operations, but these must be added after the starting event in the process flow, so that, at run time, the asynchronous processes are executed after the synchronous starting event is completed. |
You can also enable synchronous clients to interact with processes that have asynchronous interactions with resources. A synchronous Oracle Workshop for WebLogic client such as a JSP or portal page that uses a Java control might, for example, need to invoke a process and then wait for a response (block). While the client is blocked, the process may perform asynchronous activities such as queueing a JMS message and waiting for a JMS receive, and then return the response to the client, after which the client is unblocked.
Processes can either be stateless or stateful.
When you set the properties of the process, the following types of persistence can be defined:
Processes can expose their functions to clients in several ways, including through WSDL files, process controls, service broker controls, and JPD proxies.
Process controls can be used for invoking other processes over an optimized transport. The service broker control must be used for invoking other processes and Workshop 8.1-based web services over HTTP or JMS transport. The invoked processes and web services may be deployed on the same domain or on a different domain.
Any Java client – including standalone Java applications, EJBs, JSPs, and servlets – can communicate with any process by using JPD proxies. When the clients use JPD proxies, they make Java method calls using Remote Method Invocation (RMI).
For more information about creating processes, see Guide to Building Business Processes.