First of all when you face a integration challenge the systems to be integrated are heterogeneous and use different data models (syntactically and semantically). So the data needs to be mapped from requester data to provider data.
1) Direct mapping, this results in n * m mappings (n=#requestors, m=#providers) and is very costly when a new provider or requester is added.
2) CDM, this results in n + m mappings
A CDM gives you:

• Message consistency
• Message maintainability

A CDM is a set of data representing the business entities used in all messages on the Bus. This does not mean that each provider or requestor uses the same set of messages but that the messages are all based on the same types.

Possible implementations for CDM on ESB
Option 1: ESB translates

• The requestor and provider keep their own models
• Only CDM is used on ESB
• Existing services do not have to be changed (especially B2B)
• Only m+ n translations to be implemented and managed
• Easier to reuse mediation logic because it can use the CDM data instead of proprietary message models of the requestors/providers
• Processing overhead? ESB becomes single point of failure?

Option 2: The services translate

• The ESB is not responsible for data mapping
• Transformations run in the request’s/provider’s environment

Option 3: The requestors/providers all use the CDM data

• No transformations needed
• Services can adopt the CDM data model
• Reduces load and management on the ESB
• Mostly unrealistic, hard to reach consensus on model, applications are legacy and cannot be changed

Option 4: Hybrid (combination of option 1 and 2)

• It may lead to complex maintenance and management of the transformations.

Reference

http://www.ibm.com/developerworks/webservices/library/ar-esbpat3/index.html?ca=drs-

Mochten er toevoegingen zijn, dan voel je vrij om een Comment te plaatsen.

Required downloads

• Oracle Weblogic Server 10.3.1
• SOA Suite
• Repository Creation Utility
• JDeveloper Studio

The detailed steps are nicely described here.
The next picture gives a nice overview of the directory structure created.

Step1 -  Create Schemas for Oracle SOA Suite and Oracle BAM (RCU)

• Unzip the files
• Run bin/rcu.bat
• At the Database Connection Details fill in the XE details. If you encounter the next fault you have probably not started the XE database.

• Ignore all warnings

• Click OK
• Select all components

• I ran into the following problem:

And this is about the Processes DB Init parameter that is wrong.
To fix this goto the Database Home page, Sql Editor and execute the following statements:

alter system set open_cursors=500 scope=SPFILE;
If everything is ok you should see the next screen.

• Further ignore errors from portal installation

Step 2 – Install Oracle WebLogic Server and Create the Middleware Home

• Run wls1031_win32.exe
• Choose Middleware Home (example: d:\oracle\middleware)
• Register for security updates, leave empty, Next
• Choose Typical install type
• Choose Weblogic Server Home (example: d:\oracle\middleware\wlserver_10.3)
• The next screens choose Next and the installation progress screen is shown
• After a while you are done with this step

Step 3 – Installing SOA Suite and BAM

• Unzip ofm_soa_generic_11.1.1.1.0_disk1_1of1.zip
• Run setup.exe within Disk1 directory
• When asked for the Java jre use middleware home (d:\oracle\middleware\jdk160_11\jre)
• When the checks are finished the installation locations are asked:
  Use the Middleware Home (selected by default) and use Oracle_SOA1 (also default)
• The following components are installed: BPEL PM, Mediator, Rules, B2B, Human Workflow, BAM

Step 4 – Creating Domain

• Run Configuration Application Server within SOA
• Create a New Domain
• Select all products to be supported
• Enter a Domain name
• Configure JDBC Component Schema

• Select all optional configuration

• Configure the Administration Server, leave unchanged
• Configure Managed Servers, leave unchanged
• Configure Clusters, leave unchanged
• Configure Machines, leave unchanged
• Assign Servers to Machines, leave unchanged
• Target Deployments to Clusters or Servers, leave unchanged
• Target Services to Clusters or Servers, leave unchanged
• Configure JMS File Stores, leave unchanged
• Configure RDBMS Security Store Database, leave unchanged
• Summary
• Create

Step 5 – Install JDeveloper

• Run jdevstudio11111install.exe
• Choose the existing Middleware Home directory
• The rest is Next, Next, …
• After JDeveloper is installed start JDeveloper
• Choose Help -> Check for Updates
• On the Source page choose:

• On the Update page select the extensions to download

• Note: You need an Oracle Web Account.
• After the download is finished you have to restart JDeveloper.

That’s it and now you can start developing SOA components using SCA, but that is an item for another blog item

Capabilities
He emphasizes that we need to understand the capabilities of an ESB. The capabilities are defined from an architectural context and he first explains why an ESB is used (loose coupling, agility, location transparency, services reuse, separate business services from service providers).

The following core capabilitities are described.
Note that not all capabilities need to be present within the ESB, but only use the one the customer needs. Next the capabilities are described in short.

Routing
The ability to channel a request to a particular provider based on routing criteria (types are: deterministic, content-based, policy-based, complex rules-based).

Message Transformation
The ability to convert the structure and the format of incoming request to provider needs.

Message Enhancement
The ability to add or modify the information contained in the message as required by the provider.

