Why Maven rocks

In the beginning there was "make". Then "make" was eclipsed by "ant". Now I feel that maven is the brightest star in project build and project management universe.

I love maven. Truth be told, I was not always feeling that way. In fact I used to quite dislike maven. Then, my dear open source colleague, Diego turned me on to it. For quite some time, I did not get it at all. It seemed complex and bloated and I felt it was tying my hands. That was back in maven1 days and when all we were trying to use it for was to generate the web site for our freebXML Registry open source project .

Since then a lot has changed. Maven2 has been improved maven tremendously. But more importantly, I understand now, that maven is good for so much more in software projects than simply helping generate its web site.

By now, I have gone from being a skeptic to an avid evangelist for Maven. Nearly, all my projects (and there are many) are now on maven. Those that are not, at least provide their releases in a maven repository so other maven projects can use them easily.

I have often been in a situation where I am trying to use an open source project as a dependency in my project but that project's jars are not available in a maven repository. Maven provides a workaround for this but it is not convenient longer term.

Thus I have often had to beg a project to either transition to maven 2 (usually from ant) or at least make their releases available in a maven repository. To beg effectively, I have often had to write "why maven rocks" in many mailing list.

To make my "begging for maven support" even more effective I have just created the following wiki page summarizing the key benefits:

http://ebxmlrr.wiki.sourceforge.net/whymaven

This is very much a work in progress and your suggestions are greatly appreciated.
The wiki is not editable so please send me any suggestions for improvements as comments to this blog entry.

The better we make the wiki page the more effectively we can all get projects to adopt maven. Thank you for your support.

[Ann] ebXML RegRep Worldwide Webinar 2007

Here is a good opportunity for any one interested in catching up with the latest developments in the OASIS ebXML Registry and Repository (RegRep) standard (ISO 15000, parts 3 and 4). This is a world-wide webinar that includes the following information:

• Overview of ebXML RegRep
  
• Implementations and deployments of ebXML RegRep
  
• Diverse use cases for ebXML RegRep
• ebXML RegRep: The System of Record for SOA Governance
  
• A brief demonstration of ebXML RegRep
• Questions and Answers session
  

Registration Form:
https://www.gotomeeting.com/register/323859279

Other Details:
http://www.oasis-open.org/events/webinars/ebxml-2007.php

Here is a piece of FUD regarding ebXML registry that I simply had to respond to.

Sadly, Anne once again shows a complete and utter bias towards UDDI and against ebXML Registry in this interview.

When asked "Are there any competing technologies?" she gives an example of a recent IBM product and does not even mention ebXML Registry which is an approved ISO standard and has been around for seven years. This is quite deliberate and not a simple oversight. She is quite aware of ebXML Registry as based on numerous debates I have engaged with her on the subject.

When the interviewer asks:

"Now, isn't there an issue as to whether to use UDDI or ebXML?",

she gives a blanket dismissal without giving any facts to back up her blanket assertions:

"I don't think there's an issue at all. There's a spec out there called ebXML Registry, but nobody's using it."

Here are some hard facts that should dispel such FUD...

• ebXML Registry is not just "a spec out there". It is an approved ISO Standard. UDDI is not an ISO standard.
• ebXML Registry is being used by major governments such as US, Canada, Spain, Norway. In US it is powering the Department of Defense metadata registry as well as being used in Department of Education.
• ebXML Registry is being used by major world institutions like United Nations
• ebXML Registry has been adopted by entire vertical such as IHE and HL7 in healthcare, OGC in GIS, SDMX in statistics, GS1 (formerly RosettaNet) in supply chain
• ebXML Registry is the foundation for HL7 ESB product from IBM. Since IBM product was cited by Anne instead of ebXML Registry, and since IBM was a huge backer of UDDI, it begs the followingt questions:
• Why did IBM use ebXML Registry from the freebXML Registry open source project instead of their own UDDI registry?
• Why did IBM bother creating IBM WebSphere Registry and Repository product beyond their basic UDDI registry product?
  

• ebXML Regtistry is being used in products from Adobe and others

Many of above adoption instances are cited at:

<http://ebxmlrr.sourceforge.net/wiki/index.php/Showcase>

Note that above link shows adoption of one specific implementation of ebXML Registry called freebXML Registry opensource project. There are several other implementations of the standard whose deployments are not included in that link.

Most recently, the Open GIS Consortium chose ebXML Registry over UDDI:

<http://xml.coverpages.org/OGC-ebRIM-200701.html>

All of these successes have been based on a grassroots standard with zero funding. In contrast UDDI has been funded so well by a couple of large companies that when uddi.org disbanded the change left over in their coffers was US $24,000.

The following page compares UDDI and ebXML Registry:

<http://ebxmlrr.sourceforge.net/wiki/index.php/Overview/comparisonWithUDDI>

The following paper includes a feature comparison between the two at its end:

SOA Registry-Repository White Paper

A feature comparison matrix is also available here:

<http://ebxmlrr.sourceforge.net/tmp/Registry_Capability_Matrix.html>

