CamelCase

Groovy for quick text clean-up

2009-11-22T15:04:00.016+01:00

Having some XML files to clean-up and transform, I was looking for a script-based solution, so that I don't have to go through the Java edit-build-run cycle. Usually I would think to Python, but it's a long time since I have touched it and then I wanted to try some Groovy.

The file I have to transform is an automatically generated XML, like this:


       <_pdl></_pdl>

       <_tkn></_tkn>

       <_out></_out>

       <_tds></_tds>

       <_evt></_evt>

       <_lfn></_lfn>

       <tc></tc>

       <fc></fc>

       <dkey-protected></DKEY-PROTECTED>

       ....

I want to strip things out to get only the start elements, like this:


<_pdl>
<_tkn>
<_out>
<_tds>
<_evt>
<_lfn>
<tc>
<fc>
<dkey-protected>
....

A quick and dirty Groovy solution can be something like:


def file = "C:\\Users\\mauri\\Desktop\\mapping.txt"

StringBuffer dest = new StringBuffer();

new File(file).eachLine{ line -> 
        line = line.trim()
        if (line.equals("")) {
        } else if (line.indexOf("/") > -1) {
            dest.append(line.substring(0, line.indexOf("/")-1))
            dest.append("\n")
        } else {
            dest.append(line)
            dest.append("\n")
        }
    }

print dest.toString()