Protocol Transformation
The ability to accept one type of protocol and communicate to the provider through a different protocol (i.e. SOAP/JMS -> IIOP, XML/HTTP -> RMI).

Service Mapping
The ability to translate a business service into the corresponding service implementation and provide binding and location information.

Message Processing
The ability to manage state and perform request management by accepting an input request and ensuring delivery back to the client via message synchronization.

Transaction Management
The ability to provide a single unit of work for a business service request by providing a framework for the coordination of multiple resources across multiple disparate services (WS-Coordination, JSR-95). It is difficult to propagate transaction through for example MQ and HTTP. The solution would be to use an aggregate service.

Security
The ability to protect enterprise services from unauthorized access (authentication, authorisation, auditing) through security manager.

The two where you probably have the most discussion about are Process Choreography and Orchestration. Choreography is the ability to manage complex business processes that require the coordination of multiple business services to fulfill a single business request. Whereas orchestration manages multiple implementation services (aggregation of services).

Components
When looking at architecture components of the ESB with its responsibilities/capabilities he defines 4 components.
Mediator: routing, communication, message transformation, message enhancement, protocol transformation, message processing, error handling, service orchestration, transaction management, security.
Service Registry: service mapping.
Rules Engine: rules-based routing, message transformation, message enhancement.
Choreographer: Process choreography and only in case of entry point for the ESB: transaction management, security and message processing.

He then describes the relation between the mediator and choreographer and advises to use the mediator as the entry point and the choreographer underneath it. He advices to use a JMS resource as the entry point for an ESB because of its reliable delivery, monitoring and performance.
The advantages to set it up this way are: performance, scalability, only services that need choreography go through the choreographer.

JSR-208 JBI Specification
This specification of the Java community reached its final version in August 2005. It is an architecture and set of interfaces for providers of integration products to integrate with each other within a JBI container. It is highly flexible in which you can configure just the components you need within your ESB solution (by using Service Components). The way communication is handled with the bus is done with Binding Components.

The advantage is a vendor-indepedant ESB, flexible, light weight solution.

Open Source
There are two open source ESBs

• Mule
  Light weight messaging framework that uses POJOs for implementing the routing, message enhancements etc, so you have to implement a lot.
• ServiceMix
  Open source JBI compliant ESB with some out-of-the-box service- and binding components (like WSIF, HTTP, XSLT, Drools)

Opinion
I would like to give my opinion on the presentation:

• In my opinion choreography is not part of the ESB capabilities, but is done within BPM. Orchestration can be done within ESB and is often seen as choreography. Or should the choreography be part of the ESB? Because you could also say that a choreography is a business service itself and it should be transparent for a service client where and how the business service is implemented.
• The capabilities list can nicely be used to investigate which product is suitable for a customer. It is a nice checklist.

The tool can be downloaded from http://www.hermesjms.com/.
After install copy-paste the configuration within the hermes-config.xml file.

JNDI: Java Naming and Directory Interface
Is a standard extension to the JavaTM platform, providing Java
technology-enabled applications with a unified interface to
multiple naming and directory services in the enterprise (Sun)

EDA: Event Driven Architecture
Software architecture pattern promoting the production,
detection, consumption of, and reaction to events

SOA: Service Oriented Architecture
Is essentially a collection of services. These services
communicate with each other. The communication can involve
either simple data passing or it could involve two or more
services coordinating some activity

WSDL: Web Service Description Language
An XML format for describing network services as a set of
endpoints operating on messages containing either documentoriented
or procedure-oriented information

WSIF: Web Services Invocation Framework
Simple Java API for invoking Web services, no matter how or
where the services are provided

SOAP: Simple Object Access Protocol

JMS: Java Message Service

RPC: Remote Procedure Call
Interprocess communication mechanism

In other words, guide and coach the development teams of each customer in getting familiar with SOA concepts and getting their hands dirty ;o))
The developers themselves are tought BPEL, Web Services, XML and XSD through basic hands on session, workshops in a practical way and then they start designing bpel processes.

What’s very important is this process is that each person needs to do the brainwork, in other words always start from scratch, don’t define a synchronous or asynchronous process, no define an empty process and build it up yourself.

What’s very interesting when guiding and coaching people in becoming a SOA expert, is understanding the way they think and handle functional requests and problems in a SOA Technology. This gives me the opportunity and possibility to focus more on how to better advice and guide people in learning SOA, e.g. BPEL.

The most interesting points to consider and think about when being a teacher in SOA or being a student are the following:

Being a teacher:

• be passionate, patient, non technical, use metaphors and most don’t use abbreviations or buzz words, this ain’t cool ;o)

Basic knowledge before starting BPEL/ESB/OWSM/Mediators … Integration:

