HermesJMS is a great (free) tool to view JMS destinations.
I was struggeling to connect it to Oracle SOA Suite 10.1.3 but here is the configuration part that did the trick.

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


The Role of the Enterprise Service Bus

This was a presentation given by Mark Richards and describes the role of an ESB and particularly what it provides. It is an old presentation (23 oct 2006) but still very true, in the fact that there are still a lot of different definitions of an ESB within the world.
This is a short recap of this presentation.

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.

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.

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).

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)

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.


BEA WebLogic: The NodeManager

The NodeManager is an important part of a weblogic server and this blog will give a short introduction and more detailed information on system administration can be found here.

Node Manager is a WebLogic Server utility that enables you to start, shut down, restart, and monitor remote WebLogic Server instances. To enable these capabilities, you run an instance of Node Manager on each physical machine in your domain.
WebLogic Server provides two versions of Node Manager, Java-based and script-based, with similar functionality. However, each version has different configuration and security considerations.
  • Java-based Node Manager runs within a Java Virtual Machine (JVM) process (start as a service). BEA provides native Node Manager libraries for Windows, Solaris, HP UX, Linux on Intel, Linux on Z-Series, and AIX operating systems.
  • A script based version is provideded for UNIX and Linux systems. This script is based on UNIX shell scripts, but uses SSH for increased security. SSH uses user-id based security.
Access Node Manager
The node manager can be accessed from:
  • Administration Server (Console or JMX utilities that you write)
  • WLST commands and scripts

What can you do with the Node Manager?

  • Start, Stop, Restart admin server
  • Start, shut down, suspend and restart Managed Servers
  • Monitor servers and view log files
    Node Manager creates a log file for the Node Manager process and a log file of server output for each server instance it controls.


Gartner: About Oracle's Fusion Middleware

See here

The bottom line:
"The full integration of the BEA products into Oracle's middleware will not come out until somewhere in 2009"

Gartner analysts recommend waiting for Oracle Fusion Middleware (OFM) 11g, due in the next six to 12 months.


Bea WebLogic Server JMS - Part 1 Basic JMS

This is the first blog in a series about WebLogic JMS (WLS 10.0). Full description can be found here.

The Java Message Service (JMS) is a standard API for accessing enterprise messaging systems.

WebLogic Server is compliant with the Java Platform, Enterprise Edition (Java EE) Version 5.0 specification and fully compliant with the JMS 1.1 Specification and can be used in production.

The major components of the WebLogic JMS are:
  • JMS servers that hosts a set of modules and any associated persistent storage that reside on a WebLogic Server instance.
  • JMS modules contains configuration resources conform the weblogic-jmsmd.xsd schema.
  • JNDI (Java Naming and Directory Interface), which provides a resource lookup facility. JMS resources such as connection factories and destinations are configured with a JNDI name.
  • WebLogic persistent storage (file store or JDBC-accessible) for storing persistent message data.
Messaging Models
JMS supports two messaging models: point-to-point (PTP) and publish/subscribe (pub/sub). Multiple queue senders and queue receivers can be associated with a single queue, but an individual message can be delivered to only one queue receiver.
Unlike with the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to receive the same message. JMS retains the message until all topic subscribers have received it.

Message Persistence
Messages can be specified as persistent or non-persistent.
  • A persistent message is guaranteed to be delivered once-and-only-once. The message cannot be lost due to a JMS provider failure and it must not be delivered twice. It is not considered sent until it has been safely written to a file or database.
  • Non-persistent messages are not stored. They are guaranteed to be delivered at-most-once, unless there is a JMS provider failure, in which case messages may be lost, and must not be delivered twice. If a connection is closed or recovered, all non-persistent messages that have not yet been acknowledged will be redelivered. Once a non-persistent message is acknowledged, it will not be redelivered.

WebLogic JMS extensions
In addition to fully supporting XA transactions, WebLogic JMS also features high availability through its clustering and service migration features, while also providing seamless interoperability with other versions of WebLogic Server and third-party messaging providers.
See weblogic.jms.extensions.

To create a JMS applications, use the javax.jms API. For a complete description of all JMS classes, see the javax.jms or weblogic.jms.extensions Javadoc.

