Friday, May 22, 2009

Oracle Fusion Middleware Architecture

As many of you aware that Sun was acquired by Oracle in April, 2009.

There is a big overlap on software products of Sun & Oracle like IDM, SOA, Database etc., Each of it's product has got it's own strengths and weakness.

As we don't know which sun products are retained by oracle and what products will be merged/scrapped etc., we have started evaluating some of Oracle products

I have spend sometime to understand Oracle Fusion Middleware which is similar/competitor to Sun JavaCAPS/Open ESB.

I had drawan a diagram to depict my first level understanding on Oracle SOA suite as shown here.

It contains 3 broad categories, Design Time, Run Time and Administering/Monitoring tools.

1. The underlying layer is the Oracle ESB, which provides adapters, routing services etc.,

2. On top of it, OWSM (web service manager) is available for communicating across applications via web services

3. Third layer is the heart of any SOA tools, which is called BPEL Process Manager

4. Fourth layer is the Oracle Business Activity Monitoring for providing dash boards

5. Above this, some applications like B2B (Business to Business Integration) available

To administer/monitor all of the above, there are some monitoring tools available from each layer as shown in the diagram

Oracle JDeveloper and Eclipse IDEs supports design time activities for the developer to develop SOA applications

These applications can be deployed and run on to the application servers like Oracle App Server or Weblogic etc.,

Tuesday, March 10, 2009

Comprehensive example in Open ESB using File, FTP, JMS, JDBC and Soap

The last 5 articles explains different binding components (File, FTP, Soap, JDBC, JMS) usage in Open ESB. To summarize and get more understanding of each of this BC, here is a comprehensive scenario using all of these binding components. Let's define a problem that requires to use all these BCs.

Problem Description: Get the employee details from the database based on employee id and publish it in JMS. There will be two different subscribers who listens to JMS and consumes the message based on some filter logic and publish the message either on local file or on FTP server. The whole solution should be exposed as a web service so that it can be accessible to any web service client.
Let's assume that you have to implement this solution in normal application like Java/.Net. You'll have to take care of the following major things apart from business logic
  • Management of Database connections
  • Management of JMS connections
  • Management of FTP connections
  • Management of File streams
  • Web service implementations

In case, you are using SOA application all of the above are taken care by the respective binding components and user can only concentrate on the business logic.

Click here to view the complete solution in Open ESB

Below is the solution overview diagram



JMS/Messaging in Open ESB

As we know that messaging in the core technology in any ESB/SOA application, this article explains how messaging has been addressed in Open ESB using JMS Binding Component.

Follow this link to get the complete solution on the usage of JMS BC with a sample business scenario

Connecting to database in OpenESB

In any application, there is a maximum probability of using database, so here is the need on how to interact/connect with different databases from the application. There are many solutions available in each of the application like java/.Net/PHP etc., but the same need to be addressed in any of ESB/SOA application as well.

Let's see how this is addressed in Open ESB. Even in Open ESB, there are multiple solutions available like SQL SE, JDBC BC to connect to the database but this article explains the database connectivity using JDBC BC.

Follow this link to get the complete solution.

FTP in OpenESB

Previous article describes the transferring of files from one location to other location within file system with some conversion of the message using Encoders but most of the real time requirements involves upload/download of files from the remote location using the FTP protocal.

As this is common requrement in many of the SOA/ESB solutions, we are going to discuss how we can achieve this in Open ESB

Click here for the problem description and detailed solution of File Transfer using FTP protocol in Open ESB

Monday, March 9, 2009

Encoders in Open ESB

In any ESB/SOA application, message transformation like converting the message from one format to another specific format is the minimum requirement, this article describes how you can achieve this in Open ESB.

The application receives the CSV file and transforms in to XML file using Java EE Engine in OpenESB. Click here to view the complete solution

The main component used here is Encoders in Open ESB

Friday, March 6, 2009

MySQL Presentation