In light of all this data, it is frankly astonishing for an industry analyst like Anne to assert that no one is using ebXML Registry.

It should be enough for UDDI proponents to simply make their case for why they think UDDI is such a good thing. Unfortunately they often tend to resort to FUD against ebXML Registry.

The UDDI TC suspended operations some time back. As mentioned in TC minutes:

<http://www.oasis-open.org/archives/uddi-spec/200611/msg00008.html>

"
It was agreed unanimously that we will suspend operation of the TC for six months from the publication of CR92, at which time we will consider whether there is any further need for the TC. It’s time to declare success!"

The ebXML Registry standard and TC in comparison is alive, well and seeing healthy adoption, both commercially and in opensource. We do not plan to declare "Mission accomplished" for a very long time.

On a very personal level, I have bet the farm on ebXML Registry by founding Wellfleet Software Corporarion, a startup dedicated to furthering ebXML Registry adoption and deployment world-wide. So far, the ebXML Registry business is booming.

New Beginnings, Same Passions

After seven happy years I am leaving Sun and starting a software consulting business.

It has been an amazing ride.

When I joined Sun, my main motivation was Java. I was the lead architect for the largest Java project at Hewlett Packard at the time, when to my dismay they decided as a corporation to get on the COM bandwagon. Does anyone even remember what COM was? Let me help you out: It was the Microsoft platform du jour back then. OLE! OLE!

So I thought, what better place to get my fill of Java, than at its headwaters at Sun's Java Software Division. I joined the J2EE group in 1999 and life has never been the same since. I have had the good fortune to learn from some of the best and brightest minds in the industry. For that, I will forever be grateful.

Some of you know of my love for the OASIS ebXML standards and in particular the ebXML Registry standard. My involvement with ebXML was quite accidental. In 2000, a colleague asked me for some help on a deliverable for an upcoming demo. I ended up building what was one of the very first ebXML Messaging Service implementations. One thing led to another and I ended up authoring the original proposed draft of the ebXML Registry specification, again quite by chance. Since then, I have been the editor of the specifications as they continue to evolve with the contributions of many talented people and companies. For more than six years now it is my passion and a labor of love.

Around the same time as we were producing ebXML Registry 2.0 standard, I had the opportunity to lead the Expert Group that delivered the Java API for XML Registries (JAXR) API within the Java Community Process (JCP). It was a happy day when the Expert Group completed its work in one year with a unanimous approval vote within the JCP.

When I implemented the very first ebXML Registry implementation, Sun generously donated the work to seed the freebXML Registry open source project at Source Forge. In 2001 while on a trip to Hong Kong, in collaboration with CECID, I helped launch freebXML.org, an initiative to build and deliver royalty-free open source ebXML implementations. This has been instrumental in fueling the adoption and success of ebXML. As the freebXML Registry project caught on, Sun decided to productize it as the Sun Service Registry product within Java Enterprise System 4. Other companies including IBM, Digital Artefacts and FGM decided to build products on freebXML Registry as well.

It is rewarding to see that today, Sun Service Registry is completing work on its second release and freebXML Registry is completing its sixth release. It is even more rewarding to see that freebXML Registry and its deritaives are in production deployments at many notable organizations such as the US Department of Defense, United Nations and National Institute of Standards and Technology (NIST). The Service Registry product was successfully monetizing an open source project well before the idea became popular at Sun. In fact, we took it a step before open source and a step after productization by creating a “community driven, collaborative development model” as shown below:

I think my move and its timing are very good for the ebXML Registry standard, freebXML Registry open source project, customers deploying this technology and even Sun. Let me explain...

The ebXML Registry standard is now 5 years old with version 3.0 approved as an OASIS standard. What the standard needs most now is many many more strategic deployments. With this move, I can aspire to be a “Johnny Appleseed” for the standard, and plant the seeds of many new deployments of the standard where ever there is demand.

Coincidently (well not really), the freebXML Registry project is also reaching a maturity milestone with the release of version 3.0-final1. This took 5 years of hard work by a very dedicated and talented open source team. The largest contingent of that team consists of my able team mates from the Sun Service Registry team. I will continue to lead the freebXML Registry project with my full passion, attention and vigor. With this move, the project will gain more diversity of membership, broader industry deployments and participation.

Sun gains yet another independent and ardent evangelist for Java, Java EE, Java Enterprise System and Sun Service Registry. I am a believer in the Service Registry product and will be helping customers deploy it to its maximum potential.

Customers of freebXML Registry and Sun Service Registry will now be able to get the help they need to realize well-governed SOA deployments and secure, federated information management using these ebXML Registry technologies.

Finally, this move scratches a long-standing itch for me personally. My heart has always been in customer-focused deployments. This move creates the perfect opportunity for me to scratch that itch.

Even though the timing is right for me to take on new challenges, leaving Sun is not so easy. What I will miss most are the good friends, colleagues and mentors at Sun and the culture of innovation and leading edge technology.

Looking forward, I hope to work with many of you who share this vision of collaborative, community-driven, open-source software development for the common good of this blessed Earth.