A ConnectionFactory encapsulates connection configuration information, and enables JMS applications to create a Connection. You can use the preconfigured default connection factories provided by WebLogic JMS, or you can configure one or more connection factories to create connections with predefined attributes that suit your application. The default connection factories are: weblogic.jms.ConnectionFactory and weblogic.jms.XAConnectionFactory.
An XA factory is required for JMS applications to use JTA user-transactions, but is not required for transacted sessions. Another distinction when using the default connection factories is that you have no control over targeting the WebLogic Server instances where the connection factory may be deployed. However, you can disable the default connection factories on a per-server basis. A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously.

A Connection represents an open communication channel between an application and the messaging system, and is used to create a Session for producing and consuming messages.

A Session object defines a serial order for the messages produced and consumed, and can create multiple message producers and message consumers. The same thread can be used for producing and consuming messages. If an application wants to have a separate thread for producing and consuming messages, the application should create a separate session for each function. WebLogic JMS does not support having both types of MessageConsumer (QueueConsumer and TopicSubscriber) for a single session.

A Destination object can be either a queue or topic, encapsulating the address syntax for a specific provider. Administrators can also configure a distributed destination, which is a single set of destinations (queues or topics) that are accessible as a single, logical destination to a client. The members of the set are typically distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use a distributed destination are more highly available than applications that use standalone destinations because WebLogic JMS provides load balancing and failover for the members of a distributed destination in a cluster.

Producer and Consumer
A MessageProducer sends messages to a queue or topic. A MessageConsumer receives messages from a queue or topic.

A Message encapsulates the information exchanged by applications and it has header- and property fields and a body. Some header fields:

Specifies one of the following: a WebLogic JMSMessageID, an application-specific string, or a byte[] array. The JMSCorrelationID is used to correlate messages and is set directly on the message by the application before send().
There are two common applications for this field.
The first application is to link messages by setting up a request/response scheme, as follows:
  1. When an application sends a message, it stores the JMSMessageID value assigned to it.
  2. When an application receives the message, it copies the JMSMessageID into the JMSCorrelationID field of a response message that it sends back to the sending application.
The second application is to use the JMSCorrelationID field to carry any String you choose, enabling a series of messages to be linked with some application-determined value.

Specifies PERSISTENT or NON_PERSISTENT messaging. This field is set on the producer or as parameter sent by the application before send().
Contains a string value that uniquely identifies each message sent by a JMS Provider.This field is set internally by send().
Specifies a queue or topic to which reply messages should be sent. This field is set directly on the message by the application before send().

A message body contains the content being delivered from producer to consumer and can be one of the following types:
Bytes, Map (name/value pairs), Object (serializable), Stream (same as Bytes only primitive types allowed), Text, XML (Weblogic extension and facilitates message filtering which is more complex when done on a test message that happens to contain XML data)


XA Transactions

I came across a good article about what XA transactions here.

Common Data Model on ESB

This item is about a CDM a.k.a CMM (Common Message Model) on the Bus, why is it wise and how can it be done.

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.



Message Oriented Middleware

With Message Oriented Middleware you can have several different communication mechanisms. The most common are Queues and Publish-Subscribe. Queues are mostly point-to-point, so therefore not loosely coupled, location-based addressing. What does Pub-Sub give you?
  • Decoupling of Producers and Consumers
  • Producers and consumers do not know each other
  • Flexible number of producers and consumers

Addressing Models

With pub-sub there are a number of addressing models.
  • Channel or Topic based
  • Subject based
  • Content based
  • Concept based (not further described here, but tries to describe interest on a high level)

Topic based addressing

This is simple but less powerfull. Example JMS topics.You basically get every message that is published on a particular topic. However you have the possibility to set a filter when a subscription is taken that will filter the messages on attributes in the header of the JMS message.
This is supported by BEA AquaLogic Service Bus.

Subject based addressing

