Sensors in BPEL

This is an excellent article by Peter Ebell on the usage of Sensors in BPEL.
http://technology.amis.nl/blog/3326/debug-logging-in-bpel-using-sensors-part-1

I could not find the Part2 of this article.

I intend to update this with more information.

Passing Userid and Password Credentials as SOAP Header in BPEL

Problem
There may be Services that have policies enforced to receive the userid/password as part of the requests. If you do not have a Service Bus then this informaton has to be passed from the BPEL.


Solution

1. Right click on the Web Service in Composite Design view
2. Select "Configue WS Policies"
3. Add Client Security Policy as applies to your case. I had to us "oracle/wss_http_token_client_policy"
4. Add the following Binding Properties from the Property Inspector
1. "oracle.webservices.auth.username" : admin
2. "oracle.webservices.auth.password" : admin

If you look at the source generated in the composite .xml, you would see the following

  <reference name="...Service" ui:wsdlLocation="....wsdl">
    <interface.wsdl  ...../>
    <binding.ws port="....."
    
      <property name="oracle.webservices.auth.username" type="xs:string"
                many="false" override="may">admin</property>
      <property name="oracle.webservices.auth.password" type="xs:string"
                many="false" override="may">admin</property>




    </binding.ws>
  </reference>

Increasing memory of JDeveloper IDE

Problem
JDeveloper 11.1.1.3 by default comes with 768M of Max memory. When you have lot of files or objects in memory(I noticed this during XSLT of a large structure) JDeveloper runs out of memory and cannot open the file.

Solution

1. Go to C:\JDeveloperStudio11113\jdeveloper\ide\bin
2. Open ide.conf
3. And increase the memory to 1024 : AddVMOption  -Xmx1024M
4. Restart the Jdeveloper and this should not cause any poblem.

Disabling WS Addressing in BPEL

Background and Problem
In BPEL, the WS Addressing seems to be enabled by default. The external Web Service that is invoked from BPEL Service receives the WS Addressing and first verifies the end point. For some reason this end point that was generated by BPEL is incorrect and so throws an error. The only way the communication can be successful is to disable the WS Addressing.

Solution
In SOA 11.1.1.3, this can be achieved by adding a binding property in the BPEL.

• Select the WebService and you will see the Property Inspector.
• Add the Property "oracle.soa.ws.outbound.omitWSA" and set it to true. As of this version this property is not available in the dropdown. So you need to add this.
• Save it and deploy the new Service to test it out.
• The Steps are shown below as an image

Oracle BPMN2.0 : Important Things To Know

Oracle 11gR1Ps2(11.1.1.3) was released on April 27,  and supports BPMN2.0.

The Oracle documentation for BPMN is available at http://oracle-bpel.blogspot.com/2009/09/oracle-bpel-informative-web-sites.html

Following are the important points worth remembering

• A BPM Process can be converted to BPEL process
• BPM Process is a Composite Application
• Different Types of Business process are
• Synchronous
• Asynchronous
• Manual
• To expose a process as a service, your process must begin with a message start event
• The message start event enables you to specify input and output arguments to a process.
• It supports Timer Start Event which can be scheduled to kickoff at a certain time
• If you are invoking a process or service synchronously, use the service task.

SOA : Design Patterns : Foundational Service Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.


Functional Decomposition (Service Identification Pattern)

• Decomposes the business processes/tasks/problems to smaller ones
• Applies the separation of concerns 
• Helps greatly in Service Analysis and Service Modelling

Service Encapsulation (Service Identification Pattern)

