Petals ESB v3.0 is out

Petals ESB v3.0 is finally out (two years after the v2.0 release), there are many changes in this version but here are the main ones :

Petals ESB 3.0, includes a lot of improvements for users, as well as optimisations, and nice new features :
- Dynamic configuration, and hot-deployment of new nodes
- Redesigned webconsole for administration, and deleted statistics monitoring (based on OW2-OpenSUIT)
- SCA support: SCA engine (OW2-FraSCAti), and SCA designer (Eclipse)
- BPEL support: BPEL engine, and BPEL designer (Eclipse), with validation (based on a new BPEL engine!)
- WS Notification and WS-BorkeredNotification support (EDA)
- more and more things…

Integration with new Petals Camelia softwares :
- Petals Studio: Complete Eclipse development environment, for Petals ESB
- Petals Master: SOA Governance (OW2-Dragon)
- Petals View: Business flow monitoring based on Petals EDA feature (based on OW2-OpenSUIT)

We gave this release a name : Camelia.

Fractal Component Inheritance Limitations

Here is the problem I had this afternoon and I said really bad things on Fractal and Spoon (if we had a Fractal Box cf  http://wp.me/pcSx0-3U we will be able to have liters of beer to drink tonight…).

Here is the compilation stack trace :

[WARNING] FractalComponentProcessor >>  No value found for property ‘generatorClass’ in processor org.objectweb.fractal.fraclet.annotation.processor.FractalComponentProcessor

[INFO] ————————————————————————

[ERROR] BUILD ERROR

[INFO] ————————————————————————

[INFO] fail to execute

… which is really helpful…

After spending too much time on searching why, the cause was ’simply’ because my Fractal component (java class) was extending another Fractal component (java class). Not sure that it is a component problem or a component import/requirement one but when one component inherits one other it does not compile at all.

Good to know!

 

Update on november 13:

Sometimes things are strange… It seems that this bug has been fixed some months ago (according to the Fractal bug tracker…) but I have it when I try to extend a component which has already been processed by spoon… ie In the same project all works fine… The problem occurs when I have a fractal based project which depends on another one…

Pro/Cons PEtALS ESB Game

Here is the new game at PEtALS Link: If you say bad things on PEtALS ESB you MUST put money into the box. If you say good things, you can take a candy…
Some says bad things just to in order to buy some beers with the money…

 

The PEtALS Box

and we soon be able to have many beers!

 

Money vs Candies

 

 

PEtALS ESB Live Monitoring with WSDM and GWT

In one of my previous posts (Adding Registry Listener in PEtALS), I spoke about adding a registry listener in PEtALS ESB. In the current article, I want to introduce how I used this feature to implement a live monitoring Web application.

Here are the different modules which are used in this Live Monitoring Tool :

1. PEtALS ESB. The standard behaviour has been customized by adding a registry listener and a routing module (to be detailled below).
2. Monitoring layer. This layer is an independant process which embeds a WS-Notification engine.
3. A WS-notification subscriber. This is the module which will receive the notifications from the monitoring layer.
4. GWT based Web application used to display monitoring data.

PEtALS ESB Extensions

Registry Listener
The role of the registry listener is to register a new monitoring endpoint into the monitoring layer when a new endpoint is available within PEtALS.

Routing Module
Since modules can be added dynamically inside the PEtALS message router, we have created a module which timestamp the messages. Once the message exchange is complete, a message exchange report is sent to the monitoring layer.

Monitoring Layer

The monitoring is in charge of creating monitoring endpoints through a management API. Once a monitoring endpoint is created, it is also exposed as a Web service. This newly created Web service exposes a WS-notification subscribe operation.
Another role of the monitoring layer is to receive raw reports from the PEtALS ESB, to process the report in order to generate a WSDM payload which will be send to subscribers.

WS-Notification subscriber

The subscriber subscribes, receives and stores notifications from the Monitoring layer. That’s all for that module ;o)

GWT Based Web application

The GWT Web application uses comet in order to display live service response time. The data used to display response time is the one received and stored into the database and of course the server part of the Web application have access to this database.

As a result, we have a really nice live Web application (live means that the chart gives real time result and is updated automatically when messages are exchanged within PEtALS Service Bus). Here are some screenshots :

Live Response Time

SLA Violation

Adding Registry Listener in PEtALS

I just added a new feature to petals ESB (to be released quite soon in v3.0) in order to customize the Service Bus endpoint registration and unregistration…

The interface to implement is defined in org.ow2.petals.jbi.messaging.registry.RegistryListener such as :

package org.ow2.petals.jbi.messaging.registry;

import org.ow2.petals.jbi.messaging.endpoint.ServiceEndpoint;

public interface RegistryListener {

void onRegister(ServiceEndpoint endpoint);

void onUnregister(ServiceEndpoint endpoint);

}

Note that for now, the listeners are just called for local endpoints (remote endpoints listeners will be added in a future version). In order to add registry listeners, you just have to implement the RegistryListener interface and to add the listeners to the registry in the Fractal configuration file (JBI-Messaging.fractal).