It avoids the use of of physical network addresses. Messages are labeled with subject and consumers can subscribe on subjects. Producers do not need to know how messages are consumed and consumers do not need to know the source. There must be agreement on subject names and subjects can be added dynamically.The names consist of a hierarchy of elements: element.subelement.subsubelement.
Consumers can use wildcards: BOOK.* matches BOOK.TITLE and BOOK.> matches BOOK.TITLE.DESCR.
The disadvantage is that subject hierarchies can not be changed easily.

This type of addressing is supported Tibco's Rendezvous.

Content based addressing

A content based filter is a predicate on the content of the messages.


The JMS publish and subscribe is a combination of Topics and expressions on envelope's attributes. Factories, Destinations are identified via JNDI.
The message header is used for addressing and extra message properties, which are name value pairs, can be set. A selector (SQL-like expressions) can be used by consumer to filter messages based on the header's properties.


Oracle Fusion: OWSM

Ik moest toch naar de Oracle Fusion stack kijken, dus ik dacht laat ik maar direct een samenvatting maken van de verschillende producten.
Het eerste is de Oracle Web Service Manager.

Wat biedt het?
• Centraal configuratie van policies m.b.t. web services (LDAP directory of Oracle’s Access Manager(OAM))
• Enforce deze policies runtime
• Monitoren van runtime security evenst en SLAs in grafieken

Bij web services security spelen de volgende zaken een rol:
• Authenticatie – Is degene wel wie die zegt dat hij is, gebaseerd op credentials (user name, paswoord)
• Authorisatie – Een gebruiker toegang geven tot bepaalde resources gebaseerd op de gebruiker entitlements (property/karakterestiek van een gebruiker).
• Confidentiality – Zorgen dat de data niet gelezen kan worden, dmv encryptie. Ook hoort hierbij de identiteit van de sturende en ontvangende partij(privacy).
• Integrity – Zorgen dat een bericht niet kan worden aangepast

OWSM maakt gebruik van Public Key Infrastructure (PKI) omgevingen (ga ik hier verder niet op in).
De security requirements worden op transport nivo ondersteund (SSL) en op applicatie nivo (maken gebruik van XML frameworks, bijv WS-Security).
SSL zorgt voor authenticatie, confidentiality, integrity, secure key exchange tussen client en server. SSL zorgt voor point-to-point security maar geen end-to-end.

Wat gebeurt er op applicatie nivo?
Confidentiality wordt bereikt door gebruik van XML Encryption (= XML standaard).
Data integriteit en authenticatie maken gebruik van XML Signature (=XML standaard).
WS-Security definieerd hoe XML Signature en XML Encryption aan SOAP headers worden toegevoegd en heeft profiles voor 5 security tokens: Username (met password digest), X.509 certificaat, Kerberos ticket, Security Assertion Markup Language (SAML)asserties en REL document.

OWSM gebruikt 3 main operaties voor configuratie:
1) Define policies, bijv Log Incoming Message, Extract Credentials, Encrypt, Sign).
2) Enforce Policy Enforcement Points (PEPs) voor management policies.
3) Monitor voor tracking (in charts) runtime security en mgt events opgevangen door OWSM

OWSM gebruikt hiervoor de pipeline metafoor. Je definieerd dus wat er met request gebeurt en voor de response. De OWSM Gateway (of Agent) onderschept een web service request, voert de stappen uit van de request pipeline en forward (als alles goed is gegaan) de request naar de service request provider. Bij de response gebeurt iets soortgelijks. Het is ook mogelijk om custom steps, die niet out-of-the-box worden geleverd, te maken.

De gateway en/of Agents (ook bekend als PEPs) gebruiken de Policy Manager voor nieuwe policies (pull). Je hebt client en server Agents, die gebruikt worden bij respectievelijk een service client en service provider. Een gateway wordt meestal gedeployed aan de kant van de service provider in de zogenaamde DMZ (demilitarized zone).

Verschillende setups:
• Protecting web services dmv gateway

• Een webservice client en web service provider gebruiken verschillende credentials (client gebruikt username/password, provider SAML assertion).

• End-to-end security met Oracle Access Manager (OAM)

