Cloud Computing and SOA

There are lot of things happening in the field of SOA, which is making SOA always hot. As far as banefits of SOA is considered, the first banefit comes to our mind is Reusability. Reusability is making our implementation faster as a incremental approach. When our reusable component is attached with the most of the application for integration, it gives the real visibility of SOA. Succes of SOA.

But the time comes when this reusability become resource expensive. This is the time when we need to think of using reuable component in the highly available and computing environment. Initially we would not face any challenges by using reuable component. But day by day our reusable component can go into the heavly used zone.

To overcome this kind of situation Cloud computing comes into picture. Its about creating data centers for higly scalable environment. Not the grid, but the fluid i.e. Cloud. The term called Cloud Computing. The Cloud can be contracted or expanded according to the need of your application at any point of time. Its in evolution process that comes out of grid or distributed computing. Cloud computing is very useful where you need to run high backend as well as front end processing. This all emerged due to the Web 2.0 era. According to the study made, by 2010 there will be 4 billion cell phones. To support these much devices, we need highly scalable, responsive model. To achieve this target Cloud Computing will be very useful.

ESB : Error Hospital

Its time to handle errors occured in Oracle ESB.
I would like to describe Error Hospital using a simple
usecase...

-->execute-->(RS)--async-->callWebService-->(WS)
RS - Routing Service
WS - Web Service

Suppose while invoking callWebService some error occured,
as we are calling web service asynchronously it can be retried.

To automate the process of retring the web service, we need to implement
Error Hospital, which is nothing but a BPEL process.

OWSM : Using Keystores

Today I'm going to talk about the creation of the keystore
for client side and server side, using java keytool.


As in earlier post, I talked about the policies to be applied
to secure web service, now I'll show you the creation of keystore
to sign and encrypt your channel between client and server.


> Create Keystores
Here I'm going to use java keytool to generate keystores.
This tool can be found at location
<java_home>/bin
Create two keystores to be used by client and server as :
Go to cmd prompt

keytool -genkey -alias server -keyalg RSA -keysize 1024 -keystore server.jks -storepass oracle_server -keypass server_key -dname "cn=Lalit Jolania, ou=oracle, o=lntinfotech, c=IN"

Above command will create a keystore file called : server.jks
with
private key alias : server
private key password : server_key
keystore password : oracle_server

Words from OSHO

"Without meditation, energy remains passion; with meditation, the same energy becomes compassion. Passion and compassion are not two energies, they are one and the same energy. Once it passes through meditation, it is transformed, transfigured; it becomes qualitatively different. Passion moves downwards, compassion moves upwards; passion moves through desire, compassion moves through desirelessness; passion is an occupation to forget the miseries in which you live, compassion is a celebration, it is a dance of attainment, of fulfillment...you are so fulfilled that you can share."

OWSM : Applying Policies

To make message flows between client and server secure,
we need to maintain following Policies
1> Authentication - Check whether the user is authenticated
2> Integrity - Check whether message is being altered
3> Confidentiality - Check whether message is being encrypted

Using OWSM you can apply all of the above policies.

Use any one step below to apply authentication :
1> Active Directory Authenticate
2> File Authenticate
3> Ldap Authenticate and others...

Here there are two things to be considered,
one is authenication and other is authorization.
Authentication is simply checking whether the user is providing the right username and password or not...but second thing that is Authorization, meaning whether the person has permission to access particular operation or not.

OWSM allows you to manage authorization also using:
1> Active Directory Authorize
2> File Authorize
3> Ldap Authorize
4> Oracle Access Manager Authenticate Authorize and others...

Everything is happening at OWSM, dont need to worry about...

Next comes Integrity
Sign the message, so nobody can alter it...forcing integrity..
OWSM provides option to sign the message...
SIGN it with your private key on one side...
on the other side VERIFY SIGNATURE with your public key

Next is Confidentiality
The message should not be readable.....no spy can see what are you sending....
Encrypt it using XML Encryption in OWSM...
Decrypt it on other side using XML Decryption....

Applying above policies makes your transaction highly secure...

Just do it...

BPEL MailBox

BPELMailBox
Its all about how to utilize emails to make better Business Process.

Use Case :
Case 1> A sends a mail to service@fusion.com
with subject : upload to fusion directory

Case 2> B sends a mail to service@fusion.com
with subject : leave request from 10/10/2008 to 13/10/2008


Case 3> C sends a mail to service@fusion.com
with subject : book conference room conf2

Case 4> D sends a mail to service@fusion.com
with subject : <action code>

In above cases, each request says different actions to do using email subject code.

Requirements:
1> Use same email id for each request.

2> Service should authenticate users.

3> Service should be hot-pluggable (meaning more services can be added later on.)

Solution:
1> Create one BPEL Process which will be initialised by incoming mail.
The inputvariable should be of type mailMessage.
Refer notification based initialization of BPEL process

Message recieved should be passed to ESB Service as :



2> Create ESB service with input type mailMessage again :
Plug all service to be called as action using routing rules with filter expression.
Filter expression will decide the actionable bpel process.
Note : All BPEL process should be asyncronous with input variable type mailMessage.



