Friday, February 13, 2009

Correlations in Open ESB

Introduction

Consider the usual supply-chain situation where a buyer sends a purchase order to a seller. The seller needs to asynchronously return an acknowledgement for the order, and the acknowledgement must be routed to the correct business process instance at the buyer. How do we guarantee that we are talking to the original instance at buyer side? To solve this, the obvious and standard mechanism in BPEL is Correlations. Correlations use key fields of data which may uniquely identify the conversation/instance. Thus correlations enable processes to participate in the stateful conversations. In the above scenario, it carries a business token in the order message (such as a purchase order number) that is copied into the acknowledgement for correlation. The token can be in the message envelope in a header or in the business document (purchase order) itself. In either case, the exact location and type of the token in the relevant messages is fixed and instance independent. Only the value of the token is instance dependent.

Definition: The idea of associating business-application-specific data found in the messages to maintain references to business process instances is termed BPEL Correlations



As Correlation is the key concept in BPEL and OpenESB is an emerging technology, this Sun BluePrints™ explains how to implement BPEL Correlations in Open ESB. The article addresses the following topics.

  • Overview of Correlations

  • Business Case

  • Implementation in Open ESB

This article assumes that you have basic understanding of Open ESB architecture and BPEL constructs. It also assumes that you are familiar with NetBeans 6.0 IDE.

Overview

As the name states, Correlation is simply associating a message with another message via some identifier. Coming to BPEL Correlations, It allows the business process to be waiting until the correlation message arrives. It is basically used in Asynchronous message exchanges.

Click here to view the complete solution http://ravi-blog.googlegroups.com/web/Correlations_OpenESB_Blueprint.pdf

Thursday, February 5, 2009

SOAP BC in Open ESB

This article describes the instructions of SOAP BC usage in association with BPEL SE in OpenESB.

SOAP Binding Component provides external connectivity for SOAP over HTTP and BPEL Service Engine allows users to implement the business logic in the BPEL flow.

Objective:

The objective of this exercise is to implement the Business Process to receive the Soap request from client, do transformation and send back the Soap response to client. Soap Binding Component used to receive the soap request and send back the soap response and BPEL Service Engine helps for transformation and other business logic.



Follow this link http://groups.google.co.in/group/ravi-blog/web/Soap.pdf for complete solution

Monday, February 2, 2009

Subversion setup on Solaris for Access Control

What is Subversion

Subversion is a free/open-source version control system. That is, Subversion manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. Subversion can access its repository across networks, which allows it to be used by people on different computers. http://subversion.tigris.org/

Architecture

On one end is a Subversion repository that holds all of your versioned data. On the other end is your Subversion client program, which manages local reflections of portions of that versioned data (called “working copies”). Between these extremes are multiple routes through various Repository Access (RA) layers. Some of these routes go across computer networks and through network servers which then access the repository. Others bypass the network altogether and access the repository directly


Installation

Go to http://www.sunfreeware.com/programlistsparc9.html (Search for subversion-1.4.3-sol9-sparc-local.gz or subversion)

Extract the installable and also download below listed pre-requisite softwares that required for sub version from the same site.

  • apache-2.0.59
  • neon-0.25.5
  • swig-1.3.29
  • openssl-0.9.8c
  • db-4.2.52.NC
  • expat-1.95.5
  • gdbm-1.8.3
  • libiconv-1.9
  • libgcc-3.4.6
  • libxml2-2.6.26
  • zlib-1.2.3
  • openssl-0.9.8e

Make ftp all the above installables to Solaris system.

Most of the installables are in the form of .gz/.z extensions, we need to extract them using gunzip/gzip utility.

For example, gunzip subversion-1.4.3-sol8-sparc-local.gz this extracts the actual installable to current directory. After running this command, user can observe this file in the current directory, subversion-1.4.3-sol8-sparc-local, which is the actual installable package.

Run the below command to install the package.

pkgadd –d subversion-1.4.3-sol8-sparc-local

