Hello world!

In: Uncategorized

13 Jan 2010

Bienvenue dans Petals Link Blog. Ceci est votre premier article. Modifiez-le ou effacez-le, puis lancez-vous !

Rien de technique dans cet article, juste un grand merci à Gaël et Bertrand pour la session Karting d ’entreprise d ’hier après midi

Publié dans PetalsLink Tagged: ebmwebsourcing, PEtALS, petalslink

Implementation types

Let’s first introduce the different ways to register a server in WTP server tools.
Basically, there are two ways:

  • Hard-coded: you use WTP extensions-points and API. It implies Java programming.
  • XML: you define the server properties as a XML file that you register through an extension point. The GUI and properties will be generated and handled from this XML file.

For the XML approach, you can check these two links:

It is clearly the most simple way to register a server definition into Eclipse. OW2 JOnAS used it for its version 4.x.
The hard-coded approach is reserved for full-control and/or specific behaviors.

The XML approach was once used to define Petals servers.
About three years ago, Cap Gemini people created Eclipse plug-ins for Petals. There was a Petals server definition in it.
When I had to work on the Petals support into Eclipse, my first reflex was to start on this basis and update the serverdef file. Unfortunately, it revealed some weakenesses.

This brings us to talk about Petals specifics and somehow limitations to determine what is the best approach.

Petals’ needs

Petals contributions

Petals implements the JBI specification.
A Petals server accepts many kinds of contributions. These contributions are listed by the specifications and they must have a given structure. For some of them, moving from the workspace structure to the deployment structure can be a complex operation. For Petals components, this operation is generally made by Maven. For Petals service-units, this operation is generally made by the Eclipse plug-ins.

Therefore, deploying projects (WTP server tools would say modules) to Petals relies on and includes different backgrounds.
Integrating this packaging into a XML approach is not very convenient, unless you use ANT. Using ANT would require not to depend too deeply on Eclipse mechanisms.

Communications with Petals

There are two ways to communicate with Petals.
The first one relies on JMX. The second one relies on web services, that act as a proxy to JMX.

Why add web services? Well, Petals is a distributed ESB. We have users and clients who have several deployed nodes. And it appeared JMX was sometimes a problem to configure firewalls in systems. From this point of view, web services were more convenient.

Local and remote servers

One last aspect is that we want to be able to define local and remote servers.
Debugging and deployment things will obviously rely on local instances. But registry queries and diagnostic will be available on any server.
This is why our approach has to deal with both kind of Petals servers.

The .locked file

When Petals is running, or was improperly stopped, the install directory contains a “.locked” file.
When this file exists, no instance of Petals can be started.

If you use the XML approach, and that this file exists, the start server command fails, showing an exception with no cause explained.
To handle these files, a hard-coded approach is required, at least to implement the start command.


Clearly, we have important needs with respect to controlling interactions with Petals servers.
Besides, the .locked mechanism is very difficult to handle with a XML approach.

This is why I will try my luck with the hard-coded approach.


I’m starting a series of articles to explain the creation of tools to define and interact with Petals servers through the Eclipse server view.
This is the first step to new tools around Petals: obviously, Petals servers will be used to debug Petals components and Java services, query the Petals technical regitry. But Petals servers will also be the basis for topology related tools: architecture modeling, definition and management of Petals projects, introspection and diagnostic of Petals servers and topologies.

This is definitely an important step that must be done carefully and correctly.
Without being too arrogant, I think I have quite a good experience in Eclipse. I mean, I have programmatically worked with SWT, EMF, GEF, GMF, JDT (the Java tooling), the Common Framework Navigator, WTP SSE (source editing), dynamic registrations of plug-ins extensions, plus the usual Eclipse mechanisms, e.g. builders, natures… And despite this, I must confess I have never worked with something so much complex than WTP server tools. Their concepts can be confusing, the existing plug-ins are not that simple. And applying it to YOUR server is far from being trivial. Generally, it doesn’t take me so long to understand an Eclipse API or mechanism. I guess the language may also have a responsability in this (I was used to consider runtime and server as – almost – equivalent words).

This is why I want to write these articles.
At least, it will help me to explain to Petals developers why I made some choices.
And mayit will help others to implement their own server support into Eclipse.

To end this first article, here are few but useful links and readings:

Une entrée en Français pour une fois…
Une section dans la nouvelle newsletter de Petals est dédiée au projet sur lequel je travaille depuis plusieurs mois : SOA4All.

La principale contribution de Petals Link concerne évidemment l’infrastructure de service au cœur de l’architecture. Basée sur Petals ESB, elle doit concilier des exigences parfois contradictoires : très haute distribution des services, qualité de service, monitoring mais également facilité d’utilisation et de déploiement ainsi qu’une grande modularité.

La dernière revue s’est déroulée en octobre dernier dans les locaux de la Commission européenne. Cette revue de mi-projet (Mois 18) était spécifiquement dédiée à la démonstration de prototypes visant à valider les principaux concepts techniques de la plate-forme.