• Web services (synchronous versus asynchronous)
• Xml and xsd (how to define, how to work with xml data (xquery, xpath, …)

You need to be able to understand following principles:

• Fault handling
• Compensation handling
• Transaction handling

Following abbreviations mean something to you:

• JCA, JNDI, EDA, SOA, WSDL, WSIF, SOAP, JMS, RPC

How to get started when designing bpel processes:
One of the interesting tricks I’ve learned when guiding a customers’ developer in learning bpel was that he defined an empty bpel process where all needed activities where pseudo-coded.

In other words when you need to define your first bpel process using the use cases defined and described by your analysts, you just design the bpel process using empty activities which describe each needed task/action in your process.

This empty process is deployable and can then be iteratively implemented by the designer when the visual flow is checked upon with the functional developers. => THIS IS A GREAT INSIGHT and WAY OF THINKING and a very visual approach to enabling business processen (thanks to Yves for the tip !!!)

The most interesting part when starting with SOA development is that everyone that’s involved in this process is learning; it’s a learning organization where every person’s knowledge and expertise is augmented!

In this post I’ll mention the 2 approaches I use the most, namely the bpel console itself and Junit.
Visual Debugging Using BPEL Console

Oracle Enterprise Manager 10g BPEL Control reduces the cost and complexity of deploying and managing your business processes. Visually monitor the execution of each BPEL process, drill down into the audit trail and view the details of each conversation, or debug a running flow against its BPEL implementation.

If you’ve deployed a bpel process, you can test the execution in the BPEL Console: http://server:port/ BPELConsole.

In the screen above you can see the deployed bpel processes on the lef-hand side of the screen. To instantiate such a process and create a test instance you can click on the process name and the below screen will be shown:

In this screen you can test the process by defining your own payload, data to be processed by the BPEL process. To define the payload you can use an html-form, the default screen or you can paste the soap-envelop, an xml-based message into the xml-source textarea. To actually test the instance you just need to click on the ‘Send XML-Message’-button. You can also perform stress tests on the bpel processes to verify if performance problems may occure on peak moments.

When you’ve clicked on the button, the process is instantiated and the following screen is shown:

In the tabbed windows you can have a detailed look at the instantiated process, depending on your requirements:

Visual flow:

The activities that failed, threw an exception, are shown with a red background. Each activity in the visual flow holds all needed information for that specific activity. When you double click an activity, the needed data will be shown in an xml-format, because xml is the standard messaging-format for web services.

Audit instance:

Debug instance:

Debug BPEL Processes via JUnit

As soon as a BPEL process is deployed, the BPEL process lives on as being a web service. The webservice can be accessed by its endpoint, or wsdl location.

On the wsdl-tab of your BPEL Process, in the Bpel Console, you can look-up the end-point of the deployed bpel process = web service.

In Jdeveloper you can define a Web Service Proxy and integrate a Junit-test case for this web service proxy:

package test.proxy;

import javax.xml.rpc.ServiceFactory;

public
class BPELTest_ServiceTest extends junit.framework.TestCase{
private
BPELTest_Service myBPELTest_Service;

public
BPELTest_ServiceTest(java.lang.String name){
super(name);
}

protected void setUp() throws Exception {
ServiceFactory factory =
ServiceFactory.newInstance();
myBPELTest_Service =
(test.proxy.BPELTest_Service)factory.loadService(test.proxy.BPELTest_Service.class);
}

protected void tearDown(){
myBPELTest_Service = null;
}

public void testBPELTestPortprocess() throws java.lang.Exception {
test.proxy.BPELTest_PortType port = myBPELTest_Service.getBPELTestPort();
test.proxy.BPELTestProcessRequest payload = null;
BPELTestProcessResponse response = port.process(payload);
assertEquals(“389″, response.toString());
}
}

• Options | Command History | Buffer Size | 500
• Options | Command History | Discard Old Duplicates | True
• Options | Edit Options | QuickEdit Mode | True
• Layout | Screen buffer size | Height | 999
• Layout | Window size | Height | 50

Now we’ve got some room to actually see stuff! QuickEdit mode enables copying from the command prompt by intuitively dragging and right clicking with the mouse. Furthermore, you can paste what’s in the clipboard to the command line by right clicking with nothing selected.

And of course, set the font and colors to taste. I use green-screen style colors (background 0 55 0, foreground 0 255 0) with Lucida Console as pictured above. But if you prefer Comic Sans here, be my guest! When exiting this dialog, you’ll be prompted to save. Make sure you select “Save properties for future windows with same title” so all future command prompts will benefit from these improved settings.

There are also a few helpful keyboard shortcuts that aren’t always widely known:

• Pressing arrow up selects a previous command from your command history; similarly, arrow down selects the next command.
• Pressing F7 pops up your command history list.
• You can drag n’ drop files or folders from an explorer window into a command prompt; this inserts the quoted path as if you had manually pasted it.
• Tab completion is fully supported; type edit *.ini then hit TAB to iterate through all matches. Use SHIFT+TAB to move to the previous match. This works for partial filenames as you would expect, and in all commands.
• Tired of the typical “c:\windows\system32\cmd.exe” window title? Change it using the TITLE command.
• ALT+ENTER takes your command prompt to fullscreen mode and back again.

If you’re really a hard-core cmd.exe junkie (or maybe a UNIX user), you may want to look into the 4nt command shell replacement. It’s a direct descendant of the venerable 4dos shell.