Follow the below steps to install all other pre-requisite softwares.

  1. gunzip (e.g., gunzip db-4.2.52.NC-sol9-sparc-local.tar.gz)
  2. pkgadd –d (e.g., pkgadd -d db-4.2.52.NC-sol9-sparc-local.tar)

Repository

Use the svnadmin utility to create the repository.

svnadmin create /subversion/repository This command creates a new directory /subversion/repository and stores repository related information like Berkeley DB, conf etc., Once the repository is created, we need to import the directories & files into the SVN repository using the following procedure.

1. Create a directory structure and files on your hard disk

  • mkdir /root
  • mkdir /root/nodes
  • mkdir /root/nodes/node1
  • mkdir /root/nodes/node2
  • mkdir/root/nodes/node1/leaf1
  • mkdir /root/nodes/node2/leaf2

2. Use the import command and import the structure into SVN repository

svn import /vzw file:///subversion/repository -m "initial import

Subversion Server

A Subversion repository can be accessed simultaneously by clients running on the same machine on which the repository resides using the file:/// method. But the typical Subversion setup involves a single server machine being accessed from clients on computers all over the office—or, perhaps, all over the world.

There are two ways to setup the subversion server. One is Apache Webserver in which the server can be accessed using normal http protocol and another is svnserve a small, standalone server program that speaks a custom protocol with clients.

In this version, we’ll be configuring svnserve server.

Run the below command to start the svnserve server as a standalone “daemon” process.

svnserve -d -r /subversion/repository

-r option effectively modifies the location that the program treats as the root of the remote filesystem space. By using this option, user doesn’t need to give the absolute path of the repository while checking out.

svn checkout svn://host.example.com/project1 (If uses –r option)

svn checkout svn://host.example.com/subversion/repository/project1 (without –r option)

Authentication & Authorization

When a client connects to an svnserve process, the following things happen:

· The client selects a specific repository.

· The server processes the repository's conf/svnserve.conf file, and begins to enforce any authentication and authorization policies defined therein.

· Depending on the situation and authorization policies,

o The client may be allowed to make requests anonymously, without ever receiving an authentication challenge, OR

o The client may be challenged for authentication at any time

In this version, we are setting of Read/Write access for the set of users and Read access for anonymous uses on the repository.

1. Go to the repository installation folder and followed by conf

a. cd /subversion/repository/conf

2. Open the svnserv.conf file in vi/text editor

3. Un comment the below two lines, which enables read access for anonymous users and Write access for authenticated users.

anon-access = read

auth-access = write

4. Un comment the below line and give the value of the realm as Repository’s uuid. To find out this uuid, go to db folder under repository (cd /subversion/repository/db) and display the contents of uuid file (cat uuid).

realm = 5f437005-2437-0410-b26a-d6881fc15dd9

5. Save the file and close the editor

6. Open the passwd file in vi/text editor from conf directory

7. Enter the user names along with the passwords that you want to give write access. Finally the file should look like below, if you add 5 users. # represents for commented line which comes with the default file.

[users]

# harry = harryssecret

# sally = sallyssecret

svnuser = svnpwd

8. Save the file and close the editor.


MQ Installation and Server to Server Communication on Solaris

Objective:

This article describes the detailed instructions of Websphere MQ installation, configuration of Queue Managers and setting up Server to Server Communication between two MQ Servers.

Before going into the main part, would like to walk through on MQ and it's components.

About MQ

As a whole, MQSeries enables messages to be exchanged, either synchronously or asynchronously, between application programs running on one or more target systems. Messages traveling between programs are stored on message queues, which are under the control of a service provider called a queue manager. In general,a queue manager is required on each target system.

MQSeries can be configured to provide assured delivery of the messages. Assured delivery means that even if the hardware or software platform crashes the messages within the system will still be delivered, once the platforms are brought back up. On a typical target system MQSeries consists of a queue manager and a number of queues and channels.

Message