1 – Browser accesses application
2 – OAM agent (WebGate) vraagd om credentials, WebGate authenticeerd bij OAM en OAM genereerd sessie token
3 – De applicatie haalt cookie uit de sessie en zet dit in SOAP header en maakt de SOAP call
4 – Credentials in de SOAP header worden vervangen door SAML asserties en maakt forwards de SOAP call
5 – SAML assertie wordt gevalideerd en de web service call wordt gemaakt


SOA Component

Bij het opzetten van een architectuur wordt altijd gepraat over componenten, modules, business services. Maar wat betekenen die termen nu eigenlijk in een SOA omgeving. Wat is een component dan precies? Moet een component een business service leveren? Of alleen een service die vervolgens in een business service gebruikt kan worden om de service te implementeren.
Het is natuurlijk goed om te weten hoe dit binnen jouw project gedefinieerd is. Dat maakt het praten en ontwikkelen van een SOA een stuk gemakkelijker.

Ik kwam op de IBM Developers site dit artikel tegen.

Agile en SOA een goede match ?

Ik ben voor het eerst een paar jaar geleden in contact gekomen met Agile development. Ik wil hier niet verder ingaan op wat Agile inhoudt, maar ik heb me wel beziggehouden of Agile ook werkt in een SOA oplossing.
Vandaag stuitte ik op blog van Martin Fowler dat wel de moeite waard is om te bekijken. Op InfoQ een reactie hierop.
Een interessante passage was wel: "As a result, one of the fundamental aspects of a SOA implementation should be the ability to evolve services contracts as the overall requirements to implementation change".


Oracle DBAdapter

Deze blog laat zien hoe je eenvoudig een Oracle DB Adapter ge-exposed als een web service kunt maken met BEA Workspace Studio. Dit maakt gebruik van Apache Beehive.

* Maak een new Project aan en kies in de project wizard voor een Web Service Project. Klik Next.

* Geef als project naam, bijv DbAdapter, en klik Next

* In dit scherm kun je zogenaamde Facets aangeven. In dit geval de Annotation Processors die gebruikt gaan worden. We gebruiken de JAX-WS annotaties en de extended Beehive annotaties. Accepteer hier de Defaults.
en klik Next.

* Accepteer in dit scherm de defaults en klik Next.

* Het volgende scherm gaat over de Beehive Controls. Je kunt hier aangeven of je wilt verwijzen naar een Beehive library (eerste optie) of de JARs wilt copieren naar je WEB-INF/lib directory. Je kiest voor het eeste geval als de library vaker gebruikt wordt (of gaat worden), je kiest voor de tweede optie als je per applicatie wilt kunnen aangeven welke jars je precies wilt gebruiken.
Let op!
Als je voor de eerste (default) optie kiest, moet je er bij het deployen (en runnen) rekening mee houden dat de library wel gedeployed is in je weblogic server. Anders kan de webservice niet gedeployed worden. Dit is de fout die in een eerdere blog beschreven is.

Accepteer de default en klik Next.

* Bij Weblogic Controls, accepteer default en klik Next.
* Bij WebLogic Integrated Commons Logging accepteer default en klik Finish.

* Maak een nieuw services Package aan voor de classes

* Klik met rechtermuisknop op services en kies New > JDBC Control
* Geef als naam op DbAdapter en klik Next
* In het volgende scherm kies je de database source. Hier vul je de JNDI van de data source in.

En klik Finish.

* Nu wordt er direct al wat code voor je gemaakt:

* Nu kun je dmv annotaties van Beehive Sql queries uitvoeren op de data source waarnaar je zojuist gerefereerd hebt met z'n JNDI naam.

* Nu gaan we deze adapter exposen als een web service. Ga op services package staan, rechtermuisknop en kies New > WebLogic Web Service. Geef de service als naam DbAdapterService en klik Finish.

* Weer is er alvast wat code ingevuld. We gaan nu de JAXWS annotaties gebruiken om de DbAdapter te exposen als een WebService.

Voordat we gaan deployen vanuit WorkSpace Studio, gaan we eerst een koppeling maken met de server.
* Ga op DbAdapter project staan, rechtermuisknop en kies New > Server
* Vul hostname in (in ons geval localhost)
* Kies juiste BEA WebLogic Server versie (in ons geval 10.0), klik Next.
* Browse naar het juiste Domain en klik Next.
* Klik op je DbAdapter en klik Add, en daarna klik Finish
Bij de servers is nu je server toegevoegd met je project:

