During the last week we had a “great disturbance in the force”. Oracle detailed its agenda for Sun products and promised to “maintain” the Open-ESB community and Glassfish ESB.

As explained in our last blog, we had a bad feeling for our community and were not very optimistic. In order to understand what "maintain" means exactly, we had a look on the Oxford dictionary where the word “Maintain” is explained as follow:

1. cause or enable (a condition or state of affairs) to continue.

1. keep (a building, machine, etc.) in good condition by checking or repairing it regularly.

2. provide with necessities for life or existence

Everyone could understand the message that Oracle will provide a level of resource or budget enough to continue and keep Open/Glassfish ESB in good context. Of course, we did not expect from Oracle millions dollars of investment for what they named : a non strategic product.

Alas, we did not to wait more than one week to spy out Oracle's intents. This week, we got news about Open/Glassfish ESB teams from very reliable US and EU sources involved in the project. We think that it is our duty to inform the community and communicate the news even it is obvious that Oracle or Oracle groupies will refute them.

The sources informed us that development team working on Open-ESB had been dissolved. One of our source told us: “the development team has been massacred just sustaining remains”. Another one said: "new developments are dead, Don't reckon on new enhancements. Version 2.3 or even Fuji will never be issued. Just few people remains to provide a very light support". In fact, Last Monday 1st February for the first time, the Forum Nabble : http://n2.nabble.com/OpenESB-Users-f794670.html did not receive any answer, and since the last week, wiki's activity decreases dramatically !!! Other contacts described the same situation and now, we have no more doubt about what happen this week.

First, let take time to think of all the girls and guys that worked on Open ESB project and that will never see the outcome of their hard work. Dozens of names cross our minds and Pymma wants to thank them for what they did. (Please let us know if you come in London and have a beer together)

If you are lucky enough to develop with J-caps or to subscribe to a Glassfish ESB support don't worry about this new context. With a contract you will get a support and will be able to work for many years.

For the other cases, what can be the response of the community ?

First responses emerge from the chaos. Former SUN's employees propose professional support (http://forgerock.com/) on open-source product likes Open-SSO, Open-IDM. Open ESB in included in their portfolio but without control on Netbeans and Glassfish evolution, it appears difficult to propose an alternative support.

We learn that the project Wonderland has been cancel as well. Most probably, one of the next target will be MySQL development teams. Fortunately, forks will be easier to create and maintain than for Open-ESB project.

We hope that other solutions will emerge from this new context. Of course, Pymma is ready to participate to any credible proposition. Let's take advantage of the forums to encourage and promote a light and powerful integration system.

To conclude this sad post, once again, we would like to thanks Sun guys and girls that gave us faith in Open and Standard solutions.

Pymma

Back to the Middle age ?

Long time I did not write something on this blog. It is a real pleasure to write again in this blog
As you certainly did last Wednesday, I watched the web-cast about SUN/Oracle strategy. It was a very tired by the marketing show, and fortunately, I was able to stay two hours until Thomas Kurian executive vice president of Oracle products development detailed the future of Glassfish portfolio.
The speech was not very clear and a little bit confusing. As expected, I learned from Thomas Kurian that Fusion, Weblogic and JDeveloper remain strategic products for Oracle.

Glassfish App Server and Netbeans in second league ?

On the other side, it has been plan that NetBeans, Glassfish server and ESB will now play in second league. Netbeans continues as “Lightweight”IDE” and Glassfish will be the “JEE reference server”.

This does not sound well for me. I don’t know if you remember what the “Reference implementation” was before Glassfish. It was a very slow application server just useful for IT students and training. We all know that Glassfish has the potential to support enterprise application, but it will lose its credibility and be limited to departmental applications. Even if it is not true, what will be Oracle response when a company will ask a quote to support 20 Glassfish app servers for an enterprise system?

No more investment for Open/Glassfish ESB ?

http://www.oracle.com/ocom/groups/public/@ocom/documents/webcontent/044523.pdf