An MQSeries message is simply a collection of data sent by one program and intended for another program. The message consists of control information and application specific data. The control information is required in order to route the message between the programs, and, to some extent, describe the contents of the application data section. The application data is free-form and MQSeries places no overall constraint on the contents. A message can be classed as persistent or non-persistent. A persistent message will survive a software or hardware crash / reboot, once communicated to a queue manager, whereas a non-persistent message will not survive.

Queue Managers

It is the queue manager that provides the queuing services to the application programs. A queue manager also provides additional functions so that administrators can create new queues, alter the properties of existing queues and control the operation of the queue manager. It is possible to connect queue managers on different platforms together, this is achieved via a mechanism called channels.

Queues

Queues are named message repositories upon which messages accumulate until they are retrieved by programs that service those queues. Queues reside in, and are managed by, a queue manager. They can open a queue, put messages on it, get messages from it, and close the queue. Queues are either defined as local or remote. Local queues allow programs to both put messages on, and get messages off, while remote queues only allow programs to put messages on. Remote queues are used in order to provide put access to queues that are local to another platform. Any message put onto a remote queue is automatically routed to the associated platform and local queue by the queue manager via the channels mechanism.

Channels

Channels are named links between platforms across which messages are transmitted. On the source platform the channel would be defined as a sender and on the destination platform as a receiver. It is the sender channel definition that contains the connectivity information, such as the destination platform's name or IP address. Channels must have the same name on both the source and destination platform.

Installation

Download MQ 6 trial version from the below URL to the Solaris system

https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?S_PKG=sparc&source=wsmq90&S_TACT=105AGX28&S_CMP=TRIALS

  • Create a mqm group < groupadd -g 998 mqm >
  • Create an user and add it to the group < useradd -u 999 -g mqm -c "mq user" mqm >
  • Change the password of the newly created user < passwd mqm >

Most of the installables are in the form of .gz/.z extensions, we need to extract them using gunzip/gzip utility.

  1. gunzip WMQv600Trial-sparc_solaris.tar.Z this extracts the actual installable to current directory. After running this command, user can observe this file in the current directory, WMQv600Trial-sparc_solaris.tar, which is the archive package for installables
  2. Untar the file using tar command tar xvf WMQv600Trial-sparc_solaris.tar which extracts the installation into current directory
  3. Agree the license by executing mqlicense.sh file in the extracted directory
  4. Run the installations by adding packages into system using the pkgadd utility
  5. pkgadd –d. (This command shows the available packages in the current directory)
    Add all packages


Setup of sample Queue Manager & Queue

  1. Create a Queue Manager
    • crtmqm –q qmDefault
  2. Start the queue manager
    • strmqm qmDefault
  3. Create a Queue
    • runmqsc (To enable MQSC commands)
    • define qlocal (‘qTest’)
    • end (To stop MQSC)
  4. Put a Message in queue
    • cd /opt/mqm/samp/bin
    • ./amqsput qTest
    • Enter the input text as "This is a sample message" and press Enter twice
  5. Retrieve a Message
    • cd /opt/mqm/samp/bin
    • ./amqsget qTest

SERVER TO SERVER COMMUNICATION

Setup of Sender Workstation

  1. Create a default queue manager called QMSENDER. At a command prompt in a window, enter the following command:
crtmqm -q QMSENDER

The -q option specifies that this queue manager is the default queue manager.

Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.

  1. Start the default queue manager. Enter the following command:
strmqm QMSENDER

A message tells you when the queue manager starts.

  1. Enable MQSC commands. Enter the following command:
runmqsc

The message Starting WebSphere MQ Commands is displayed when MQSC has started. MQSC has no command prompt.

  1. In the MQSC command window, define a local queue to use as a transmission queue called QMA. Enter the following command:
define qlocal(TRANSMITQSENDER) usage(xmitq)

The message WebSphere MQ queue created is displayed when the queue is created.

  1. In the MQSC command window, create a local definition of the remote queue. Enter the following command:

define qremote(LOCAL.DEF.OF.REMOTE.QUEUE) rname(SAMPLE.QUEUE) rqmname('QMRECEIVER') xmitq(TRANSMITQSENDER)