During Tech Fest,09 of Jawaharlal Nehru Technological University, I got a chance to represent Sun to present any of the Sun Technologies. I have prepared presentation on MySQL and presented the same to a group of students, professors and HODs of around 200 people on 27th Febraury, 09 (3PM-4PM).

Below are the items that were covered in presentation

  • Introduction
  • Features
  • Architecture
  • High Availability & Scalability
  • SQL Scripts, Stored Procedures & Triggers
  • Query Optimization
  • Client Interfaces
  • GUI Tools
  • Summary

Click on this link to view the presentation http://ravi-blog.googlegroups.com/web/MySQL.pdf

I was presented a memento from JNTU for this event




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>

Wednesday, January 21, 2009

DUAL BOOTING – Win XP & Open Solaris

So far I used to work with VMWare/xVM for Unix/Solaris OS on Windows XP. This was a fantastic approach to run multiple operating systems parallel, this is useful especially in testing your software in different environments. The only concern is, it is not as fast as the original Operating System.


Recently I thought of working on Solaris Desktop, so started making my machine dual booting in which one partition is dedicated to Windows XP where as the other one is allocated to Open Solaris. I thought of sharing the steps that I have taken to make my system dual booting.


Firstly my system was installed with Windows XP one one partition (C drive).


User has to make some unformatted space for the solaris to be installed on one of the drive.


Insert the Open Solaris bootable CD in to the CD Drive and re-boot the system.


Ensure that the system loads from CD drive (F12 or F2 keys will be helpful to set this setting during booting)


System will start installing Open solaris from the CD on the unformatted drive. During installation it prompts user for root password, another user and password and host name. User can give the values for his/her choice. Once the installation completes, the system re-boots and prompts user for the login name and password to enter in to the solaris desktop.


NETWORK SETUP


In order to setup the network on Solaris OS, user has to install the network driver first. As a pre-requisite, get the network driver from the net ( http://www.marvell.com/drivers/driverDisplay.do?driverId=180 ) into the USB driver or CD and install the same from that media.


After installation of the driver, setup the network


Go to System → Administration → Network option and enter the values for IP address, Subnet mask and Gateway IP and DNS Server addresses. Alternatively user can change the following files manually.

  1. Edit /etc/hosts file and add an entry with IP address

  2. Edit /etc/nsswitch.conf file and change the value “hosts: files” to “hosts: files dns”

  3. Add new file under /etc with the name defaultrouter and with the following contents

    • nameserver xx.xx.xx.xx where xx is the DNS server IP address (Primary)

    • nameserver xx.xx.xx.xx (Secondary DNS IP)

Run the below commands on the terminal

  1. ifconfig -a plumb

  2. ifconfig yukonx0 xx.xx.xx.xx/24 up where xx.xx.xx.xx is IP address of the system

  3. route add default xx.xx.xx.xx where xx.xx.xx.xx is IP address of the Gateway

With this setup, the network should be enabled, please remember that this is static IP network not a DHCP. BTW, ifconfig -a should tell you the configured IP addresses


Internet also should come by default after configuring the network. In any case, if you are unable to connect to the Internet from the browser, follow the below steps

  1. Run the command on terminal, svcadm disable network/physcial:default

  2. Change the file /etc/nwam/llp by adding the below line

    • yukonx0 static xx.xx.xx.xx/24 where xx.xx.xx.xx is the static IP address

  1. Run the command on terminal svcadm enable network/physical:nwam


That's it. You are ready to use the Solaris desktop with net and internet configured.


Friday, January 16, 2009

Myself

I'm Ravi Kumar KNV and I have been working in Information Technology (Software) since 1999. I was a post graduate (M.Sc) in Mathematics from Osmania University and also completed GNIIT (Graduation in Computer course) from NIIT.

Most of my experience involved in integration domain (EAI,SOA), in which providing client solutions on different integration tools like Cordys, ICAN, JCAPS and OpenESB. Also involved in design aspects and corporate trainings on Sun Middleware products of ICAN & JCAPS.