There is no need to authenticate...as email server will authenticate you...

Thats all...Now u can hot plug your services to this ESB Mail Box....

Nice IDEA...

Invoking BPEL from Java

1> Import following libraries to project properties -
a> <jdev_home>/intergration/lib
orabpel.jar, orabpel-common.jar, orabpel-thirdparty.jar
b> <jdev_home>/j2ee/home
oc4jclient.jar
c> Add J2EE

2> Create Properties, add following properties in java client
Properties props = new java.util.Properties();
//sets target bpel platform, oracle installation, this will be oc4j_10g
props.setProperty("orabpel.platform","oc4j_10g");
//sets jndi factory class, this is used to locate remote RMI server
props.setProperty("java.naming.factory.initial","com.evermind.server.rmi.RMIInitialContextFactory");
//sets target url for target rmi server (oc4j
props.setProperty("java.naming.provider.url","opmn:ormi://172.28.10.138:6003:oc4j_soa/orabpel");
//sets user name for the remote server
props.setProperty("java.naming.security.principal","oc4jadmin");
//sets password for the remote server
props.setProperty("java.naming.security.credentials","welcome1");

3> Create message to be post to BPEL process
String ssn = "lalit";
// construct the normalized message
String xml = "<input xmlns=\"http://xmlns.oracle.com/HelloWorld\">" + ssn + "</input>";
NormalizedMessage nm = new NormalizedMessage();
//payload is specific to the process you invoke, it is defined in the WSDL used by your BPEL process
nm.addPart("payload", xml );

4> Call BPEL using orabpel api as
Locator locator = new Locator("<domain name>", "<domain password>", props);

DeliveryService deliveryService = (DeliveryService)locator.lookupService(DeliveryService.SERVICE_NAME);

//Invoking bpel process
NormalizedMessage res = deliveryService.request("<bpel process name>", "<operation name>", nm);

//Since we used request, we can retrieve the return message
Map payload = res.getPayload();

Using Map object you can extract payload.

Error Directory

Small information, but useful
While dealing with File Adapters, if you translation fails in between then you can find the rejected messages in particular directory. Information about that is specified below.

Oracle BPEL Process Manager: The errored records during translation are placed by default in the following directory:

<SOA_HOME>\bpel\domains\domain_name\jca\project_directory\rejectedMessages

Oracle Enterprise Service Bus: The errored records during translation are placed by default in the following directory:

<SOA_HOME>\j2EE\jca\event_name\rejectedMessages

Happy learning....

Match made in Heaven

Oracle's aquisition of BEA is making everybody curious. In this post I am going to highlight some of the key features that we will going to see in future - in SOA arena, after BEA addition to the Oracle family.

Highlights:

1) Oracle has integrated WebLogic into both JDeveloper and the Application Server, replacing OC4J. This will be good for performance and stability.

2) Oracle has announced convergence of Oracle ESB and AquaLogic Service Bus towards Oracle Service Bus (will contain strong points of both ESB and AquaLogic-SB.

3) Now JRockit, the world’s leading VM, will be the standard VM for Oracle.

4) Coherence will be the central component for dehydration. So we get zero latency in the VM and unparallelled performance for the dehydration store.

5) Integration of BPM Studio into the BPA Suite is the another good news. I must say that the Oracle BPA Suite, in conjunction with the Oracle SOA Suite (BPEL PM in particular) is the world’s best-of-breed for process management, design and execution. The added functionality from BPM Studio will create a comprehensive set of tools to support both process architecture, design and execution in a fully supported roundtrip engineering environment.

Oracle and BEA: The road ahead...

Probably no other news has created waves like the news of Oracle acquiring BEA for $8.5 billion in April has done. In a recent web conference, Oracle president Charles Phillips and Oracle Fusion Middleware Senior Vice President Thomas Kurian covered product plans in the SOA, development tools, identity management and other middleware spaces.


Taking cue from what Oracle had to say, it plans to categorize BEA products into three areas:

1. Strategic products : These will be adopted immediately with limited re-design into the Oracle Fusion Middleware platform.
2. Continue and converge products : These are BEA products being incrementally re-designed to integrate with Fusion Middleware. These products will continue to be developed and maintained for at least nine years.
3. Maintenance products : These are the ones that BEA had put on an end-of-life status and will get continued maintenance for five years.

Kurian has promised that BEA customers will not need to make forced migrations on account of this acquisition. Customers who are already using BEA products will not have much of a haggle in terms of new licensing, and will continue to recieve maintainance support.

Oracle shall move in the direction of using BEA WebLogic server as the OC4J container. Oracle Service Registry will serve as a UDDI-compliant registry to publish and register services.

The Oracle Data Integration product continues as Oracle's entry in data integration and Oracle BPEL Process Manager provides SOA service orchestration. For event processing, BEA's Weblogic Event Server will be merged with Oracle Complex Event Processor.

Oracle also plans to strengthen BEA's Tuxedo transaction processing software. Tuxedo is geared for C, C++, and Cobol applications as well as customers looking to migrate off of mainframes.