Probably there are much better ways to do that in Groovy (I'm a rookie here), but I can recycle most of my Java skills and well known Java syntax, which saves me a lot of time. Especially, even if I have to learn new interesting things like closures, I can re-use years of knowledge about the Java API, which from my point of view makes Groovy a winning tool in the JVM world.

NetBeans IDE 6.8 Beta

2009-11-13T07:56:00.004+01:00

NetBeans IDE 6.8 Beta is available for download. This release is especially targeted on providing support for the new JEE 6 specifications, which represent a major evolution of the JEE platform toward simplicity:

Java Enterprise Edition 6 support in NetBeans:

Web Projects with Java EE 6 and Java EE 6 Web profiles, EJBs in web applications
EJB 3.1 support, EJB project file wizard also supports Singleton session type
RESTful web services (JAX-RS 1.1), GlassFish Metro 2.0 web services (JAX-WS 2.2), JAXB 2.2
Java Persistence JPA 2.0, deployment, debugging and profiling with GlassFish v3 application server

The delay of Oracle - Sun deal

2009-11-05T22:10:00.034+01:00

In FT.com I read: Oracle braced for EU objection on Sun deal

"Brussels’ concerns centre on Oracle’s assumption of MySQL, an open source software company that Sun acquired in 2008. Opponents of the deal claim MySQL could become a serious competitor to Oracle’s own core business in the long term."

Maybe Oracle is not too worried about the delay: what if in the meanwhile Oracle tries to push Sun customers to Oracle database and middle-ware? Money lost today can be recovered tomorrow... The apparent lack of urgency from Oracle, despite their complaints about "Sun loosing 100$ millions a month" could be a signal they just want to let the Sun's ship sinking?

At present some of the new open-source software technologies Sun is developing are very smart, lightweight and cheap, especially cheaper than Oracle's. Just try yourself to install and setup the Oracle SOA suite and then try the same experience with Glassfish ESB. Why should Oracle let live a potentially disruptive competitor to its present product line? Well, if only Sun were aware of its own middle-ware technologies and, especially, actually able to sell them...

Sun top management unfortunately has done a great job disrupting, wasting and disbanding all the SeeBeyond technical and commercial knowledge in the SOA / EAI field, with a series of totally bad organizational and operational decisions. Especially, they disbanded the Professional Services teams they have inherited from SeeBeyond, leaving the field almost totally naked and unable to provide high level consultancy services. Exactly that same SeeBeyond team that before was able to compete and deliver against all the software giants, despite the fact that, to be honest, ICAN 5 was initially a terribly broken and unstable product. Here we are now, easy to predict when I left Sun in 2007: "I told you, guys".

I admit the EU's objection about MySQL is not without foundations, but while political games are running, thousands of Sun employees, partners and customer are facing hard times.

"A good plan violently executed now is better than a perfect plan executed next week."
-- George S. Patton

Fuji Simple Service API, SpringDM and OSGi Integration with JBI

2009-11-03T07:50:00.011+01:00

Sujit Biswas wrote an interesting article which:

"[...] shows how to integrate Fuji simple service api with spring/springDM application, We will create a springDM application which instantiates the above provider Implementation , based on spring-config and spring-osgi-config files."

Fuji allows for Spring and OSGi services integration

"The simple service provides the capability to invoke/interact with JAVA code outside of JBI, i.e Service API provides a bridge between code that is hosted outside of a JBI component and service endpoints available on the NMR."

This enables integration of OSGI/POJO services with JBI. Read Sujit's article for more.

About Fuji:

"Project Fuji forms the core component of Open ESB v3 effort and represents Sun's next generation open source integration runtime, focused on providing a lightweight, developer-friendly, and extensible platform for composite application development.

At the core of Project Fuji is a lightweight micro-kernel based on JBI (JSR 208) and OSGi. Packaged as an OSGi bundle, the micro-kernel can be installed in any OSGi R4 compliant runtime (such as Felix, Knopflerfish or Equinox), including GlassFish v3. JSR 208 support introduces a robust, message-based service bus to the OSGi environment and allows the wide range of existing JBI "components" (adapters and containers) to run in Fuji.

Developer experience is a primary focal point in Fuji as evidenced by the level of flexibility and accessibility offered in the platform. Starting with a rapid, top-down development language, IFL (Integration Flow Language), developers can quickly and easily generate an integration application using a domain-specific grammar. The service development model favors convention and configuration over boilerplate code and framework APIs, allowing integration developers to focus on the code that matters. "

Link to Java CAPS Release 6.2 Documentation Center

2009-10-11T13:29:00.003+02:00

The Java CAPS Release 6.2 Documentation Center is already available at:

http://docs.sun.com/app/docs/doc/821-0538

Java CAPS 6.2 to be released

2009-10-07T16:55:00.008+02:00

There are rumours that the latest Java CAPS 6.2 will be released within end of this month. So far Sun has already published the release notes.

In summary, from the release notes:

This release of Java CAPS uses the following versions of NetBeans and GlassFish:

NetBeans IDE 6.5.1
GlassFish Enterprise Server 2.1 patch 2

This release of Java CAPS provides new support for the following operating systems:

Design-Time

Windows Server 2008
Red Hat Enterprise Linux AS 5.3 (64 bit)

Runtime

Windows Server 2008 (OS: 32 bit; JVM: 32 bit)
OpenSolaris 2008.11 (OS: 32 bit; JVM: 32 bit)
Red Hat Enterprise Linux Server 5.3 (OS: 32 bit; JVM: 32 bit)
Red Hat Enterprise Linux Server 5.3 (OS: 64 bit; JVM: 32 bit)
IBM AIX 5L 5.3 (OS: 64 bit; JVM: 32 bit)

This release of Java CAPS adds support for the following browsers and external systems:

Firefox 3.5.2 for accessing all Java CAPS browser components
OpenSSO Web Services Security (WSS) Agent for the HTTP Adapter
SWIFT 2009 messages and SWIFT 2009 certification
SAP JCo 3 for the SAP BAPI Adapte

My comments:

It is a bit disappointing that the IDE is not Netbeans 6.7. I have experienced JAX-WS Web Services deployment issues with Netbeans 6.5 and the suggested solution has been to upgrade to Nb 6.7 (!?!) so I really hope Sun has fixed some bugs in Nb 6.5 before packaging it with JCAPS. It would be annoying to start patching the stuff the day after downloading it.
Finally Java CAPS has an understandable version numbering convention: this release will be called 6.2 and not "6 update 2", which meant nothing unless you want to remember customers a sound close to the Windows service packs...

Tungsten

2009-09-28T04:23:00.005+02:00

It seems there is a fork of the old C-JDBC project that I was not aware of:

Tungsten is an open source stack for deploying and operating horizontally scaled database clusters, also known as database scale-out. Scale-out works by spreading data across multiple, independent database servers connected through a network. The model offers an intuitive, incremental approach to solving the following important database problems:

Preventing data loss though up-to-date replica databases and coordinated backups
Increasing overall application availability by providing rapid database failover
Raising performance and through-put by dispatching read traffic to replicas
Integrating data between heterogenous systems, for example to support scaling of commercial databases using low-cost open source databases.

C-JDBC is:

an open source (LGPL) database cluster middleware that allows any Java application (standalone application, servlet or EJB container, ...) to transparently access a cluster of databases through JDBC(tm). The database is distributed and replicated among several nodes and C-JDBC balances the queries among these nodes. C-JDBC handles node failures and provides support for checkpointing and hot recovery.

EJB 3.1 specs heading in the right direction

2009-06-27T02:37:00.011+02:00

Since a long time EJB were loosing ground in favour of simpler and more effective programming models. specifically, Spring has become the leading framework to develop and deploy JEE applications.

(spring AND java), (ejb AND java) Job Trends

(spring AND java) jobs - (ejb AND java) jobs

For these reasons, a sense of urgency is pushing the new EJB specifications toward a massive simplification. This trend was clearly significant when the EJB 3.0 were introduced, and it is continuing now with the latest EJB 3.1.

Ken Saks, the Specification Lead for EJB 3.1, has written a nice summary of the hottest features. "A Sampling of EJB 3.1" shows you the most interesting news. Together with the upcoming Glassfish V3 , which is a very lightweight and OSGi based application server, the new specs can represent a quantum leap in terms of productivity and win back some developers.

It is difficult to predict if it is too late to regain developers' confidence and market quotas, but the combination of JEE 6 + EJB 3.1 + Glassfish V3 seems to be heading in the right direction: no overload of features but simplification.

Specifically, Ken Saks mentions:

Ease of Development: the ability to package enterprise bean classes directly in a .war file, without the need for an ejb-jar
No-interface View: you don't have to write interfaces if you don't need it
Simplified Packaging: You now have the option of placing EJB classes directly in the .war file, using the same packaging guidelines that apply to web application classes.
Singletons: A singleton is a new kind of session bean that is guaranteed to be instantiated once for an application in a particular Java Virtual Machine
Application Startup/Shutdown Callbacks: The introduction of singletons also provides a convenient way for EJB applications to receive callbacks during application initialization or shutdown

Simplification, is the way to go.

JMS Over HTTP Using OpenMQ

2009-06-22T23:45:00.003+02:00

DZone has an interesting article about new OpenMQ's features:

"OpenMQ provide different transport protocol and access channels to access OpenMQ functionalities from different prgramming . One of the access channels which involve HTTP is named Universal Message Service (UMS) which provide a simple REST interaction template to place messages and consume them from any programming language and device which can interact with a network server. UMS has some limitations which is simply understandable based on the RESTful nature of UMS. For current version of OpenMQ, it only supports Message Queues as destinations so there is no publish-subscribe functionality available."

Read the full article.
About OpenMQ.

The end of the body-shopping model

2009-06-18T09:46:00.019+02:00

In the very last few years in Italy I have seen many system integrators undertaking what I have always seen as a dangerous path: progressively moving toward low-valued body-shopping. Healthy companies, with a good track of high-level consultancy and custom product development, decided it was more lucrative to only hire inexperienced kids just out of Universities and send them to customers. Two years of experience was enough to classify those kids as "senior developers" and make good margins out of them.

The mixture looked good: horde of young people, rich of enthusiasm and open to accept ridiculously low salaries have been sent to final customers, where the only selection criteria has been: very low daily rates, please. Really, most customers do not even look at resumes, they just want to keep a pressure on daily rates. On the other hands, it happens to read ridiculous job posts here in Italy, for example "A junior developer with at least 5 years of Java experience and 3 years of SAP". And the proposed salary, of course, even more ridiculous.

A lot of consulting companies have seen only one direction: grow the number of employees, grow sales figures, making margins by selling a lot of very junior developers for low daily rates. This has been perceived as an easy path for growth, less risky than investing in new technologies and growing an high-level consulting profile. On the other side, customers only devoted on reducing visible costs, without any kind of performance monitoring, created a bid competition on the lowest rates, regardless of effectiveness. Now they get what they deserve.

One bad day, the financial crisis comes.... One bad, black day, that big customer tells you he doesn't need your 50 kids anymore, because there is no more budget for that project. And the day after, another customer tells you that the expected budget for that new project has been cancelled, so you don't know where to collocate those 30 kids you have just hired. The game is over, as you have to pay salaries for people hanging around your offices without anything to do. You have to start firing people and fighting with unions (Italy and usually Europe is not US, you can't just kick people out of their cubicles and make your employees paying the bill for your lack of strategy). You don't really know the people you hired, because you have parked them to a customer for the last few years and forgot about them. Maybe now it could be time to invest into quality, but it is difficult and a bit late: you realized that you best people left the company a while ago, now you are full of developers with bad habits - they growth without guidance, they never took any good training. Suddenly your revenues disappear, your margins are red and your credit is over.

However, I rarely encounter other kinds of companies, those who are less greedy, have planned to grow at a sustainable rate, invested in less but more skilled people, train their junior developers and discuss reasonable rates with their customers. Those who think about IT in terms of solutions (quality) instead of man-days (quantity) and reward their own people with challenging jobs and decent salaries. Very often, this smaller companies are the ones surviving better to crisis, because they are in control of their business.

Usually, in a free market quality of supply is driven by quality of demand, so I guess customers need to change their purchase habits soon if they want to shape the IT market differently. Quality pays for itself, sooner or later.

"My personal feeling is that this is how any further improvement of the world will be done: by individuals making Quality decisions and that's all. God, I don't want to have any more enthusiasm for big programs full of social planning for big masses of people that leave individual Quality out. These can be left alone for a while. There's a place for them but they've got to be built on a foundation of Quality within the individuals involved. We've had that individual Quality in the past, exploited it as a natural resource without knowing it, and now it's just about depleted. Everyone's just about out of gumption. And I think it's about time to return to the rebuilding of this American resource -- individual worth."

Quote from Robert M. Pirsig, Author "Zen and the Art of Motorcycle Maintenance"

GlassFish ESB v2.1 has been released

2009-06-18T09:09:00.001+02:00

"New in GlassFish ESB v2.1 is clustering for all components, a great number of bug fixes, the inclusion of the IEP SE and Scheduler BC (a new component!), several component enhancements, inclusion of the latest NetBeans 6.5.1 IDE and the latest GlassFish v2.1 application server, and support for AIX 5.3. "

Look at the release notes for more.

dutchman's log: GlassFish ESB BPEL cluster with correlation

2009-05-24T12:25:00.003+02:00

Marjo wrote an interesting article about "GlassFish ESB BPEL cluster with correlation".

He wrote:

"GlassFish ESB 2.1 will support GlassFish cluster. BPEL will also run clustered. Cluster support includes support for BPEL processes with correlations.

Once a BPEL process instance starts to wait for a correlated receive activity, the instance will be passivated. If the correlated input comes in to any instance of the cluster, the passivated process instance will be re-activated on that appserver instance, also if it is not the appserver instance where the original process was running, and continue where it left off when it was passivated.

To make this work, BPEL persistence must be enabled, and the BPEL engine must be running in a cluster in an appserver domain set up with the cluster profile."

This feature was missing since a long time. Read Dutchman's full article to learn all details.

Surviving the economical climate as a consultant

2009-04-28T11:54:00.026+02:00

These are hard times, but there are in my opinion some healthy rules one should remember to survive in this difficult economical climate. Those are only nine, not to be blaspheme...

Be prepared. It sounds obvious, but you need to know your stuff very well. For example, JEE is not about knowing many different application servers (I don't even understand what it means to "know an application server"), it is about "how to design that process so that I am in control of the distributed transactional context". Something like this. Filling your CV with buzzwords and acronyms can lead you to get interviewed by superficial recruiters, but then you are naked if you don't have concrete skills.
Be versatile. You have to be mentally prepared on how to deal with unforeseen environments, technologies and unknown situations. Be prepared to work abroad and to get a flight early on Monday mornings. This is quite usual for US consultants, but young consultants and consulting companies in Europe should start thinking at the whole Europe as a huge market. Exit your comfort zone.
Be consistent. Deliver quality and think on how to solve your customer's business needs, IT issues can't be your only priority. Do not think on how to consume hours and days, instead focus on delivering useful stuff. Be prepared to suggest fixed-price packages: if you really know your stuff you can make good estimations and take the risk, you cannot just move the deadline's responsibility into your customer's shoulders and throw out a timesheet each Friday, it is no more enough.
Improve your skills. Take time to revitalize some old skills and to learn something new. Buy books and study, but expecially experiment on your own.
Accept short terms activities. Learn to live in a world where things change daily, if you are flexible you will have more chances. Being squeamish about a five days assignment don't provide you with a good credit nowadays.
Do not undersell yourself. Flexibility doesn't mean you have to drastically reduce your consulting rates only because a couple of recruiters tell you to do so, it is easier to negotiate discounts before than to increase rates afterwards.
Be business-oriented. Knowing your IT stuff is no longer enough, try to understand and study basic economy, marketing and generally speaking how your customers make their money. Your salary or your consulting fees don't come from magic, there should be a sustainable business and usually has nothing to do with the latest Linux distribution or that cool scripting language that you are so eager to learn.
Learn foreign languages. I wish I studied another language in addition to English when I was at school. Decent English in IT is of course mandatory, French, German and Spanish can open a wide set of new opportunities. Of course you need to always remember point #1, you need to be technically prepared: a silly thing in seven different languages is still a silly thing.
Sell. Work is no more jumping into our head, it is necessary to go out and find it. Garden your network, market your skills and then be ready to sell them more often than usual, as assignments and contracts are getting shorter. Presentation skills, technical writing abilities and speech skills in front of an audience are the main sales tools of a freelance consultant, being the best hacker is no more enough.

By the way, I think most of these rules apply to both individuals and organizations. I see many consulting companies reacting to the crisis by just enforcing their usual behaviours and keep on providing exactly the same set of services of their competition. Differentiation is key.

Good luck, we need it anyway.

How to call a remote transactional Weblogic EJB from a Java client

2009-04-15T16:02:00.032+02:00

My objective here is to show how to call a remote Weblogic stateless EJB from a Java client, then adding the ability to invoke multiple EJBs in a client-controlled transaction.

The code below is very simple and has been tested with BEA Weblogic Application Server 10.0 and developed with the Netbeans 6.1 IDE. The original requirement was to call Weblogic EJBs from Glassfish, using the Weblogic user transactions from the client code. Let's say there is the need to call several EJBs and to make it in a single unit of work, this is not usually a best practice, as client-controlled transactions are usually slower and lead to bad design. The best would be to expose a transactional service from Weblogic which wraps all the calls in one server-side unit of work, but it is not always feasible if we are not in control of the other side and this is also an example how to call a remote EJB from Java, if one removes the transactional code.

Anyway, let's have a look at our sample JEE 5 service (EJB 3), which is deployed in Weblogic:


package com.mt.ejb;

import javax.ejb.Stateless;

@Stateless(mappedName = "CalculatorBean")
public class CalculatorBean implements CalculatorRemote {

    public int add(int a, int b) {
        return a + b;
    }
}

Above is a trivial "hello world" EJB, implementing a Remote interface. The mappedName = "CalculatorBean" is a mandatory parameter for the @Stateless annotation if one wants the EJB to be remotely callable.

I deployed in Weblogic, Netbeans offers the ability to connect to a Weblogic server, even if the plugin has limited functionalities it gives me what I need and allows me to work from my favourite IDE and deploy from there.

Here comes the client code, which is more interesting:


package com.mt.client;

import com.mt.ejb.CalculatorRemote;
import java.util.Hashtable;
import java.util.logging.Level;
import java.util.logging.Logger;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.transaction.UserTransaction;

public class WeblogicTest {

    private final Logger log = Logger.getLogger(WeblogicTest.class.getName());

    public WeblogicTest() {
    }

    public void callRemoteEJB() {
        InitialContext context = null;
        UserTransaction transaction = null;

        Hashtable env = new Hashtable();
        env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
        env.put(Context.PROVIDER_URL, "t3://localhost:7001");
        env.put(Context.SECURITY_PRINCIPAL, "weblogic");
        env.put(Context.SECURITY_CREDENTIALS, "weblogic");

        try {
            context = new InitialContext(env);
            transaction = (UserTransaction) context.lookup("javax.transaction.UserTransaction");
            if (transaction != null) {
                log.info("in transaction context.");
                try {
                    CalculatorRemote calculator = (CalculatorRemote) context.lookup("CalculatorBean#com.mt.ejb.CalculatorRemote");
                    transaction.begin();
                    int result = calculator.add(3, 5);
                    transaction.commit();
                    log.info("add=" + result);
                } catch (Exception ex) {
                    ex.printStackTrace();
                    try {
                        transaction.rollback();
                    } catch (Exception ex1) {
                        log.log(Level.SEVERE, "Can't rollback transaction.", ex1);
                    }
                }
            } else {
                log.info("transaction context is null.");
            }
        } catch (NamingException e) {
            e.printStackTrace();
        }
    }

    public static void main(String[] args) {
        WeblogicTest test = new WeblogicTest();
        test.callRemoteEJB();
    }
}

It is necessary to add the CalculatorBean EJB jar file and the wlclient.jar to build the above client code. The wlclient.jar can be usually found into folder \server\lib of our Weblogic server.

Let's comment the main code sections.

First, I populate the connection properties:


Hashtable env = new Hashtable();
env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
env.put(Context.PROVIDER_URL, "t3://localhost:7001");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "weblogic");

I look-up the initial context and get the UserTransaction from Weblogic's JTS:


context = new InitialContext(env);
transaction = (UserTransaction) context.lookup("javax.transaction.UserTransaction");

I lookup and call the remote EJB by enclosing the method invocation in transaction:

CalculatorRemote calculator = (CalculatorRemote) context.lookup("CalculatorBean#com.mt.ejb.CalculatorRemote");
transaction.begin();
int result = calculator.add(3, 5);
transaction.commit();

The lookup string "CalculatorBean#com.mt.ejb.CalculatorRemote" makes the trick, it is the Weblogic syntax to identify the Bean and its Remote interface.

Of course, in this trivial case there are not any transactions, but I wanted to keep the example very simple. If the EJB was transactional, the call made use of the transactional context, while in this case it is simply ignored.

Farewell SGI

2009-04-03T10:47:00.005+02:00

The glorious SGI, after being close to bankruptcy and going for chapter 11, has been bought by Rackable for mere $25 millions plus the assurance to pay its debts. I learned 3D computer graphics and OpenGL programming in the late 90s on SGI's Indigo and Octane workstations, beautiful pieces of hardware and software but already feeling the price pressure coming from much cheaper Windows workstations. It is a piece of the Silicon Valley computing history which was hit by the post New Economy bubble crisis and has never really recovered from that point.
Farewell, SGI.

Fluxology Alliance

2009-03-29T14:16:00.007+02:00

The Fluxology Alliance is a network of companies, from large to small, and independent consultants. The Alliance is committed to work together with Sun to build successful implementations with JavaCAPS and OpenESB, but also to spread the knowledge and awareness about other Sun's opensource solutions (Opensolaris, MySQL, Glassfish, Netbeans, ...). There are hundreds of former SeeBeyond customers out there and many of those are looking for migration path from eGate 4.x, ICAN 5.0, JavaCAPS 5.1 to JavaCAPS 6 and the new opensource Sun's offering.

The Alliance is mainly focused on the EMEA market. The idea was born because Sun needed more expert partners to help its customers dealing with large SOA / EAI implementations. Partners are distributed quite everywhere from Southern to Northern Europe, most of them are composed by former SeeBeyond and Sun employees with a long term experience around Java enterprise technologies and a deep knowledge of Sun's business. The membership is mainly about fair cooperation and exchange of information.

"Fluxology facilitates two cooperative global partner networks around OpenESB, JavaCAPS, its SeeBeyond predecessors, enveloping the Sun Java Enterprise System and complementary technology partners, to pave a pathway into the future towards "the adjacent possible" in both business relations and information technology."

On my side I'm a member of the Alliance as an independent consultant and already a Sun external contractor. If you want to learn more please point your browser to Fluxology.Net.

Frank Kieviet interview on OpenESB at DZone

2009-03-17T14:20:00.009+01:00

Dzone hosts an interview to Frank Kieviet, OpenESB Community Manager, about OpenESB, Java CAPS, Glassfish and future directions. It is a good summary of the present status, how difficult has been to get the former SeeBeyond suite as opensource and where it aims to go in the next few months.

From my point of view the OpenESB suite still lacks two major components:

A SOA Governance solution. A good registry / repository is an important side component of any ESB, at present Sun should at least establish a commercial partnership with other vendors about that, the strategy here seems a bit confusing and no clear message is available for consulting partners and end customers. My opinion is that OpenESB needs to partner with solutions having a similar dual opensource / commercial license, a closed-source only registry product could lead to difficult sales propositions.
A ESB management and monitoring console. The ESB Console project is very late, even if it seems a version 1.0 will be released within this year. Any ESB needs robust and easy monitoring and this can't be sold by suggesting users to build their own through JMX or other APIs.

A good SOA Governance suite should allow for easy monitoring and management, repository and versioning of files (for example, versioning WSDL is not enough, the imported XML messages need versioning). Then it should be a single place to apply orthogonal policies for security, auditing, billing, ... The model should be of a policies gateway, working in combination with the ESB as a services proxy.

So far, lacking an integrate offering from Sun, I am evaluating myself some third parties Governance solutions to suggest to my customers, some are quite nice and works well with OpenESB and Java CAPS.

The Crisis of Credit Visualized

2009-03-10T02:45:00.005+01:00

The Crisis of Credit Visualized by Jonathan Jarvis, an interaction and media designer, is one of the best explanation of the present credit crisis I have found on the Internet. It also a wonderful example on how to create a beautiful visual presentation.

GlassFish ESB Roadmap

2009-03-07T11:41:00.003+01:00

The OpenESB community just released a roadmap for this year. Things are accelerating.

GlassFish ESB v2.1

Scope:

* NetBeans 6.5
* GlassFish 2.1
* Full support for GlassFish clustering
* Scheduler BC
* Misc. performance enhancements
* Bug fixes

Target date: Mid May 2009

GlassFish ESB v3

Scope:

* NetBeans 6.7
* GlassFish 3
* Light weight composition
* IFL
* Maven Support
* OSGi
* Interceptors
* ...

Target date: Sept 2009

So the most interesting will be GF ESB v3 scheduled for September 2009. Glassfish V3 is a micro-kernel based app server running on a OGSi platform. The IFL language is an effort to simplify common ESB tasks and implementing a domain specific language, much like Apache Camel, to implement common enterprise integration patterns and messages manipulation (routing, filtering, splitting, pipelining, ...).

The OpenESB and Java CAPS consulting ecosystem

2009-03-06T13:21:00.024+01:00

Sun's new open-source strategy offers interesting consulting opportunities. In the last months I have worked closely with former SeeBeyond and Sun colleagues to build a network of partners able to independently support the free OpenESB and commercial Java CAPS platforms at all levels. A set of very skilled professional left Sun recently and joined the freelance market or started new companies. Most of these expert people were actually also in charge of developing core aspects of the Glassfish ESB, Java CAPS and MDM suites, so it is possible to even offer product's enhancements and customizations. Sun is supporting this effort, so we are more and more closely coordinating activities with Sun Services in US and EMEA.

It is a huge paradigm shift from SeeBeyond. When I was in SeeBeyond everything was closed and even secret, while Sun is now growing as an open company embracing open-source as a way to tackle the market from a very different angle than its competitors. At the beginning many Sun employees were doubtful about new Sun strategy, it is so distant from the company's culture. Sun was, and partially still is, an hardware and infrastructural software vendor, a company built by engineers for engineers, with a technology language and culture. Integration and SOA are much more related to pure business aspects, customer's expectation are very different because they take for granted that the technological problems are solved, what they want is business integration, which requires a lot of consulting expertise. This kind of combination of technical and business expertise is exactly in the DNA of former SeeBeyond consultants.

The network of partners is growing and able to fill the business gap. SOA is not much related to technologies, it is about designing and fitting an Enterprise Architecture, it requires first to understand customer's business needs. The OpenESB ecosystem is made of a set of commercially supported open-source tools which provides the possible best value for money. Now there exists also a worldwide consulting services offering able to put this software effectively in production.

OpenESB is an open community, where Sun, its partners and customer can collaborate to create the best set of features, pro-actively suggesting functionalities and corrections. In which ways OpenESB offering is different from both big vendors and other similar open-source products?

It is fully open-source and supporting open standards, so you can really avoid any vendor lock-in
Full commercial support and indemnification is optionally provided by Sun at much cheaper prices than any other big vendor
You can download the suite, develop your solution and then decide if and when buy commercial support
Comparing to other open-source ESB, support is provided by a much bigger company, the one who invented Java
The set of development and runtime environments (Netbeans, Glassfish, OpenMQ, JBI) is very mature and allows for better developers productivity than other open-source ESB

Netbeans make a big difference: this is a great IDE and the company behind it is the same building OpenESB, so you get a closer integration between the IDE and the ESB in the whole development cycle. Other products require you to edit by hand lot of configuration files, IDE integration is weak and often provided by third parties, unless you decide to buy a much more expensive commercial ESB from any other big vendor. Glassfish V2 is now a great JEE 5 application server, Glassfish V3 is going to be the market leader in terms of features.

So, what are the real services a customer can expect from the network of professional OpenESB partners?

High level consulting expertise, most consultants are former SeeBeyond and Sun professional services. No kids, senior people only with up to 25 years experience
Possibility to leverage both Sun's technical support and the open-source community, to get independent advices
Ability to modify or create custom JBI adapters, as many companies in the network are OpenESB code committers and some were even Sun product managers (can you really ask your Big Vendor to create a custom adapter for you?)
For previous SeeBeyond customers there is also a lot of added value, as the network can offer tailored migration plans from DataGate, eGate 4.x, ICAN 5.0, JCAPS 5.1 to OpenESB and Java CAPS 6
Ability to support big enterprises worldwide. I'm in touch with partners from Israel to Scandinavia, and in US also. We are looking for partners in Australia and New Zealand shortly.
Any vertical market: retail, healthcare, telecommunications, finance, energy, ...
Any EAI experience: SAP, Siebel, Oracle, CICS, SWIFT, Microsoft, ...
Identity management, Role management & provisioning, Security, Master Data Indexes, federated SSO, SOA Governance, Business Process Management, Rule Engines.
On going partnership discussions with Savvion, Fair Isaac, Autonomy and other specialized vendors.

An independent and comprehensive review of Glassfish ESB can be read here.

For more information about the "unit-42" partnership network, please drop an email to me or my business partner.

New Sun Glassfish Portfolio

2009-02-10T23:19:00.007+01:00

Sun has announced the new Glassfish Portfolio.

Finally Sun seems is learning something from MySQL, they are selling added-value tools for paying customers.

"GlassFish Enterprise Server subscribers are entitled to Enterprise Manager, which delivers improved management and performance monitoring features."

Before the Enterprise Manager was available only for Java CAPS. The new version seems to be a lot improved anyway:

SNMP monitoring: Leverages existing SNMP infrastructure to monitor GlassFish
Performance Advisor: Proactively monitors key performance indicators and automatically tunes JDBC connection pools.
Performance Monitor: Diagnoses performance bottlenecks with visibility into key GlassFish performance metrics.

This was a much needed tool for enterprise customers, as monitoring and management is one of the primary features of any ESB, by definition.

From my point of view Glassfish ESB is not an opensource product with optional commercial support, it is a commercial product with the additional benefit of being opensource. Putting words in the right order makes a lot of difference sometimes.

The Growing of REST

2009-01-28T03:37:00.021+01:00

Here I try to give my point of view on why REST is gaining a lot of traction against SOAP in the Webservices world.

First, I have to explain that REST is an architectural style while SOAP-based WS are just a way to implement RPC, which is the most basic inter-communication style. Even Corba one day went to the point of being very mature an stable, but how many new projects are now started with it? A technology should demonstrate itself within a reasonable time window, otherwise people get tired. My first SOAP implementation, I think it was 2000, was with Axis's ancestor Apache SOAP: I still feel the headache.

My opinion is that most self-proclaimed RESTful implementations are not really so, because REST is not just XML over HTTP (it can use JSON, plain text, Atom, binary streams, or a combination of all) but it is a way to implement an Object-Oriented architectural approach on top of Web resources (the data is the resource itself, the methods are the HTTP operations get, put, post delete, etc...). SOAP WS instead, as said, is plain, old RPC and it does not mandate to use HTTP only, but also works with other protocols such as JMS, etc.

Now I hope we agree programming languages evolved from procedural to OO, so I'd say the REST paradigm is more modern than RPC one, but we know that good OO is actually harder than procedural (and I mean good OO). So, IMHO, the traction REST is gaining is not due to the fact that it is conceptually simpler (as OO is not, if compared to procedural programming) but instead to the fact that REST is based on a simpler implementation, robust protocol (HTTP), few consistent operations (HTTP methods), a proven architecture (The World Wide Web, not a tiny one really...), a set of extremely tested technologies (Web servers, Web proxy and caches) and a long track of true interoperability and security (again, the WWW and SSL). Honestly I am very happy that I still access my on-line banking through HTTP + SSL and not any WS-Security......

Resource Oriented Architecture, implemented through REST, is actually conceptually harder than RPC style for the same reasons that proper Object Oriented modelling is conceptually harder than plain procedural programming. But a lot more rewarding, if we compare the final outcomes. And that's why, by the way, also good stuff like Spring is gaining a lot of traction: it allows to model a real domain through POJOs.

Maybe I am too old, because in this procedural world of SOAP and EJB (yes, EJB specs before version 3 forced a procedural programming style) I still persist thinking that Object Orientation should be the way to model business domains properly: I learned that many years ago and still nothing has been able to change my mind. Of course, integration often demands for a simpler paradigm than OO: probably scripting will happily rule here (IFL and Fuji anyone?).

My opinion is that the WSDL + WS-* combination, regardless of all the efforts, is still a way too complex, real interoperability is still questionable and security is largely unproven, if compared with plain, old HTTPS and its some billions of daily Web transactions. However, I agree things are improving, but while I'm at customer site I'd love not to spend days resolving WSDL and WS-* quirks and instead focus my attention to more added-value activities....

More simplicity quite usually equates to more security.

Tom Barrett's Open ESB and Mural Tutorials

2009-01-25T00:05:00.005+01:00

Sun's Tom Barrett has produced a set of very well written and easy to follow tutorials, which can gently lead the reader toward a step by step introduction with many of the newest OpenESB related technologies, together with Netbeans and Glassfish. Good job Tom!

Tom Barrett's OpenESB Tutorials

Dump Glassfish HTTP conversations to debug security

2009-01-23T01:11:00.013+01:00

In Glassfish is possible to dump the HTTP conversation to debug Web Services, by adding the following two JVM options to domain.xml:


<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>

Then when the web service is called the server.log will show complete SOAP envelopes for both request and reply:


[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
---[HTTP request]---|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Host: localhost:8080|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Content-type: text/xml;charset=UTF-8|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Content-length: 866|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
User-agent: Jakarta Commons-HttpClient/3.1|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
Soapaction: ""|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:svc="http://xml.netbeans.org/schema/svcMessages">
   <soapenv:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"><wsse:UsernameToken wsu:Id="UsernameToken-27540698" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"><wsse:Username>wsitUser</wsse:Username><wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">xhM3irVV+4ROPhzEjwlEeL7IViI=</wsse:Password><wsse:Nonce>oE1wwvm+ZLeBuvgDJvaLvw==</wsse:Nonce><wsu:Created>2009-01-21T02:13:32.238Z</wsu:Created></wsse:UsernameToken></wsse:Security>
</soapenv:Header>
   <soapenv:Body>
      <svc:payload>Maurizio</svc:payload>
   </soapenv:Body>
</soapenv:Envelope&gt;|#]

[#|2009-01-21T03:13:33.783+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|--------------------|#]

[#|2009-01-21T03:13:34.828+0100|SEVERE|sun-appserver9.1|com.sun.xml.wss.logging.impl.filter|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;_RequestID=9ffc6c88-9210-451f-ad64-08ec2bc5ca74;|WSS1408: UsernameToken Authentication Failed|#]

[#|2009-01-21T03:13:35.015+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
---[HTTP response 500]---|#]

[#|2009-01-21T03:13:35.015+0100|INFO|sun-appserver9.1|javax.enterprise.system.stream.out|_ThreadID=25;_ThreadName=httpSSLWorkerThread-8080-0;|
<?xml version="1.0" ?><S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><S:Fault xmlns:ns3="http://www.w3.org/2003/05/soap-envelope"><faultcode xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">wsse:FailedAuthentication</faultcode><faultstring>Authentication of Username Password Token Failed</faultstring></S:Fault></S:Body></S:Envelope>|#]

Alistair's top ten ways to know you are not doing agile

2009-01-19T01:46:00.010+01:00

I stumbled upon the following not-so-new blog entry by Alistair Cockburn, a nice short list of "bad smells" for lack of agile project management. These days companies are still frequently trying to engage project managers asking for arcane list of certifications which are mostly theoretical and paperwork-oriented. Alistair, who has written one of the best book ever about Use-Cases, instead insists on agile methodologies and expert leadership as the only effective way to deliver projects.

In my experience pragmatism, agility and the ability to deeply dig for real business requirements are the most important factors for successful integration projects. For effective consulting is mandatory to keep open a constant, daily communication link with business experts and project stakeholders, relationships with just customer's technical people almost never provide for the necessary unbiased information.

Too many developers are just trying to experiment with the latest "cool" technologies, only because they want to fill a row in their CV, regardless of the real business needs of their employers. In my experience these days two of the biggest CV-fillers are SOAP Webservices and BPEL, as I rarely see those technologies used properly.
Not that they couldn't be useful, but:

"When all you have is a hammer, everything looks like a nail."

SOAP WS and BPEL are the nowadays' hammers.