The rname parameter specifies the name of the queue on the remote machine to which the message will be sent. Therefore, the name that the rname parameter specifies must be the name of the queue to which you want to send the message (that is, sample.queue on the receiver workstation). rqmname is the queue manager name on the remote machine.

  1. In the MQSC command window, define a sender channel. Enter the following command:

define channel(QMSENDER.QMRECEIVER) chltype(sdr) conname("con-name(port)") xmitq(TRANSMITQSENDER) trptype(tcp)

Where:  

con-name is the TCP/IP address of the receiver workstation.

port is the port on which the listener will be running on the receiver machine, the default value is 1414.

  1. In the MQSC command window, stop MQSC. Stop MQSC. Enter the Command: end

You have now defined the following objects:

  • A default queue manager called QMSENDER
  • A transmission queue called TRANSMITQSENDER
  • A remote queue called LOCAL.DEF.OF.REMOTE.QUEUE
  • A sender channel called QMSENDER.QMRECEIVER

Setup of Receiver Workstation

  1. Create a default queue manager called QMRECEIVER. At the command prompt, enter the following command:

crtmqm -q QMRECEIVER

Messages tell you that the queue manager is created, and that the default WebSphere® MQ objects are created.

  1. Start the queue manager. Enter the following command:

strmqm

A message tells you when the queue manager starts.

  1. Open a new command prompt window and enable MQSC commands. Enter the following command:

runmqsc

The message Starting WebSphere MQ Commands is displayed when MQSC starts. MQSC has no command prompt.

  1. In the MQSC window, define a local queue called SAMPLE.QUEUE. Enter the following command:

define qlocal(SAMPLE.QUEUE)

The message WebSphere MQ queue created is displayed when the queue is created.

  1. In the MQSC window, create a receiver channel. Enter the following command:

define channel(QMSENDER.QMRECEIVER) chltype(rcvr) trptype(tcp)

  1. In the MQSC window, start the default WebSphere MQ listener by entering the following command:

start listener(SYSTEM.DEFAULT.LISTENER.TCP)

  1. In the MQSC window, verify the listener process has started by executing the command:

display lsstatus(SYSTEM.DEFAULT.LISTENER.TCP)

  1. In the MQSC window, stop MQSC. Enter the following command:

end

You have now defined the following objects:

  • A default queue manager called QMRECEIVER
  • A queue called SAMPLE.QUEUE
  • A receiver channel called QMSENDER.QMRECEIVER

Starting Channel

  1. If the queue managers on the two workstations have stopped for any reason, restart them now using the strmqm command.
  2. On the sender workstation, enable MQSC commands. Enter the following:

runmqsc

  1. Using the MQSC window, start the sender channel. Enter the following command:

start channel(QMSENDER.QMRECEIVER)

The receiver channel on the receiver workstation is started automatically when the sender channel starts.

  1. Using the MQSC window, stop MQSC. Enter the following command:

end

Testing Communication between the Workstations

  1. On the sender workstation, in a new command window, put a message on the queue by entering the following command from /opt/mqm/samp/bin directory
amqsput LOCAL.DEF.OF.REMOTE.QUEUE

This puts the message to the local definition of the remote queue, which in turn specifies the name of the remote queue.

  1. Type the text message, then press Enter twice.
  2. On the receiver workstation, get the message from the queue by entering the following command from /opt/mqm/samp/bin directory
amqsget SAMPLE.QUEUE

The sample program starts, and your message is displayed. After a short pause, the sample ends and the command prompt is displayed again.

Thus it proves the server to server communication by sending one message from the remote queue on the sender workstation to the local queue on the receiver workstation using XMITQ, Sender/Receiver Channels and Listener.


Executing scripts with root permissions in Open Solaris

In open solaris, we cannot login with root user, however if you want to execute the scritps/commands that requires root permissions, you can use pfexec

e.g., pfexec <command_to_execute>