Petals Studio 1.0 βeta1

Here we go. The first release of the Petals Studio is planned for tomorrow. In fact, it will be released with the last version of Petals (the platform edition 3.0) and other Petals related products.
Since there are several unknowns and organization issues in the release management, I profit from this post to introduce the tools and the features embedded by the Petals studio. You can see this as the release notes.

Petals’ creation wizards

Obviously, the studio comes with the Petals plug-ins, a set of wizards and tools to create configurations for Petals. What I call configurations is in fact service-units and service assemblies, as described by the JBI specification.
The following pictures illustrate the wizard for the Petals SOAP component.

Filling in the fields from a WSDL file
Specifying the project settings
The SOAP generated (not coded) fields
The CDK fields (here, the CDK 5)
The resulting service-unit project
Right-click the project to package it

This release has creation wizards for all the components officially supported by EBM WebSourcing (or should I say Petals Link now?).
Meaning BPEL, EIP, Jsr181, Pojo, Quartz, SCA, Validation and XSLT for the service engines.
And EJB, File Transfer, FTP, JMS, Mail, SFTP, SOAP and SQL for the binding components.

The Petals service explorer

This is a new feature that will gain more and more importance in the future.
The service explorer is a view that allows the user to see Petals services (which provides a service), no matter where they are.

4 services being shown in the service explorer

The “where they are” is defined by a source.
The default source is the workspace source. It shows all the Petals services which are in the workspace (as projects).
Another source is the external workspace folder, in case where you have several workspaces containing service definitions.
There is also a source to see services from service assemblies. Select a project where you already have zipped service assemblies, and all the service descriptions will retrieved from the contained service-units.

Adding a new source

In the future, there will be a source definition for Petals servers, allowing to see services from a running node.

Opening the service WSDL interface

So, what is the service explorer intended for?
Well… this view was added mainly to simplify developements, in interactions with designers (BPEL, SCA, maybe EIP later) and editors (for service consumers in Petals).
This is highlighted with the next section about the BPEL Designer.

An enhanced BPEL Designer

The BPEL Designer is a project from the Eclipse foundation that allows to model graphically a BPEL process.
This designer is part of the studio, with few extensions we brought for Petals.

A BPEL process shown in the BPEL Designer

The first one is related to validation.
We added a new builder using the validator from the Petals BPEL engine. When errors are found, error markers are added on the file, in the problems view and on the diagram.

Enhanced validation

In the future, additional validation rules will be added to this validator, since some are still missing.
And I hope some efforts will be made about performances, as this feature is very greedy in memory.

A second extension is a simplification in creating invocations toward Petals services.
Using the service explorer, you simply have to drag and drop a service from the explorer on the BPEL diagram to create the partner link (if it does not exist yet), the partner link type, the partner role, and the invoke mark-up. Which is much more simple for people who are not very familliar with BPEL.

If the dropped service comes from a workspace, it will be only referenced. Meaning modifications made to these services will be directly reported in your BPEL process.
If the dropped service comes from an external resource (e.g. a service assembly), then the WSDL is imported in the project.

A third extension, which is not really one, is a set of specific features for Petals BPEL project.
When you create a Petals BPEL project (File > New > Petals > … > Use BPEL), you can either import an existing BPEL or create a new one from a skeleton. Once it’s done, have an export action to package the BPEL, the Petals configuration (jbi.xml) but also all the WSDL interfaces from the partner links.

Creating a Petals BPEL project
Importing an existing BPEL process
All the BPEL imports were copied in the project

Eventually, we fixed some bugs in the designer (that I reported on the project bugzilla).
One being that we can now open BPEL files which are not in the workspace.

The studio itself

There are many more tools and features to present, but I won’t have enough space here.
To make it short, let’s just say the Petals Studio is an RCP application, which looks like a typical Eclipse distribution: same UI, same menus, and so on…
However, it embeds several other tools than the previously mentionned:

  • Java Tooling (JDT)
  • XML, XSD, WSDL, XSL editors
  • Plug-in Development Environement (PDE)
  • SCA Tools
  • m2eclipse (a set of plug-ins for Maven)
  • FindBugs
  • Mylyn (+ the adapter for JIRA)
  • CVS support
  • Subclipse
  • SoapUI
  • Metrics
  • Help center with tutorials

At the title says, it is a first version, in βeta1.
The efforts in the next months will be made on the Petals plug-ins, mainly in extending the service explorer and bringing interactions with Petals servers. And of course, in improving the user experience.

See you…

About this entry