In order to illustrate how to add a listener in the Fractal configuration file, let’s take an example. All the following lines are added to the JBI-Messagging.fractal configuration file.

1. Add a new component implementation which implements the RegistryListener interface :

<component definition="org.ow2.petals.kernel.registry.listener.wsdm.MonitoringNotifierImpl" name="MonitoringNotifierImpl"/>

2. Bind the new component with required ones (depends on the implementation) :

<binding client="MonitoringNotifierImpl.configuration" server="this.configuration"/>

3. Add the listener to the EndpointRegistry component :

<binding client="EndpointRegistryImpl.listener-wsdmnotif" server="MonitoringNotifierImpl.service"/>

Note that the binding client name MUST start with the “listener-” prefix in order to be added to the list of listeners.

Here we are, on endpoint registration and unregistration, the list of listeners will be called by the endpoint registry component. You can now specialize your endpoints lifecycle. A real use case will come in a future post, so stay tuned.

Dragon SOA Governance v1.0-alpha

OW2-Dragon, the Open Source SOA Governance Platform has been released last week in its 1.0-alpha version.
This version comes with a snapshot version of the OW2-PEtALS Entreprise Service Bus which embeds the Dragon Connector (PEtALS v3.0 to be released by the end of this year with lot of new stuff). This connector allows Dragon to import services hosted on PEtALS runtime and so to govern your SOA based application.

You can get the Dragon webapp here and the PEtALS Standalone Bus here.

Hibernate and HSQL DB are not always your friends

There are some things to know when working with Hibernate mappings and HSQL DB. The most important one is that running something on HSQL does not mean that it will run on another DB engine…

Let’s take the following annotated class :

package org.ow2.petals.registry.core.repository.bo;

import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.Id;

import org.hibernate.annotations.GenericGenerator;

@Entity
public class Property {

    private String id;

    private String key;

    private String value;

    public Property() {
    }

    @Id
    @GeneratedValue(generator = "system-uuid")
    @GenericGenerator(name = "system-uuid", strategy = "uuid")
    public String getId() {
        return this.id;
    }

    public void setId(String id) {
        this.id = id;
    }

    public String getKey() {
        return this.key;
    }

    public void setKey(String key) {
        this.key = key;
    }

    public String getValue() {
        return this.value;
    }

    public void setValue(String value) {
        this.value = value;
    }
}

This will not cause any problem running on HSQL DB but it will not run at all on MySQL for example… The problem is that ‘key’ if a reserved SQL keyword. So renaming ‘key’ fixes this problem.

I just want to know why Hibernate guys do not detect reserved keywords and prefix/postfix them to be SQL compliant. The other question is why Hibernate does not throw an exception but just print a warning when the table can not be created…

Using Nexus as Proxy for corporate Open Source project

The problem when working on an Open Source project which is hosted on a consortium (OW2 in our case) is that the users and developers community which are not working in the same organization than you must be able to compile your project without the help of your Maven2 proxy…

The current article will focus on how to use Sonatype Nexus on the corporate side and how to deliver your independant Open Source project. I will not speak about how to use Nexus as artifact repository here (will probably come in another post).

1. Always define repositories in your project POMs
This is because the community must be able to compile all without any proxy. It is quite important to give IDs to each repository and to keep the ID list in mind…
For example, here is the OW2 Release repository definition :

		<repository>
			<id>ow2.release</id>
			<name>OW2 Repo</name>
			<url>http://maven.ow2.org/maven2</url>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
			<releases>
				<enabled>true</enabled>
			</releases>
		</repository>

2. Give the list of repositories to proxify
2.1 Add the repository to Nexus
Ask your Nexus administrator to add the repositories you want to proxify to Nexus (this is not part of this blog entry, refer to the Nexus guide which is quite complete for that).

2.2 Define the list in your local settings.xml file
In the settings.xml file located under $HOME/.m2/, you must define the list of repository IDs you want to be handled by your Nexus Proxy:

<mirror>
<id>nexus</id>
<name>Nexus Mirror</name>
<url>http://m2proxy:8081/nexus/content/groups/public/</url>
<mirrorOf>central,ow2.release,ow2-plugin.release,ow2-plugin</mirrorOf>
</mirror>

This configuration will say to the Maven engine that all the calls to the 4 repositories (‘central,ow2.release,ow2-plugin.release,ow2-plugin’) will be forwarded to the corporate Nexus proxy running on http://m2proxy:8081.

Following this procedure, you will be able to compile your project with AND without the proxy but the proxy will really optimize your compilation time.

Exposing Fractal Components as Webservices in PEtALS ESB

I just added a new feature to PEtALS ESB kernel in order to expose Fractal Components as Webservices in the PEtALS ESB kernel. As an example, let’s expose some PEtALS runtime information as Web service.

Here are the steps to follow :

1. Create your component interface and add JAXWS annotations

package org.ow2.petals.kernel.ws.api;

import java.util.Date;

import javax.jws.WebMethod;
import javax.jws.WebResult;
import javax.jws.WebService;

@WebService
public interface InformationService {