Nu kunnen we deployen.
* Klik rechtermuisknop op server en kies Publish.

Als je nu vervolgens inlogt op de admin server console van de server waarop je de service hebt gepublished zul je het volgende zien bij Deployments:

Nu kunnen we de service testen.
* Klik _workshop_auto_generated_ear_ open (+ tekentje)
* Klik bij Web Services op services.DbAdapterService
* Kies Testing tab
* Klik op (+) bij services.DbAdapterService
* Klik op Test Client
Nu krijg je een mooi gegenereerd test scherm voor je kiezen, vul wat waarden in en klik op Insert.

Kijk vervolgens in de database of de data is toegevoegd.

Deploy WAR op WebLogic

BEA WorkSpace Studio: 1.1
WebLogic Server: 10.0

Tijdens het deployen van een WAR file die andere JARs gebruikt stuitte ik op foutmeldingen. Classes konden niet geinstantieerd worden.
Nu had ik dit op de volgende manier gedaan:
1) Binnen WorkSpace studio een WebApp gemaakt
2) Ga op het project staan, rechtermuisknoop > Export > Web > WAR File
3) Kies een Destination waar de WAR file naartoe wordt geschreven, druk Finish

4) Open AdminServer console van de web logic server waarop je de app wilt deployen
5) Deploy de applicatie onder Deployments en ik krijg de volgende foutmelding

Echter op een andere PC deed ik de deploy anders en vanuit Workspace Studio:
1) Maak een server aan die verwijst naar de Server waarop je wilt deployen
2) Voeg jouw project toe aan de server
3) Klik op de server waarop je wilt deployen en rechtermuisknop Publish
4) Nu zul je zien bij de Deployments in de WebServer dat ook de afhankelijke libraries zijn gedeployed.
5) Start vervolgens de Web app in de WebLogic Server


Oracle Fusion na aquisitie BEA

Nadat Oracle BEA heeft overgenomen, wat gebeurt er met o.a. JDeveloper, Workshop Studio, BEA WLS, BEA ALSB. Hoe worden de BEA producten geintegreerd in Oracle's Fusion Middleware? Een korte samenvatting.

* JDeveloper blijft de main development IDE. BEA Workshop wordt als een eclipse add-on toegevoegd aan JDeveloper (tegen geen extra kosten).

* BEA Tuxedo wordt de strategische offering voor het managen van transaction processing systemen die draaien op C/C++, en COBOL.

* BEA WebLogic Server wordt de Java application server (BEA JRockit wordt Java Virtual Machine).

* Merge van Oracle ESB product met BEA ALSB: Oracle Service Bus. Oracle’s BPEL Process Manager blijft het platform voor process orkestratie.

* Business Process Automation (BPA) Designer tool zal herenigd worden met BEA AquaLogic BPM Designer. De verenigde offering zal de bestaande BPM Suite vervangen.

Oracle Fusion Middleware


BEA Workspace Studio

Nadat ik de cursus ALSB 2.5 had gevolgd, met overigens een ALSB 3.0 installatie, kwam ik erachter dat er ook nog zoiets was als BEA Workspace Studio.
Ik had namelijk alles netjes via de HTTP SB console geconfigureerd.
Je kunt de configuratie echter heel gemakkelijk exporteren en weer importeren in de Eclipse omgeving.

1) Login op de ALSB Console (bv: http://localhost:7001/sbconsole)
2) Ga naar "System Administration"
3) Daarna "Export Resources", selecteer het project dat je wilt exporteren en klik "Export"

Nu is het configuratie project ge-exporteerd.

Ga vervolgens naar BEA Workspace Studio.
1) Ga naar de Project Explorer
2) Rechtermuis knop, New > ALSB Configuration Project (en vul gegevens in)
3) Ga op het Configuration Project staan, rechtermuisknop Import > Configuration Jar
4) Browse naar de ge-exporteerd jar file
En klaar !

Je hebt nu een designer voor bijvoorbeeld de message flow, bijvoorbeeld: