[Crossposted from my JackBe blog]

Today is an exciting day for us at JackBe. It is particularly exciting for our engineering team. Why? Walk down the memory lane with me for a minute…

About 3 years ago, we embarked on a mission to create a new kind of software which today we call an ‘enterprise mashup platform’. And as we started designing JackBe’s enterprise mashup platform (which we ultimately named ‘Presto‘), we knew the basic problem we needed to address was how to make data securely and easily accessible to enterprise users.

That’s not an easy problem, of course. ‘Easy’ and ’secure’ aren’t often associated with each other. And enterprises are typically heterogeneous collections of data sources, data security solutions, data destinations; web services, portals, databases, spreadsheets, and much, much more. And as we considered the many different options we had to tackle this complex problem, we always came back to one fundamental concept that has proven its worth time and again:

A language is the best tool one can have.

So began our journey towards an ‘Enterprise Mashup Markup Language’ (EMML), a language specifically designed to address the needs of creating and sharing mashups within the enterprise. In conceiving, designing and implementing the language, Raj (our chief architect) and I set out defining the key wants and desires and came up with the following criteria as a basis for EMML:

1. It should be declarative. So we made it XML-based.
2. It should leverage existing standards. So we used XPath and XQuery.
3. It should be domain specific to enterprise mashups. So we added features for user oriented activities.
4. It should be friendly to popular languages. So we allow the embed of Java, JavaScript, Ruby, and Groovy scripts.
5. It should be tooling friendly. So we made it interpretive for construction and execution on the fly. And extensible with your own meta-data.
6. It should be data neutral. So we made it work with all kinds of data from different sources.

While I will refrain from describing the complete language in this blog (instead refer you to the excellent documentation on EMML on the Open Mashup Alliance website), I would like to point out a few key features of EMML here using the following diagram:

As you can see, from each feature, and from the collection of all the features EMML offers, it a robust and powerful language for mashups. And over the last few years, EMML has become an important differentiator for Presto, our award winning Enterprise Mashup Platform. As part of Presto, since its debut, EMML has been thoroughly field-tested and proven. It is time to take EMML to the next level.So now let’s return to the present and let me tell you why it is so exciting for all of us here at JackBe.

Today we launched the Open Mashup Alliance (OMA) to promote and foster interoperability and portability through an open mashup language. As a founding member of OMA, JackBe has contributed EMML to the Alliance and, indirectly, to the entire mashup community. Joining us (see this, this and this)are other industry leaders such as Adobe, Bank of America, Capgemini, Hinchcliffe & Co., HP, Intel, Kapow Technologies, Programmable Web, Synteractive, and Xignite.

So why I am so excited about giving away our vision and our hard work? Why would we want to give away one of our crown jewels? Because…

1. It offers an opportunity for our industry to converge upon an open language that aids interoperability and portability of enterprise mashups.
2. I believe that OMA offers a huge potential in enabling enterprise mashup adoption in the enterprise by promoting standard approaches and reducing risk and cost.
3. As a practitioner, I strongly believe in open and standards based approaches for new and emerging technologies and for enterprise mashups, OMA and EMML are it.
4. By contributing EMML to OMA, we will see a lot more innovation in this space by the members of the mashup community.
5. I look forward to working with other industry leaders who want to collaborate to ensure portability and interoperability for enterprise mashups.

Why should you care? I hope many of the above reasons are also the relevant reasons for you. As a vendor or a practitioner, I hope you share the excitement and passion for openness and collaboration in any technology. Check out what several industry leaders are saying about OMA and EMML and you will get a sense of why I am so thrilled.

As the enterprise mashup market evolves further, OMA will provide a platform to bring together different efforts around enterprise mashups into a collaborative alliance. If you are a mashup developer, programmer, IT developer, IT Manager, software vendor, or someone simply interested in enterprise mashups, join the OMA Support Group, check out OMA website and download EMML reference implementation and start participating now.

This is just the start of things to come.
Mash On!

A picture is worth a thousand words they say. So, without much ado, here it is… having been with Java since the beginning, here is how I feel about it now.
And to justify with some concrete evidence, here is the page count from the Java In A Nutshell book that was one of my most beloved Java books in the last decade. Not anymore, the friggin book is 1252 pages!

• 1st Edition: 460 pages
• 2nd Edition: 628 pages
• 3rd Edition: 720 pages
• 4th Edition: 992 pages
• 5th Edition: 1252 pages