• If Service oriented design principles (http://oracle-bpel.blogspot.com/2010/04/soa-design-principles.html) can be applied to a meaningful extent then the logic can be encapsulated as a Service. 

Agnostic Context (Service Definition Pattern)


Non Agnostic Context (Service Definition Pattern)


Agnostic Capability (Service Definition Pattern)

SOA : Design Patterns : Inventory Centralization Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.


Process Centralization




Schema Centralization


Policy Centralization


Rules Centralization

SOA : Design Patterns : Service Governance Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.


Compatible Change

• This is the most frequently applied pattern once the Service is in maintenance phase.
• The intent should be to make the change backward compatible to the existing Service Consumers.
• Addition of new optional elements in the Schema is a Compatible change
• Similarly any new operations, renaming, adding more messages, policy changes have to be reviewed to make the changes compatible. 

Version Identification

• Design the versioning of the service contract in such a way that the compatible and non compatible changes are expressed clearly to the service consumers.
• The typical convention is the decimal format with major and minor versions.

Termination Notification

• The scheduled expiry of service or operations can be expressed through Termination Notification.
• This can be expressed through WS Policy language through ignorable assertions

Service Refactoring


Service Decomposition


Proxy Capability

• When an existing Service has to be decomposed to multiple fine grained services then the original contract is still used as a Proxy so that the existing service Consumers can still be serviced while the new Service Consumers will start using the new decomposed Services.  

Decomposed Capability


Distributed Capability

SOA : Design Patterns : Service Messaging Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.


Since all the below patterns are incorporated by the SOAP Web Service and current Enterprise Service Buses they are not being elaborated here.


Service Messaging


Messaging Metadata


Service Agent


Intermediate Routing


State Messaging


Service Callback


Service Instance Routing


Asynchronous Queuing


Reliable Messaging


Event Driven Messaging

SOA : Design Patterns : Inventory Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.


Enterprise Inventory

• Services developed in an enterprise are maintained in an Enterprise Service Inventory.
• This helps in standardized contracts, avoids creation of redundant services and easy governance.

Domain Inventory

• When Enterprise Inventory is not possible, then multiple Domain Inventories are created.
• The boundary of domain inventory needs to be carefully established. The boundary could be functional.
• Governance is established at the domain inventory level.

Service Normalization

• This pattern normalizes the existing Services that have overlapping functional boundaries.
• This is done by applying Logic Centralization and Service Abstraction

Logic Centralization

• This pattern targets the creation of Agnostic Service that have a clearly defined boundary.
• Helps in reuse and composability of these Services

Service Layers

• Same as Service Modelling. http://oracle-bpel.blogspot.com/2010/04/soa-service-modelling.html 

Canonical Protocol

• Standardizes the transport and communication protocols for all services in the inventory.
• This is to enable reusability and composability (avoiding the costly protocol bridging)
• Example: WSDL, Schema, Policy, Transport(HTTP), Communication(SOAP) versions.

Canonical Schema

• Standardizes the schema definitions in a service inventory.
• This avoids data model transformation, redundant data definitions and helps in governance

SOA : Design Patterns : Legacy Encapsulation Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.

Legacy Wrapper

• Legacy systems expose the access through wrapper services which do not have a standardized contract and have tight contract to logic coupling and little abstraction.
• This is fixed by wrapping the legacy system with a new legacy wrapper service that has a standardized contract, loose coupling and abstraction.

Multi-Channel Endpoint

File Gateway

SOA : Design Patterns : Service Contract Design Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.

Decoupled Contract

• A contract created by "contract first" approach decouples the Service Contract from the Service Logic. 

Contract Centralization

• Service Contract has to be the sole point to access the Service Logic

Contract Denormalization

Concurrent Contracts

Validation Abstraction

SOA : Design Patterns : Service Implementation Patterns

Note : These are Design Patterns from "SOA Design Patterns" by Thomas Earl. The intent here is to simplify the patterns to a few lines so that they can be referred for a quick glance and also to document my experiences over time. This is by no means an effort to explain these patterns and I believe that the book has done an excellent job at that.

Service Facade

• If a Service Logic supports multiple Service Contracts then a Service Facade Logic helps to reduce the coupling between the Service Contracts and the Service Logic. This will help in the evolution of the Service Logic without affecting the Service Contracts as the Service Facade accommodates any changes.
• The Service Facade Logic is primarily responsible for providing intermediate processing logic in support of the core Service Logic.

Redundant Implementation

• Making multiple instances of the Service available so that it does not become a single point of failure.
• Clustering of nodes and routing through ESB solves this issue

Service Data Replication

• Requires replication of data so that it improves the Autonomy of the Service and improves the performance of the Service 

Partial State Deferral


Partial Validation


UI Mediator

SOA : Design Principles

The following service oriented principles should be applied to the extent possible so that the benefits of SOA can be realized.

1. Standardized Service Contracts

• A SOAP Web Service has the following as part of the contract
• WSDL
• XSD
• WS Policy
• SLA (Service Level Agreement)
• Service Contract is standardized through the application of design standards(contract first approach)
• Standardized naming conventions(expressive)
• Standardized data types(reduces the transformations between data types)

2. Loose Coupling

The different types of coupling are

• Logic-to-Contract Coupling
• Created when the "contract first" approach is followed
• Tight coupling of Service Logic on the Service Contract
• Positive
• Contract-to-Logic Coupling
• Created when the Service Contract is auto generated from the Service Logic
• The Service Contract is dependent on the underlying Service Logic
• Also, auto generation of schemas from the database tables
• Negative

3. Service Abstraction

• Hides the implementation details from the Service Consumers(to be hidden - includes technology, functional, programmatic logic and quality of service information)
• This provides the freedom to evolve the service implementation as required.

4. Service Reusability

• Services should contain and express agnostic logic so that they can be reused across the enterprise.
• Achieving this is very important as the ROI is highly dependent on the degree of reuse achieved
• Some of the design characteristics are
• The Service is defined by an agnostic functional context
• The Service Logic is highly generic
• The Service Contract is generic and extensible
• The Service Logic can be accessed concurrently

5. Service Autonomy

• The level of control over the underlying runtime execution environment.
• Task Services have less autonomy as they compose other services over which they have less control.

6. Service Statelessness

• Stateless Services
• Increase Service Scalability
• Increase Service Reusability
• Consume less computing resources
• Orchestrated Task Services are expected to be stateful
• Entity and Utility Services are generally stateless

7. Service Discoverability

• Services are supplemented with meta data by which they can be effectively discovered

8. Service Composability

• Services should be composable

SOA : Service Oriented Design

This is a gist of Service Oriented Design from the "SOA : Principles of Service Design" by Thomas Earl.

Design Phase

• The Service Oriented Design takes the service candidates and converts them to actual services by creating actual physical contracts.
• It is highly recommended that a high level service inventory be defined prior to creating physical contracts. 
• It is better to follow the waterfall approach in doing the upfront service analysis and service modelling to be followed by agile approach in implementing the services.
• "Contract First Design" is the ideal form of design where the service contract is created before developing the service logic.

SOA : Service Modelling

This is a gist from the "SOA : Principles of Service Design" by Thomas Earl.

Service Modeling, which is a sub process of service oriented analysis  produces conceptual service definitions called service candidates.

During Service Modelling, Services can be primarily classified as follows(Service Models)
1. Entity Services
2. Task Services
3. Utility Services

Entity Services

• Also called as business entity services 
• Represents a business centric service that models a business entity
• Considered to be a highly reusable service that can be composed by the business processes 

Task Services

• Models the business process 
• Typically this composes the entity services to accomplish the business process

Utility Services

• Non business centric services 
• Provides reusable services that do not have business logic
• Examples could be logging, notification, authorization, authentication, etc.

Oracle BPEL 11g Best Practices

1. BPEL has to be primarily used for orchestrating the services. 
• Do not add complex business logic here. It should belong to the service layer.
2. Create scopes for each step of the flow in the process so as to make it modular.  This will help in creating local variables within that scope. Use Global variables when required(just like your java or C++ programming style). This will help in maintainability. Note : Adding too many scopes may affect the performance. In that case you may want top consider creating sequences.
3. Adopt naming standards and comply to it. This should be part of the governance strategy. This looks trivial but is important if you want someone else to understand the code and make changes.
4. It is good practice to have a Mediator in the Composite. Try to get most of the transformations done by the Mediator.
5. Have all the business rules implemented by the Oracle Business Rules
6. Handle all the exceptions
7. Adopt test driven development. Create test cases with a tool like SoapUI for each process and make this part of your governance strategy.
8. Instead of BPEL, you should consider implementing the process in BPM. This has the advantage of modeling it in BPMN so that it can be easily understood by the Business and also helps the model and implementation to be synchronized at all times. If you haven't considered it so far then it is time you take a look at 
9. The flow of the BPEL process should be very intuitive.
• The reason enterprises are investing heavily in this to be agile to change. So, to make this happen , make the steps in the flow linear as much as possible so that a new step can be added/reordered easily by just drag and drop. I have seen very complex nested creation of the following flow which after refactoring looks as below.

Oracle Service Registry OSR 11g Installation

Oracle Service Registry(OSR) is part of the Oracle SOA Governance strategy but comes as a separate download. The installation is 2 steps

1. Installation of OSR files into registry111 folder under oracle middleware home
2. Creation/Extension of a Weblogic 11g domain with the OSR server

Installation Steps

• Execute java -jar oracle-service-registry-11.1.1.jar. This will launch the installation wizard.
• I found it easier to create the tablespace and the schema user before hand. I had to do this as for some reason the installation failed to create the tablespace for me.
• Once the registry111 folder is create then create or extend the existing weblogic11g domain
• If you face any problem during the domain process then cleanup and create the tablespace again.

OER 11g Thoughts

IMHO, the Oracle Enterprise Repository looks like a piece of work from interns(no disrespect to interns). It lacks the enterprise and professional quality that is expected from Oracle, BEA or any other enterprise vendor. This probably is a result of the acquisition and the need to have an extra check in the checklist.

The OER is deployed in the BEA domain. It has 2 parts. One is the the ability to search and view the assets and the second is the ability to manage the assets. The search can be done through the web while the asset management is through a Java Webstart application. Both the applications fall way short of usability.

I am not convinced that both OER and OSR(Oracle Service Registry) are required as they add to the clutter. The OER functionality could be built into the OSR so that the intra enterprise view could be the OER functionality while the extra enterprise view could be the OSR. This will reduce the amount of applications to be purchased, managed and maintained by the enterprises. This will also help in easier adoption of the Governance and in better governance by managing the assets well.

Oracle Enterprise Repository 11g Installation

Installation

• OER11g comes as a separate installation. It can be installed on an existing SOA/WL 11g.
• Download OER 11g as OER111120_generic.jar
• Execute the following DB scripts

CREATE TABLESPACE OER_SOA1_DATA

DATAFILE '/opt/oracle/oradata/oer/oer_soa1_data.dbf' SIZE 300M

AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL AUTOALLOCATE

LOGGING

ONLINE

SEGMENT SPACE MANAGEMENT AUTO;

CREATE TABLESPACE OER_SOA1_INDEX

DATAFILE '/opt/oracle/oradata/oer/oer_soa1_index.dbf' SIZE 300M

AUTOEXTEND ON NEXT 5120K MAXSIZE UNLIMITED

EXTENT MANAGEMENT LOCAL AUTOALLOCATE

LOGGING

ONLINE

SEGMENT SPACE MANAGEMENT AUTO;

CREATE USER OER_SOA1 IDENTIFIED BY password

DEFAULT TABLESPACE OER_SOA1_DATA

TEMPORARY TABLESPACE TEMP

PROFILE DEFAULT

ACCOUNT UNLOCK;

GRANT "CONNECT" TO OER_SOA1;

ALTER USER OER_SOA1 DEFAULT ROLE "CONNECT", "RESOURCE";

GRANT CREATE MATERIALIZED VIEW TO OER_SOA1;

GRANT CREATE SEQUENCE TO OER_SOA1;

GRANT CREATE SESSION TO OER_SOA1;

GRANT CREATE SYNONYM TO OER_SOA1;

GRANT CREATE SNAPSHOT TO OER_SOA1;

GRANT CREATE TABLE TO OER_SOA1;

GRANT CREATE TRIGGER TO OER_SOA1;

GRANT CREATE VIEW TO OER_SOA1;

GRANT UNLIMITED TABLESPACE TO OER_SOA1;

• There are 2 steps involved. First is to install the OER in the middleware/repository111 folder. The second is to create a new domain or extend an existing one with the OER. See below for the steps.
• Run java -jar OER111120_generic.jar This will launch the installation screen. Enter the DB information.
• After installation, create a weblogic domain with OER
• The default port is 7101.
• Note : I could not install this on a SOA Suite. I tried to create a new domain and the installation wizard displays the status of 90% and hangs over there. So I installed a vanilla Weblogic11g and then installed OER on that. This works fine.
• The URL is http://localhost:7101/oer 
• The login is "admin" and "admin"

Note: If you have face an error during the installation you have to clean the tablespace and redo the domain creation/extension process.