Nous avons fait la démonstration avec succès du module « Federated Distributed Service Bus » que nous étudions et développons conjointement avec l’INRIA (Institut National de Recherche en Informatique et Automatique).

Ce composant joue le rôle essentiel d’infrastructure de service très largement distribuée. Basé sur une architecture de type fédérée, il permet de rassembler des groupes de services utilisant des middlewares hétérogènes et obéissant à des règles de gestions propres.

L ’article complet est disponible ici.

Publié dans PEtALS, SOA4All Tagged: ebmwebsourcing, Java, newsletter, PEtALS, petalslink, SOA, SOA4All, WebService

Petals Master v1.0, the first official version of the Petals governance tool has been finally released on OW2 today. Here is the quick release note from the Team :

Petals Master 1.0, includes a lot of improvements for users, as well as optimisations, and nice new features :

  • Categorize your services, endpoints and enterprises with UDDI based categories or add your own categorization value sets
  • Community capabilities : Share ratings, tags and comments on registered services and endpoints with all users
  • Share additional information about services by uploading related documents. Supported related document types are: DOC, PDF, XML, HTML, XLS, PPT, TXT, RTF, ODT, ODS, ODP
  • Identify your Enterprises with UDDI based identification system (Thomas Register, Dun and Bradstreet (DUNS)), or add your own identification system)
  • Search registered entities with a UDDI V2/V3 compliant Inquiry WS API
  • Do all what you can do with Petals Master UI with the Petals Master specific WS API
  • SLA Management is disabled, but will be back soon, with lots of improvements: SLA enforcement, service contract creation and management based on information collected on execution environments
  • Integration with new Petals ESB v3.0 Camelia edition: Govern services and endpoints deployed in Petals ESB by just providing Petals ESB specific WS address and click « synchronize ». That’s all !

As mentioned, this tool is integrated with Petals ESB v3.x, so now you can govern services from your Entreprise Service Bus.
There are also several new tools which are connected to Petals ESB, I think that more news will come soon…

Last week, we’ve released a new version of PetalsESB. This version come with a lot of new features as standard :

  • Dynamic topology, using a master – slave policy
  • Distributed registry, using a master – slave policy
  • WS Notification and WS-BorkeredNotification support (EDA)
  • many binding components (SOAP, FTP, Filetransfer, SFTP, Mail, …)
  • many service engines (EIP, SCA, BPEL, POJO, …)
  • a new webconsole based on the OpenSuit presentation framework
  • WSDL validation at deploy time thanks to EasyWSDL
  • Integration with PetalsMaster (SOA Governance) & PetalsView (business flow monitoring)
  • more and more things…

Download PetalsESB 3.0.1 :

PetalsESB logo

Posted in Announces, Petals ESB Tagged: Petals ESB

Merci à ce blog, il faut simplement désactiver l’antivirus pour se connecter au switch dell.

Just a quick tip to say that you can define the logger level for each JBI component you deploy into Petals ESB by setting things in the conf/loggers.properties of your favorite Petals distribution. If the component name is petals-bc-restproxy (the component I am currently developping), just define the log level like this :

logger.Petals.Container.Components.petals-bc-restproxy.level DEBUG
logger.Petals.Container.Components.petals-bc-restprox.handler.0 petalsConsole
logger.Petals.Container.Components.petals-bc-restprox.handler.1 petalsFile

The only DEBUG logs which will be displayed will be the petals-bc-restproxy ones.
Good to remember!


Here is a small snippet that may avoid some waste of time.
I spent almost 3 hours to find a solution. This is why I share it here.

Let’s first introduce what I wanted to do.

I have a welcome page, which extends IntroPart and is able to launch wizards on user actions. I coded it manually. It does not rely on the CustomizableIntroPart class. What I wanted to do was to close it when a wizard launched from this page had completed. This behavior is visible in the default welcome page of Eclipse. When you click “Go to workbench”, the welcome page is closed and a perspective is shown.

The first idea was to programmatically close the view that embeds the welcome page after the wizard has executed (with IWorkbenchPage#hideView( String )).
I did try, and it was unsuccessful. The workbench shows an empty widget, and no perspective is shown.

I then tried to close the page in IntroPart#setStandBy( boolean ). Unsuccessfully.
I then tried to reuse what is implemented in the org.eclipse.ui.intro plug-in, in the method IntroURL#switchToLaunchBar().
Therefore, one solution I tried to close the Eclipse welcome page is:

IntroURL url = new IntroURLParser( "http://org.eclipse.ui.intro/" + IntroURL.SWITCH_TO_LAUNCH_BAR );

Still unsuccessful.

In fact, no matter what you use, if the welcome page tries to close itself, it will fail.
The solution was to make my welcome page implement IPartListener and register itself on its page.
When the page is deactivated (when it losts the focus), the welcome page is closed, using:

PlatformUI.getWorkbench().getIntroManager().closeIntro( part );

That was that simple!




Latest Tweets

Page 20 of 33« First...10181920212230...Last »