Hell, it should be renamed to “Java in a Coconut Shell”. And I am just talking about core of Java here, not all the other extensions around it. Because there are spawns of Nutshell books like “Java Enterprise in a Nutshell” and what not.

PS: Apologies to those who came here looking for some philosophical/technical discussion about how I really feel about Java.

Java Humor

As I mentioned in my earlier post, I spend some of my time on building a rich UI application using Swing. And when it came to choosing a mechanism to store my user preferences, I decided to not use property files which was how I had stored preferences before. But, now (since Java 1.4) I use the java.util.Preferences API to store and retrieve my preferences. I would not store sensitive information in preferences, but for non-sensitive info, Preferences API is a great way to persist and manage them. The reason I am posting this is that while talking to some of my friends I realized that not many were aware of the Preferences API despite it being around for a while now. Perhaps because most of us have been focussed on server-side software where we have many other options to store preferences such as JNDI registry or a centralized configuration management system. Anyway, if you are building a stand-alone Java application or a rich client and have a need to store user preferences, take a look at the Preferences API. I think it is a cool API.

Some references:

• Preferences API
• Preferences FAQ
• ONJava Article on Preferences API

Java Programming

It shouldn‘t be this wicked. Ok, I admit it has been a while since I implemented
a Java RMI based
client/server. But, it shouldn‘t be this wicked. So, I was trying to get some
RMI client/server code running on my machine. And I kept getting was this friggin
exception:

Caused by: javax.naming.CommunicationException [Root exception is java.rmi.ServerException:
RemoteException occurred in server thread;
nested exception is: java.rmi.UnmarshalException: error unmarshalling arguments;
nested exception is: java.lang.ClassNotFoundException: com.sun.salsa.PatternModelImpl_Stub

The RMI docs said that anytime you get a ClassNotFoundException, it
is most likely caused by an improperly set codebase^[J] So I checked
the value of my java.rmi.server.CodeBase property. It was set as follows:

java.rmi.server.CodeBase=file://dev/salsa/classes 

I checked to make sure that the directory was there and that all the stubs
and other classes were in there. They were. So, I ran the RMI server program
again. But, again I got the same exception. What the heck is going on? And then
it hit me. Isn‘t that supposed to be codebase and not CodeBase?

So I change "CodeBase" to "codebase" and reset the property
as follows:

java.rmi.server.codebase=file://dev/salsa/classes 

And give the program another try. This time, I got a different exception.

Exception in thread "main" java.security.AccessControlException:
access denied (java.io.FilePermission //dev/salsa/classes read)
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
at java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
... 

Hmm…this looks like we need some permissions granted. That‘s easy, let me go
the $JRE/lib/security directory and change the java.policy file
and add a new grant permission and it should all be fine. So I edit the
java.policy file and add the grant permission:

grant codeBase "file://dev/salsa/classes" {
permission java.io.FilePermission ">", "read";
};

I run the program thinking I fixed the problem for good. But not so fast! I
see the same exception again. Then it hit me again. I had committed another
silly error. It appears that I gave 2 slashes (file://...) to the codebase
to separate the protocol and the url.

So I quickly undo the changes I made to the java.policy file.
I go back to the codebase property and this time I set it as follows:

java.rmi.server.codebase=file:/dev/salsa/classes

I restart my RMI server and voila! Everything works fine this time!

Thought this record of my silly errors might help someone else sometime.

_{[J] Thanks to Jeremy Pitten
for reminding me the codebase settings.}

RMI Java Programming

Over the years, I have worked on and off on rich user interfaces. Recently, I have been pluggin away at a Swing UI for a cool project called SALSA that I will write about some other time. If you have ever used the Swing GridBag layout, I am sure you will identify with this cool Flash animated weblog by Matt Quail. I sure do.
So for many years, I have struggled with GridBag everytime I use it.

But ever since Netbeans 4 was released, I have been liberated of this curse of the GridBag. NetBeans makes Swing development fast and easy and no more messing around with gridbag constraints, layout issues, etc. (unless you like to).
As part of my customer facing job, I have used all the Java IDEs out there. But for me, when it comes to Swing in specific, and Java in general, nothing beats the new Netbeans!

I Love NetBeans! Thanks, Netbeans team!

Check it out!