In business process management, the Oracle BPA (Business Process Analysis) designer will be converged with BEA Aqualogic BPM Designer on a common BPM and BPEL-compliant metadata model to move information between these two tools.

So far as development tools are concerned, Oracle will continue with JDeveloper as its integrated toolset.

Oracle Technology Network, the developer's resource, will merge with BEA Dev2Dev and BEA Arch2Arch programs for developers and architects to provide homogenous repository of resources.

Oracle AIA (Application Integration Architecture)

Oracle AIA combines the power of Oracle’s Fusion Middleware along with a set of best in class application Enterprise Business Objects and Services.

FOUNDATION PACK COMPONENTS
> Enterprise Business Object (EBO)
A data model consisting of standard business data object definitions and reusable data components representing a business object

> Enterprise Business Services (EBS)
The application independent web service definition for performing a business task.

> SOA Governance
- Business Service Repository
Catalog of the objects, messages, and services that compose the integration scenarios in your Oracle Application
- Composite Application Validation System
Test integration web services without the deployed participating applications in place.
- Composite Application Error Management and Resolution
Route the error back to the correct application and to the right application user.

> Reference Architecture
Comprehensive documentation to assist in integration development.

WSIF - Web Service Invocation Framework

> It supports a simple Java API for invoking Web services, no matter how or where the services are provided.

> The WSIF API allows clients to invoke services focusing on the abstract service description-the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols.

> The abstract invocations work because they are backed up by protocol-specific pieces of code called providers.

> The decoupling of the abstract invocation from the real provider that does the work results in a flexible programming model that allows dynamic invocation, late binding, clients being unaware of large scale changes to services - such as service migration, change of protocols,etc.

> WSIF also allows new providers to be registered dynamically, so you could enhance your client's capability without ever having to recompile its code or redeploy it.

J2EE Connector architecture

The J2EE Connector architecture defines a standard architecture for connecting the J2EE platform to heterogeneous EIS systems. Examples of EIS systems include ERP, mainframe transaction processing, database systems, and legacy applications not written in the Java programming language. By defining a a set of scalable, secure, and transactional mechanisms, the J2EE Connector architecture enables the integration of EISs with application servers and enterprise applications.

The J2EE Connector architecture enables an EIS vendor to provide a standard resource adapter for its EIS. The resource adapter plugs into an application server, providing connectivity between the EIS, the application server, and the enterprise application. If an application server vendor has extended its system to support the J2EE Connector architecture, it is assured of seamless connectivity to multiple EISs. An EIS vendor needs to provide just one standard resource adapter which has the capability to plug in to any application server that supports the J2EE Connector architecture.

Multiple resource adapters (that is, one resource adapter per type of EIS) are pluggable into an application server. This capability enables application components deployed on the application server to access the underlying EIS systems.

JMS Queue vs Topic

JMS Queue

> A staging area that contains messages that have been sent and are waiting to be read. As the name queue suggests, the messages are delivered in the order sent. A message is removed from the queue once it has been read.

> point-to-point

> Only one consumer will get the message

> The producer does not have to be running at the time the consumer consumes the message, nor does the consumer need to be running at the time the message is sent

> Every message successfully processed is acknowledged by the consumer


JMS Topic

> A distribution mechanism for publishing messages that are delivered to multiple subscribers

> Multiple consumers can get the message

> There is a timing dependency between publishers and subscribers. The publisher has to create a subscription in order for clients to be able to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected will be redistributed whenever it reconnects.

Creating users for Human Workflow

Following steps to create users in Human Workflow -
1> Open file <soa_home>/bpel/system/services/config/users-properties.xml
add user as


2> Go to Administration control for hw_services in Oracle Application Server Control
Click on Security provider


3> Create user -



Thats all...

Notification based initialization of BPEL Process

Follow following steps to initiate BPEL Process using Email notification :
1> Create async bpel process with inputvariable type : mailMessage

2> add MyAccount.xml to location :
soa_home\bpel\domains\my_domain\metadata\MailService

3> Contents of MyAccount.xml


4> add activation agents to bpel.xml after partnerLinkBindings



5> Deploy project

orabpel schema getting locked

If you have changed the password of orabpel schema, didnt made corresponding changes in Oracle Application Server,
then Oracle Application server locks your orabpel schema.

You need to have system user to unlock orabpel in Oracle Database.

So to prevent your schema from locking, make sure to change passwords on both sides.

Service Oriented Architecture

When we talk about SOA - Service Oriented Architecture, means everything is revolving around services. To whom am I talking, is a service. When we come in to open standards, the word service becomes a Web Service. Means we are converting our piece of code into a Web service. So that it provides a flexibility, adaptibility, loose coupling. That is why in big organizations when ERP talks to ERP, there comes into picture SOA.
So that business should flow without any loss of revenue.

Key Principles -
> Standards – Compliance to both common and industry specific standards is required for interoperability between heterogeneous applications.

> Abstraction – Reusable, modular coarse-grained business services provide rapid composite application development and easier maintenance.

> Loosely coupled – Minimal dependencies with other applications offer durability and agility.

So Make more profit using SOA