In Kevin's presentation, it was written that Oracle will maintain and invest in JCAPS and maintain Open ESB. Regarding Kurian’s professionalism, it is obvious that every word has been chosen and if the word “invests” has been written for one product and not for another one it is not by chance.
Unfortunately, despite comforting speeches, I’m not sure that Oracle will push and help Glassfish Portfolio to progress as it did during the last two years. As some bloggers said, I think that Glassfish future is more in its community hands that in the Oracle plans. If we are able to design and implement cheap and powerful integration systems for our customers we will give a good name to the Glassfish ESB/Server and the future of our community can be more interesting.

“Oracle 2010 = IBM 1960/70” Back to the middle age?

“Those who cannot remember the past are condemned to repeat it”. (George Santayana 1905)

Furthermore, I am very worried by the worst message broadcast during the web cast and it was not at all the future of Glassfish. This is Oracle's new creed: “Oracle 2010 = IBM 1960/70”. At that time, I was a young boy, but I often discussed with older colleagues that described that time as difficult for new technologies and new development. At that time, everything was decided by IBM. Your company had to choose between IBM materials, IBM OS, IBM Applications. It was a time where Big Blue was strong enough to impose its point of view to any CTO in the world. I can understand that Ellison wants to recreate the same context for his company but I did not understand why no analyst spotted that fact. (Update, that is not true anymore: http://www.theserverside.com/news/thread.tss?thread_id=59317 from Douglas Allen). As IBM was in the 60's 70's Oracle wants to be the new black hole of the IT. It is the return to the middle age.