    /**
     * Get the container version
     *
     * @return
     * @throws PEtALSWebServiceException
     */
    @WebMethod()
    @WebResult(name = "version")
    String getVersion() throws PEtALSWebServiceException;

    /**
     * Get the container type : standalone, platform, quickstart...
     *
     * @return
     * @throws PEtALSWebServiceException
     */
    @WebMethod()
    @WebResult(name = "type")
    String getType() throws PEtALSWebServiceException;

    @WebMethod
    Date getLocalTime() throws PEtALSWebServiceException;

}

2. Implement your Fractal component

package org.ow2.petals.ws;

import java.util.Date;

import org.objectweb.fractal.api.Component;
import org.objectweb.fractal.fraclet.annotation.annotations.FractalComponent;
import org.objectweb.fractal.fraclet.annotation.annotations.Interface;
import org.objectweb.fractal.fraclet.annotation.annotations.LifeCycle;
import org.objectweb.fractal.fraclet.annotation.annotations.Monolog;
import org.objectweb.fractal.fraclet.annotation.annotations.Provides;
import org.objectweb.fractal.fraclet.annotation.annotations.Requires;
import org.objectweb.fractal.fraclet.annotation.annotations.type.LifeCycleType;
import org.objectweb.util.monolog.api.Logger;
import org.ow2.petals.jbi.management.admin.AdminService;
import org.ow2.petals.kernel.ws.api.InformationService;
import org.ow2.petals.kernel.ws.api.PEtALSWebServiceException;
import org.ow2.petals.tools.ws.KernelWebService;
import org.ow2.petals.util.LoggingUtil;

@FractalComponent
@Provides(interfaces = { @Interface(name = "webservice", signature = InformationService.class),
        @Interface(name = "service", signature = KernelWebService.class) })
public class InformationServiceImpl implements KernelWebService, InformationService {

    @Monolog(name = "logger")
    private Logger logger;

    private LoggingUtil log;

    @org.objectweb.fractal.fraclet.annotation.annotations.Service(name = "component")
    private Component component;

    @Requires(name = "adminService", signature = AdminService.class)
    private AdminService adminService;

    @LifeCycle(on = LifeCycleType.START)
    protected void start() {
        this.log = new LoggingUtil(this.logger);
        this.log.debug("Starting...");
    }

    @LifeCycle(on = LifeCycleType.STOP)
    protected void stop() {
        this.log.debug("Stopping...");
    }

    /**
     * {@inheritDoc}
     */
    public Component getComponent() {
        return this.component;
    }

    /**
     * {@inheritDoc}
     */
    public String getType() throws PEtALSWebServiceException {
        return "Platform";
    }

    /**
     * {@inheritDoc}
     */
    public String getVersion() throws PEtALSWebServiceException {
        return this.adminService.getSystemInfo();
    }

    /**
     * {@inheritDoc}
     */
    public Date getLocalTime() throws PEtALSWebServiceException {
        return new Date();
    }

}

In the implementation, the important points are :

1. The @Provides part. The KernelWebService.class interface MUST be named “service”. The ‘business’ interface to be exposed (here InformationService.class MUST be named “webservice”)
2. The Component field is mandatory (used by the webservice manager). Its accessor is mandatory too!
3. The implementation MUST implement KernelWebService and the interface you want to expose

The implementation will not be exposed as Web service if the previous points are not followed.

3. Add the component to the WebServiceManager component with the help of Fractal descriptors

For now, the Fractal composite used to expose Fractal components as Web services is defined in the Tools.fractal descriptor (located under your favorite petals distribution). Here are the important steps :

A. Instanciate the component
<component definition=”org.ow2.petals.ws.InformationServiceImpl” name=”InformationWebServiceImpl”/>

B. Bind component (dependencies to other components)

<binding client=”InformationWebServiceImpl.adminService” server=”this.adminService”/>

C. Say to the Web service Manager to expose this component as Web service

<binding client=”WebServiceManagerImpl.webservice-information” server=”InformationWebServiceImpl.service”/>

Note that in the last point, you MUST always give ‘WebServiceManagerImpl-webservice-SOMETHING’ as client and give the implementation service as server.

Done! Your component is now exposed as Web service and accessible at ‘http://HOST:7600/petals/ws/SERVICE’ where HOST is the host on which you start petals and SERVICE depends on the JAXWS WebService annotation or class name.

PEtALS ESB over the internet

I am finally back from the SOA4All project review @ Brussels where I showed a Distributed Service Bus based on PEtALS ESB deployed over the internet.

The first prototype of the SOA4All Distributed Service Bus has been deployed on 4 nodes (three in France at Toulouse, Antibes, Paris and one in Austria at Innsbruck). Each node was providing SOAP access to all the platform services bound to the bus (most of them were SOAP based Web services). It is good to note that response time was quite good between service consumers and providers (some optimizations to be performed to avoid remote checking before sending messages).

Note 1 : It is true that to allow the nodes communication, we opened all the required ports (actually 4 for SOAP/HTTP, JMX and raw TCP communication) but next step will be probably to just use the default HTTP port and this is a real challenge…

Note 2 : The new distributed technical registry (self developed) used to store service endpoints was used in the prototype. Good job