How to change dehydration store DB for SOA Suite

This article explains about pointing SOA 10g suite dehydration data store to another database.

• Install another database instance and ensure that the new target database is running.
• Run IRCA script to create schemas for BPEL, ESB and OWSM in the new Database. example: irca all "localhost 1521 v102" welcome -overwrite
• Backup the file- ${OC4J_HOME}\config\data-sources.xml
• Change the following ESB and BPEL connection pools to point to new DB resource

1. BPELPM_CONNECTION_POOL
2. ESBAQJMSPool
3. ESBPool

You can use either Enterprise Manager Console to perform these changes or edit the file: ${OC4J_HOME}\config\data-sources.xml

Below is a sample of configuration for BPELPM_CONNECTION_POOL in data-sources.xml<

<connection-pool name="BPELPM_CONNECTION_POOL">

<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource"

user="orabpel_OracleAS_1" password="orabpel" url="jdbc:oracle:thin:@localhost:1521:xe"/>
</connection-pool>

• If you are changing from Olite DB to Oracle EE, look in the project's build.properties files for DB_URL and change DB_VENDOR from "olite" to "oracle"
  DB_VENDOR=oracle
  otherwise no change is neccesary.
• Update ESB Metadata - Connect to ESB schema (ORAESB) and change the value of DT_OC4J_HOST and DT_OC4J_HTTP_PORT to match your environment Hostname and Port and by running the following SQL script:

insert into esb_parameter values('ACT_ID_RANGE', '400');

insert into esb_parameter values('DT_OC4J_HOST', 'soainternal.mycompany.com');

insert into esb_parameter values('DT_OC4J_HTTP_PORT', '7777');

insert into esb_parameter values('PROP_NAME_INITIAL_CONTEXT_FACTORY', 'com.evermind.server.rmi.RMIInitialContextFactory');

insert into esb_parameter values('PROP_NAME_DEFERRED_TCF_JNDI', 'OracleASjms/MyTCF');

insert into esb_parameter values('PROP_NAME_DEFERRED_XATCF_JNDI', 'OracleASjms/MyXATCF');

insert into esb_parameter values('PROP_NAME_DEFERRED_TOPIC_JNDI','OracleASjms/ESBDeferredTopic');

insert into esb_parameter values('PROP_NAME_ERROR_TCF_JNDI', 'OracleASjms/MyTCF');

insert into esb_parameter values('PROP_NAME_ERROR_XATCF_JNDI', 'OracleASjms/MyXATCF');

insert into esb_parameter values('PROP_NAME_ERROR_TOPIC_JNDI', 'OracleASjms/ESBErrorTopic');

insert into esb_parameter values('PROP_NAME_ERROR_RETRY_JNDI', 'OracleASjms/ESBErrorRetryTopic');

insert into esb_parameter values('PROP_NAME_ERROR_RETRY_TCF_JNDI', 'OracleASjms/MyXATCF');

insert into esb_parameter values('PROP_NAME_MONITOR_TCF_JNDI', 'OracleASjms/MyTCF');

insert into esb_parameter values('PROP_NAME_MONITOR_TOPIC_JNDI', 'OracleASjms/ESBMonitorTopic');

insert into esb_parameter values('PROP_NAME_CONTROL_TCF_JNDI', 'OracleASjms/MyXATCF');

insert into esb_parameter values('PROP_NAME_CONTROL_TOPIC_JNDI', 'OracleASjms/ESBControlTopic');

commit;

• Review the inserted values using- select * from esb_parameter

• Restart the SOA container and verify the opmn and J2EE container logs for any errors.

Characteristics and Challenges of SOA

Loosely fashioned interacting software agents

This has been buzz word in IT industry for years that many software technologies and architectures tried to address.Coupling refers to degree of direct knowledge that one software component has about other component to achieve required behavior. In simple words how dependent a component on other component (If you take Java language, here component can be anything starting from a java class to an EJB) to achieve its intended functionality. This is a common phenomenon in designing applications. You can not really design even a single application with out dependency. Only matters here is how you are designing/coding those dependencies, how they are going to impact your application in case of change in behavior of a component and how soon you can incorporate the changes if it gets effected. Given all these you can not avoid coupling completely but we have to minimize it. SOA simply minimizes this dependency by defining services to the extent of granularity in a such a way that service is independent and self contained.Achieving this is really difficult,challenging and comes only with experience.

Easy integration among disparate software components

The effect of 1st discussed activity results in achieving this goal. It all depends on how complete your service defining exercise is. If a service is defined with sufficient granularity and self existence then integration is nothing but pick all what services you want and invoke them.

Reusing software components

This has been there for decades and most of traditional technologies achieved sufficient results. Here what I wanted to say is SOA is also not ignoring this important software designing principle.

Technology neutral

SOA design principles says application components should talk to each other without keeping the technologies in mind on which they have implemented. So technology is no longer barrier here. If you take current generation of SOA technologies/applications, they are heavily leveraging web services to realize this. Code your service in a technology of your choice and warp it up under web service (essentially providing WSDL interface to it).Any other component can call this service with out knowing the technology. Nowadays many tools exists in market to expose legacy applications as WSDL interfaced services.

Rapid application development(RAD)

Re usability always promotes rapid application development.RAD refers to ability how quickly you can build new applications.This can be achieved because we start with defining services and over the time we will have bunch of well defined in-house services where each service is intended to solve a particular business problem. When business is looking for a solution to solve a problem, probably what all you need to do is pick up from on- self services which you have been exercising for the years and compose a new application.

Now lets look at challenges we are facing in defining and realizing SOA benefits.

Identification and granularity of service

There are two approaches available to perform this activity. exercising this activity is very important and challenging too. Probably this might be first activity you start doing once you have made your mind to go with SOA. Business might be running bunch of applications where few of them are legacy and remaining are running on latest technologies. This does not mean that your are going to define and expose all of them as services.

1. Top-down realization
2. Bottom-up realization

Top-down realization:

This involves identifying all eligible business functionality which we are pulling into SOA layer. We take existing application and decompose into more smaller manageable units called services.

Bottom-up realization:

This involves defining all services what you are planning to implement in the first phase. Next step would be composing these smaller units into bigger one. Continue this exercise until you get a feel of sufficient level of service granularity and exposure is achieved.

Performance overhead

This is the cost we will pay. Anyway we are paying this cost because of current state technologies and hardware devices speed. In any typical SOA environment we are utilizing web services to make technology neutral and expose a service over Internet. So web services are being utilized as underline service platform. Calling a web service is always expensive because invoking web service involves wrapping the original message in SOAP envelope which adds complexity and overhead to the underlining middleware infrastructure. Considering lot of improvements in middleware servers and hardware this will be no longer bottle neck.

Service meta data maintenance

This is one of additional responsibilities that comes with SOA. Over the time we will be ending up with maintaining lot of services, many versions of same service and their meta data. Of course this responsibility goes to middleware server.

Governing services

This involves administrative part of your SOA environment. This is more political and taking business decisions rather technology part. This talks about coming up with policies for service life cycle(identifying,defining,deploying,revisioning and retiring services). It also covers who should do what aspects and also covers persons involved in SOA and their privileges. Lot of middleware servers provides applications to cover this part.

SOA all about

There has always been much hype and misconceptions about service oriented architecture(SOA).To be frank there is no unanimous agreement among SOA experts and authors on what and how SOA needs to be defined and boundaries of it.
However let me define it in my own way-SOA is an architecting style to design computer applications to achieve certain design goals.
Now let us see what the goals are.

Design goals

• Loosely fashioned interacting software agents
• Easy integration among disparate software components
• Reusing software components
• Composability
• Technology neutral
• Rapid application development

The basic building block of SOA is service. In simple words service can be any business function designed to do unit of work. For example service can be a pure C- language funtion, C++ method, Pl/SQL procedure or java application with certain characteristics.
A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.

Let us talk about a scenario where business has multiple applications running implemented in various technologies. If he wanted to integrate all of them, then the option he has in his hand is recruit multiple consultants who understands all these technologies which forces business to shell out lot of money.
In contrast, if all these applications have been designed following SOA then all he need is one consultant who knows SOA.
Many more can be added but I want to keep the list short, precise and meaningful.I am sure all the traditional application development approaches like OOPS, distributed components like EJB, DCOM and CORBA must have struggled to achieve same goals but they were successful only in achieving few of goals but not all.That means SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures.
In nut shell-It aims at coming up with a software design in such a way that all business functionality can be implemented in set of reusable technology neutral software units with de-couple fashioned communication among them.

How SOA changes next generation of application development

It impacts many phases of a typical SDLC. We need to revise the way we used to follow to design pre-SOA applications.Some enterprise architects believe that applications developed using SOA gives lot of business agility which helps in reacting to business changes as quickly as possible and incorporate those changes in services and be at the edge of nowadays competition.If a business wants to develop a new application, what all they need to do is choose already built in-house/third-party software services, compose and orchestrate them. This paradigm greatly reduces time to 'develop to deploy' cycle.
SOA Business also has an option of choosing their own technology to implement the services. This allows coding the logic in a technology that best fits.
When started adopting SOA it is going to take more time to realize SOA benefits because initially you need spend time to identify what functionality needs to be defined as a separate service called granularity level.Once business is done with this activity, then next step would be pick those services and build new ad-hoc applications.

How web services and SOA related
There is a myth that both web services and SOA are one and same, in fact both are different but work closely together.Web service talks about exposing a legacy application functionality over the network so that clients can call them to achieve certain business work or unit of work.Web services never talks about software architecting styles. In contrast SOA talks about designing an application with certain characteristics mentioned above. Neither of them replaces another. They simply supplements each other.Web services paves the way to realize and implement SOA and in tern SOA gives best practices and design principles to implement a web service.

SOA Challenges

• Identification and granularity of service
• Performance overhead
• Service meta data maintenance
• Governing services

Given many more advancements in XML standards, process and data standardizations and processing speeds above challenges are no longer be in the list.

In next post we will talk about SOA characteristics and challenges in detail.