Dynamic and reusable SOA Implementation

With the introduction of SOA, SOA has been greatly developed, and business processes (including atomic services) can now be organized into executable files. But so far, or is this the highest degree of reusability and flexibility possible?

In this article, we will introduce the Oracle service registry (OSR ). You will learn how to relax the tightly coupled BPEL process without sacrificing performance, and create a reusable and discoverable file library that benefits the Enterprise.

Set

The example scenario contains two BPEL flows: one master process, which is used to call the other process named calleeprocess. In general, when constructing a scenario, the main process is closely coupled with its service by referencing its specific binding definition (WSDL.

After creating a BPEL process, the Creator has determined the message mode provided by the process. The operation can be asynchronous or synchronous.

See the following calleeprocess definition.

In the preceding example, the service interface of a process provides an operation called "process", which defines an input (calleeprocessrequestmessage) and an output (calleeprocessresponsemessage) message.

In this case, the BPEL process does not contain any information about its location or the technology used to call it.

After deploying a BPEL process to a service, you must implement the WSDL interface and add a physical endpoint. In this case, the definition is changed from abstract to concrete.

 

Now, the process (calleeprocess) has become a service. You can use its specific WSDL location and use it as the basis of partnerlink to reuse it in another process.

After the deployment is successful, you can call masterprocess. This will trigger the execution of calleeprocess, and its communication is completely processed in the memory.

Detach a Service binding from a BPEL Process

After the preparation is complete, the first step to implement a loosely coupled system is to strip the implementation from the definition of calleeprocess (called by masterprocess.

Applying this pattern to a BPEL process can bring great flexibility because the specific service implementation in use can be changed without changing the process itself.

In this step, after registering a specific service definition to OSR, it can be found throughout the enterprise.

Based on the UDDI data model, a service is a breakdown of a business (which can be grouped by purpose. (Note: There is no connection between business and visibility .)

You only need to publish a WSDL under the UDDI business entity to add a service definition (in this example, the service definition of calleeprocess), as shown below.

After the release process is complete, you can add the service definition to the Service (dynamicdiscoverybusiness), create a UDDI item for calleeprocess, and add a binding to the physical endpoint.

Currently, the only physical endpoint in the UI of the service registry can be found. To call a service, you must call this endpoint. To make dynamic binding irrelevant to technology and implementation, you need to add a new binding. The binding type is wsdldeployment, which will be used by the BPEL engine at runtime.

Now, you can apply the BPEL process and add key information to the BPEL domain to implement dynamic service registry query. First, you must add a unique service key for calleeprocess to partnerlink. Click the service item detail to find the key.

As described in "using ESB to virtualize the service endpoint of the BPEL process", partnerlink can contain specific attributes for modifying or enhancing its runtime behavior. In this example, the flag is registryservicekey, which is a unique UDDI identifier that enables the BPEL server to discover specific service definitions in OSR at runtime.

The last information required for the query is to configure the BPEL server, which contains information about the location of the target OSR instance (uddilocation). To enhance security, it can also contain the user name (uddiusername) and Password (uddipassword ).

Why apply these changes? Now, the process is separated from the physical implementation of the service. The process can query the OSR instance at runtime to retrieve and call the endpoint. This means that the service can be moved without modifying the Process configuration when the hardware or software changes, because all information is stored in the service registry.

The last step is to accept the specific WSDL, And the partnerlink is not displayed in the image. Importantly, the BPEL Compiler (bpelc) needs information about operations and types to ensure the type integrity before deployment. However, it is not necessary to provide all binding information.

This means that abstract WSDL is used instead of providing specific WSDL. View the process descriptor again, which will reveal its location.

As shown above, the wsdllocation attribute is not directed to the specific WSDL of calleeprocess.

The re-compilation and deployment process will achieve the loose coupling we expect.

This process does not contain any information about the technology or its endpoints used to implement the service.

Conclusion

On the premise that masterprocess knows the Technology and Its calling process (calleeprocess), it is easy to dynamically bind and manage endpoints and properties completely independent of the business process.

Key information is now located in a searchable, UDDI V3-compliant registry and can be found at runtime, allowing the process to provide maximum flexibility. Despite the introduction of another component, the performance between the user and the provider has not been significantly reduced, thanks to the Registry's precise memory lookup and Endpoint calls.

View Original