Alas, this creed is the antithesis of what SUN did. Sun created Hardware, OS and software to run and collaborate with the IT diversity. From my point of view, this is the main difficulty we will face during the next years. As George de la Torre said (http://n2.nabble.com/OpenESB-GlassfishESB-strategy-td4472113.html#a4472113) “We convinced many large organizations to use open standard approach that SUN SOA strategy promoted. Dealing with Oracle we take the risk to go back to the past and be locked in by its business model far from an open system”.

This is the key lesson we have to learn from Wednesday web cast

In his blog Jason Baragry provides a very interesting use case where JBI and BPEL constraints create a dead lock. In that use case, a BPEL defines a two parts conversation where the second part is started by a callback invoked by the first part outbound partner.

When you develop and implement this use case, the application blocks without issuing error or exception. Jason explains in detail the reason of this deadlock.

When the BPEL invokes the EJB, it expects an acknowledgement in return. This acknowledgement will be returned when the EJB method invoked will be finished. To finish, the EJB method waits for an acknowledgement from the SOAP connector. The SOAP acknowledgement will be sent only when the BPEL will be available to receive the SOAP Message. But unfortunately, the BPEL is waiting for the EJB acknowledgement to receive the SOAP message. In brief, we designed a vicious deadlock.

Jason found out a workaround by putting the EJB outside the BPEL composite application. The connectors between the two composite applications will provide acknowledgement that will unlock the process.

Some drawbacks

However, JEE SE has been designed to improve the performance in a JBI environment. By putting an EJB and a BPEL (and using JEE SE) in the same composite application, we create a direct communication between the two components and improve the performances. So it would be nice to find another workaround for the Jason use case.

What is the real matter?

How could we end the deadlock in our application?

A simple way is to provide an ACK to the BPEL before the EJB starts to run and invokes the callback service. To do it, we propose a very simple solution. We add another BPEL (named “Bridge BPEL”) component between the first BPEL and the EJB. Of course, the bridge BPEL is not set to atomic. The inbound and outbound WSDLs for the “Bridge BPEL” are exactly the same and are the EJB inbound WSDL. We design the simplest process possible.

The bridge provides the same entry than the EJB and after a simple assign invokes the EJB.

Then in our casa application we insert the bridge between the BPEL and the EJB

The connection in orange indicates that the BPEL does not call directly the EJB but invokes the bridge as intermediary.

What’s happen at the acknowledgement level?

The first BPEL invokes the bridge that sends back immediately an acknowledgment (The “Bridge BPEL” is not set to atomic) then the first BPEL is able to continue the process and waits for the SOAP invocation. The bridge invokes the EJB and waits for an ACK from the EJB. The EJB invokes the first BPEL callback. A SOAP message is received by the first BPEL and an ACK is returned to the EJB. Finally, the EJB returns an ACK to the bridge. All the partners are now unlocked.

Conclusion

Writing a Bridge BPEL is very easy and takes less than one minute. Even if this workaround makes more complex the global process, this pattern is very simple to design, implement and understood.

Introduction

Last week, during a travel in the Benelux, I met a nice guy name Roger (of course it is not a real name). In a bus, we had a friendly chat and after a while, he told me that he was an IT consultant and works as DBA for a famous insurance company in the country.

For the ones who complain of their software editors, I would like to report the Kafkaesque story that Roger told me.

The context

Roger works for a company that uses for years an ERP (let’s name it “J”). The ERP J has been bought by a very famous editor (let’s name it O) that has already in its portfolio another ERP (let’s name it “OA”). Roger manages and monitors the version 9 of the database O used by the ERP J. During many months the EPR and the database worked perfectly together.

First act

Two months ago, for the first time, the database crashed. As Roger is a good DBA, he was able to restore quickly the database. But unfortunately, after few hours the database crashed again. Roger found out a viscous bug in the database and in order to find a solution, he called the O support who was not surprised since the bug was well known. An O consultant told Roger to change a parameter from the value X to Y. “Perfect solution”. The database worked well without crashing. End of the first act.

Second act

After a while the ERP users realizes that the ERP performances decreased and were divided by 10 to 100. Quickly the company found out that the bottleneck came from database. Another O consultant stepped in to optimize the database and diagnosed the problem. THE SOLUTION was quickly found out: The parameter set at the value Y must be set to X. Immediately, Roger reacted and replied that the value X crashed the database.

The solution

The editor admitted the problem and by way of solution proposed to migrate the database from the version 9 to the version 10. Indeed, the new version solved this problem.

Unfortunately at present, the ERP J does not support the version 10 of the O database even if the ERP and the database belong to the same editor. As final solution, O proposed to simply drop the ERP J and rebuild the company organization on the other ERP OA. Of course, O would assist the company during its migration. (What a pitiful solution!!!).

I hope you enjoyed the depressing story of Roger and his database.

A good new never arrives alone.

This month Pymma is pleased to announce two very good news.

KBC bank and Pymma consulting Partnership

After few months of partnership, we are pleased to announce our collaboration with the Belgium bank KBC on one of the most important Java CAPS projects in Europe. Pymma has been chosen by KBC as external Open ESB/Java CAPS expert to train its teams, to advice them about Java CAPS good practice and to propose technical solutions on the new technologies brought along with JBI and Java CAPS. We hope this partnership will be fruitful and successful for the two partners.

Pymma Open ESB community Partner

The second good news has been published last week by Sun Microsystems: Pymma consulting is officially Open ESB community Partner. We are proud to be the first company selected not on our ability to develop JBI components but on our expertise on Open-ESB consulting and training. This agreement results from lot of work from our part but also from the part of the Open-ESB team in London. I would like to thank Mike http://blogs.sun.com/mikesblog/) and particularly Louis http://blogs.sun.com/polyblog that support us during the last months.

Is SOA is dead (the debate)?

In that time where services and SOA architectures are denigrated, we would like to remind you that four years ago, the same company (http://www.burtongroup.com/) predicted the end of the J2EE platform and the same fate for .Net . Nonetheless, the polemic on Internet on this topic is important and expresses a trouble in the IT community with SOA. I hope I’ll have time in a next post, to comment this situation and break down the reasons for this trouble. However, at Pymma, we think that architectures relying on essential concepts like intermediation (contract of service and bus) have a promising future. The open ESB family (Open ESB, Glassfish ESB and Java CAPS) allows us to design and develop this type of architecture. It's for this reason that our customers decide to invest with us in these technologies.

See you soon

Last week I lectured on JBI and Open ESB to IT people. At the end of the presentation a delegate asked the awkard question: “Do you think that integration is one of the real concerns for the companies and not just a new buzz word or fashion”. We were at the end of the lecture and I had no time for a long and detailled answer. Be persuasive was a real challenge. In order to convince my interlocutor, I did not try to give him further detail on the “I” of JBI but simply I told him story that happened few days ago at Pymma consulting.

Here in UK, if you don't come from the big consulting agencies like Cap Gemini, Accenture or IGS, the companies are used to test the contractors during the interview . The tests are interesting theoretical exercises that often reveal the current IT preoccupations of the company.

By chance, four of our friends’ architects went for interviews and brought back the tests for debriefing. (Pymma is not IGS nor Accenture “thanks God”). The first had an interview with a software editor, the second with one of the largest retailer in Europe; the third with a major utility company in Benelux and then the fourth with an automotive manufacturer.

We compared the different tests, we were amazing to discover that the test topics were very similar.

The test requirements were as follow: “We want to create a new reliable, secure and scalable application bla bla bla ... For all the cases, the key requirements were: This application must be easily integrated in the company IS, able to communicate with legacy application and external partners. Integration was the key point requirement of the tests !!!

I don’t know if the four companies are a representative sample of the market, but it is clear for us that integration and agility are fast growing concerns for IT Teams.

I don’t know if I wan approval with my story, but regarding the tests similarities we are convinced that design and implementation of architecture dedicated for integration is the present challenge for many companies.

To be continued …

The last week at Sun Microsystems office in London, I had the opportunity to discuss with people working on Open ESB. It's always a pleasure to visit Sun’s people. They're always affable, thoughtful and the coffee not so bad.

During the first part of our meeting we exchange our points of view about JBI, Open ESB and the community and how our customers and prospect comprehend the product. It’s was not simple courtesies exchange but we discuss honestly about Open ESB difficulties.

During the second part of the meeting, we discussed about the new features and Sun’s marketing decisions about Open ESB. I am happy that some of our claims have been agreed by Sun. Let’s start by the most important:

From November a professional support for Open ESB will be proposed by Sun. This is very good news that will give reliability and confident to our customer.

Further detail on Sun support

Three support levels will be proposed with the 4 Open ESB based products defined by Sun Marketing. I report in this blog the products names and features detailed during our meeting but of course, they can be changed by Sun’s marketing at any time. But I think that finally this slicing will remain the same.

I describe bellow the four version proposed by SUN

1. Open ESB: Open ESB is the community which contains all the open source components and is part of the wider GlassFish community. The current Open ESB download includes most of the components and GlassFish, NetBeans bundle. Anyone can access the source for the core runtime from Open ESB. Open ESB is not just about GlassFish - the JBI core can run in WebSphere, JBoss or in Java SE (i.e. bare JVM). Sun will not provide support at this level. Support is provided by the community.

2. GlassFish ESB: GlassFish ESB is a binary distribution only of a supported set of components running in GlassFish and design time NetBeans tooling with the required add-ons pre-installed (e.g. binding wizard, custom encoders, XSLT / BPEL editor etc...). It includes a selection of stable service engines (Java EE, BPEL, XSLT, Data Mashup) and binding components (HTTP, FTP, FILE, JMS, Database, LDAP) designed and developed by Sun. GlassFish ESB will be downloadable Buying a license, you will get standard support, patch and knowledge database. This product aims at small and departmental applications since Clustering is not provided nor supported at this level. It can be found on https://open-esb.dev.java.net/glassfishesb

3. ESB suite: ESB suite is the competitor of IBM, Oracle-BEA ESB product. Designed for Enterprise applications. It supports Clustering, be packaged with Enterprise adaptor (mainframe, software package…). Premium services will proposed with this version (Top support, knowledge database, patch …). ESB Suite will be a strong competitor to legacy ESB Suite. It can be found on http://www.sun.com/software/javaenterprisesystem/javacaps/esb_suite.jsp

4. Java CAPS: Java CAPS is the well known product that includes the ESB suite but also many other suites (Financial...). Java CAPS also includes MDM Suite which has an open source presence at Project Mural (https://mural.dev.java.net/) Further details on Java CAPS could be found on
http://www.sun.com/software/javaenterprisesystem/javacaps/index.jsp

Once again, I would like to thank again Sun Team (Louis http://blogs.sun.com/polyblog , Mike http://blogs.sun.com/mikesblog/) for their real motivation for Open-ESB products, their dedication to the community and receptivity to our suggestions.

So what a benefit for ESB community?

The best consequence of this announcement is that we will able to propose professional support to our customers and prospects. As a result, Open-ESB will increase its creditability towards the executive and management. Now Open-ESB is in position to compete with other ESB Suites

At Pymma we think that it’s a time for new opportunities and good business with Open ESB.

This month, I stayed in Paris for few days and by chance, I had the opportunity to met people from EBM Websourcing, Gael Blondelle (CTO) and Pascal Portes (Sales Manager).

EBM resourcing is a software company which develops an interesting implementation of JBI named Petals. The company is member of the JSR 312 (JBI V2.0) expert group.

During one hour, we discussed about JBI projects, compared Petals and Open-ESB features. We shared ideas and feedback on ESB projects and integration technologies.

Petals is a JBI open-Source implementation that contrary to Open-ESB, has been conceived from the beginning, as a stand-alone application fully distributed. This is one of the main strengths of the product. You can define multiple domains on different machines and different locations, and consider them as a global bus (NMR).

Petals and Open-ESB integration processes are similar but Petals development tools (based on Eclipse) do not emphasize on WSDL as Netbeans does.

Petals is packaged with many Services Engines (BPEL, XSLT, EIP…) and Binding Components (Http, Soap, FTP, Mail…). A nice and easy-to-use console is provided for administration and supervision.

Congratulation to EMBWebsourcing for this very interesting project and Good luck to Petals.

Jonathan Schwartz new policy

Few years ago, Jonathan Schwartz replaced Scott McNealy as SUN Microsystems CEO. Swartz's first decision was to convert Sun into an Open-Source company. Consequently, Solaris OS, Application Servers and even the Java language were opened and their sources published. At present, Sun is viewed as a major Open Source actor.

Sun’s new sales philosophy proposes, on one hand, its best products in an open-source format and on the other hand, commercial support and hardware. The best examples of this new philosophy are Open-Solaris and Glassfish. You can download these products, use them and test them. After you have built applications with these tools and wish to move into a production environment, you can buy support from Sun.

Open source or Commercial version, it's up to you!

Alternatively, you can as well buy commercial versions at the first place. Even if open sources and commercial versions are slightly different than the open-source ones, more than 95% of their code is originated from the same development branch. Example : SUN proposes its queue messaging system with two similar versions, respectively named “SUN QM” and "Open-MQ". The only difference is the amount you pay for the technical support.

Everyone can find advantages in this sales policy on Sun products: companies and developers try and develop for free and can rely on Sun support in production. As a matter of fact, Sun uses these “free” products as Trojan horses to conquer new market shares, penetrate new companies and sell Sun hardware.

Why not for ESB Products ?

Unfortunately, there is a small issue in this picture: Sun's ESB platform is the exception in this sales policy. In Fact, Sun proposes two different tools for ESB developments. The first product. "JCAPS", is a commercial product inherited from Seebeyond. The second product, "Open-ESB" is based on JBI specifications (JSR 208) and was developed from scratch about 2 years ago.

Alas, JCAPs and Open-ESB are definitely two different products.

• JCAPS ignores JBI specifications
• JCAPS connectors are based on JCA specifications and not on JBI.
• Open-ESB development process is based on Web services specifications, JCAPS not.
• JCAPS and Open-ESB developments are not compatible.

Hundreds other differences can be found between the two products.

We can understand that for a while, for technical, marketing or business reasons, a company supports more than one product lines with the same functionalities. IBM does it and Oracle buying BEA will do it also.

However, there are several things that Pymma would like to understand:

• Why the download of JCAPS is only available for authorized JCAPS Partner ?
• Why SUN does not provide support for open-ESB as it does for Glassfish, Open Solaris or Open MQ ?
• Why JBI or Open-ESB are never mentioned at most ESB seminars organized by Sun Centres in the UK ?
• Why Sun marketing, Gurus or consultants are prolix about JBI in the public lectures and technical forums, and at the same ignore Open-ESB when they advice companies ?
• Is the policy of Jonathan Swartz policy only applicable for Java Legacy applications (Application Server, Message queuing…)? not for ESB tools ?

Of course, we already asked these questions to SUN but we never got clear answers.

Thanks for clarifying Sun's position

Many companies believe in JBI and their developers spend time and energy working on Open-ESB . These companies would certainly be interested to hear Sun's explanations on the above questions. They probably want to be sure that Open-ESB will not be just a prototype for the new JCAP version (only reserved for SUN JCAPS Partners). They certainly want to be credible by proposing SUN's professional support on Open-ESB as they do for Glassfish and Open-Solaris. After, they only need from SUN to clarify its position and give a clear prospective for the future of JBI and Open-ESB. We hope that through this blog Sun will hear us and we will give us clear answers.

Le mois dernier, j'ai reçu un DVD de Sun Microsystem contenant une version d'OpenSolaris (www.openSolaris.org) et pour la première fois, j'ai pu installer Solaris sur mon vieux Thinkpad T40 qui grâce à des perfusions de GigaOctet de ram, rend encore de bons services. C'était la première fois que je voyais s'allumer la lumière témoin du wireless. Après une rapide séance de configuration, la machine était prête au service. Je précise que par devoir ou par paresse, j'ai toujours travaillé dans un environnement Windows et que je ne suis pas du tout compétent en compilation Unix ou en écriture de scripts shell plus ou moins mystérieux ou ésotériques pour moi. La configuration dont je parle ici, ne concernait que la connexion Internet et l'impression .J'en profitais dans la foulée pour télécharger les versions Solaris X86 des outils java actuellement utilisés chez Pymma (NetBeans, GlassFish, open-ESB).

Les vacances de fin d'année passées, je me suis penché plus sérieusement sur ma nouvelle configuration et depuis bientôt 10 jours, je travaille parallèlement sur un environnement Windows et un environnement Open Solaris. A première vue, l'avantage est à Windows. L'interface utilisateur est mieux finie, les fontes sont plus lisses, sans défauts et tous les logiciels du monde sont à notre disposition. Cependant, en utilisant la suite de développement Netbeans / Glassfish / Open-ESB que je me suis aperçu avec surprise de l'extraordinaire fluidité et de la vitesse des applications Java sous Solaris. Rien que pour l'ouverture du serveur d'application le temps gagné est important en pourcentage. La compilation et le déploiement d'applications sont rapides. Un sentiment de stabilité et sérénité se dégage de cette configuration et par conséquent, j'arrive à fournir un travail plus important et avec une meilleure qualité.

Je vous conseille vivement de tenter l'expérience soit en partitionnant votre disque, soit en utilisant un logiciel de virtualisation. (OpenSolaris ne s'installe pas sous virtual PC (Janvier 2008) mais cela fonctionne bien avec VMWare pour Windows).

Faites donc un essai et dites moi ce que vous en pensez

Paul