[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!

Must save this forever!

I just got this on my twitter account.

Hi, deepakalur (deepakalur).

Gov Schwarzenegger (schwarzenegger) is now following your updates on Twitter.

Check out Gov Schwarzenegger’s profile here:

http://twitter.com/schwarzenegger

Best,

Twitter

[Cross-posted from JackBe blog]

I am big fan of Ed Yourdon. So, I was delighted to see his presentation on Mashups (here). Discussion on this topic by eminent and experienced gurus like him are heart warming and encouraging to me, since we at JackBe, have been working in the area of Mashups to create a new kind of lite-middleware. I and my colleagues have often written about our work (for instance here and here).

What was not so encouraging to me personally was the fact that Presto, our enterprise mashup platform from JackBe, did not figure in his presentation. Which got me thinking, no surprise really, there must be a whole lot of people that might not know or heard about us since we are such a small company compared to the likes of Google, Yahoo, IBM and Microsoft, which were featured mentions in his presentation.

So, to those, I would also like to take this opportunity to introduce our company, JackBe and our product Presto, which is a pure play enterprise mashup server platform built from the ground up for enterprise mashing! At the core of this is our Enterprise Mashup Markup Language (EMML), which we describe as a domain specific language for mashups. No other product or technology offers such a DSL for mashing, which has been greatly appreciated by our users and customers. Do check it out yourself and let me know what you think.

We also offer Presto to developers in a special developer edition to the community. The Mashup Developer Community (MDC) members can download and use Presto for free here (requires registration).

In Ed Yourdon’s presentation, he mentions Yahoo! Pipes, MS Popfly, etc. Some have described Presto as Yahoo! Pipes on steroids for the enterprise, since Presto’s visual mashup composer called Wires allows you to create mashups that consume any kind of service / API including WSDL, REST, RSS, Atom, Databases, Excel spreadsheets and so forth. Pipes only deals with public RSS services as far as I know.

Presto also generates Mashlets, which puts a face (UI) in front of each mashup. Mashlets become the embeddable objects that can virally spread within and outside the enterprise (assuming the enteprise security policies allow them to share outside). All of this is done in a secure manner, which is why we are an enterprise mashup solution.

To better understand Presto at a high level, I had previously described the 3 artifacts of mashup process here. I hope this provides you some insight into our technology, and hopefully, you will get to try it when you get a chance. While doing so, if you do need any help, don’t be shy to ask on MDC, the whole community is there to help!

Mash On!

I came across this interesting post: How Mashups Could Eliminate Integration Projects by Loraine Lawson. In a related post, she refers to John Crupi’s article Enterprise Mashups Part I: Bringing SOA to the People which I would recommend to readers who want to understand JackBe’s take on defining mashups. Anyway, Loraine’s post led me to Ron Schmelzer’s ZapFlash.

Here are some excerpts of Ron’s article that caught my eye, with my take on it:

A year or two ago, assuming that a mashup was a web browser-based, static, user interface composition of web-based functionality would be a reasonable presumption. But in the enterprise context, none of those assumptions necessarily hold – we might want non-Web access to mashed applications, we might want to change them regularly, and we might want to mash up information that exists below the user interface abstraction. For sure, Web mashups might embody the ideals of the original mashup concept, but we now have the desire to mash up a wide variety of IT resources from application to infrastructure to data that might be exposed with a wide range of interfaces – or without. And, it’s the desire to mash up information freed from the application that diversifies the mashup term to include the concept of the data mashup.

Introducing the Mashup Tier

My take: This hits the point right on what we at JackBe have been saying all along about mashups. While some mashups are done purely in the UI/Browser, in the enterprise, such mashups need to be supported by a new tier, the mashup tier, which sits between the presentation and business tier. So enterprise mashups will have some mashing done in the client, but most of the mashing happens in server side where security, governance, policies can be applied before any mashing can happen in the client.

Another excerpt:

There are many scenarios for composing data, but some are better suited for static, tightly-coupled, IT-driven, non-Service Oriented form. In fact, 80% of the value that businesses derive from data come from the 20% of fixed, highly optimized data integration approaches implemented over decades. In this realm, traditional data integration approaches retain high value. However, it’s the other 80% of data integration requirements, most of which come from the need to meet short-term, often ad hoc, integration requests that cause 80% of the problems. Anyone who has lived long enough in the enterprise IT space knows that business-driven requests for reporting, forecasting, analysis, or other interpretations of data can present significant complications and cost to the IT organization. The reason for this is that the IT organization is set up to meet the recurring needs of the business and not “situational” needs for information.

Long Tail of Enterprise Software Demand

My take: This highlights another issue which we have been talking about at JackBe about the long tail & enterprise applications need which was so nicely discussed here by Dion Hinchcliffe.

Bottom line: Something new and interesting is happening in the enterprise architecture space. A new flexible and agile tier is being introduced in the architecture to meet the increasing demand on IT and  add value to existing architecture, applications, services and data. Question is, are you embracing this inevitable change? If not, it’s still not too late.

Session: Enterprise Mashups / Presenter: Kishore Subramanian, JackBe

[ Disclaimer: I work for JackBe ] There are about 30 attendees. Kishore is going over the concepts behind our mashup approach like mashables, mashups, and shareables.

Kishore demonstrating SalesForce mashups and walking through the internals including EMML code. Talking about how you can merge data from SalesForce with data from internal proprietary data source and merge/combine to produce a mashup (virtual) service. Showing how to invoke it as a REST interface, which makes it easier to use a complex/mashup service. Now showing how to make a Mashlet using MashletMaker and sharing the mashlet. Now he is demo’ing Wires to show how to visually mashup by drag, drop and connect.

Got some interesting questions. Here are a few:

• Question: Is it Free?
  Answer: Yes, it is for developers. Get it here.
• Question: Is it Open Source?
  Answer: No. Did I mention it is free? JackBe is partnering with enterprise software vendors and developers to open up the EMML language. Please contact me (deepak dot alur at jackbe dot com) to get involved, support EMML or for more information.
• Question: We got a great question from a guy from the Yahoo Pipes team (I think I heard it this way) -
  Do you guys have the same problem as we do in that you need a programming language underneath?
  Answer: Yes, absolutely. We solve it by providing our Enterprise Mashup Markup Language (EMML) which has integration with different languages allowing you to plug in your program in Java, JavaScript, Ruby, Groovy. EMML and such integrated script will run on the server side dynamically.
• Question: Can you offer a hosted version for developers to use? I am not going to download this. Would like to play before I download.
  Answer: Thanks for the feedback. We are looking into it.
• Question: I am a developer. Can I run and host Presto for personal use ? What about if I am a non-profit?
  Answer: Contact me at deepak dot alur at jackbe dot com.

Get the Free Developer Edition of Presto here.

Session: Working with Sharepoint Data @ SV Code Camp / Presenter: Joseph Ackerman, Senior Consultant with Allin Corp. MS Partner

Things I heard (caution: I am not a Sharepoint user or developer):

• Sharepoint development is not fun. 80% audience (~30 prople) raise hands as sharepoint users.
• Had never heard of CAML until now…CAML=Collaborative Application Markup Language
• Sharepoint woefully under-documented for developers, getting better but right now it sucks.
• Though built on top of ASP.net 2.0, SQL Server, Sharepoint has lots of differences. E.g. cannot do the way you are used to doing it with those stuff.
• Biggest difference is working with data. Everything is a list. Lists =  Tables. Fields = Columns. Rows = ListItems. Lists have more metadata. Less flexible (e.g. joins are difficult or impossible). Lots of things to stitch together.
• You get a Context object to work with anything in Sharepoint (e.g. SPContext.Current.Site). Sites have webs. Web has a collection of Lists. List has 1-n views.
• Sharepoint / Web Parts is impossible to debug – use the famous println approach.

After this conceptual discussion, I am lost in all the XML files, C# and other code shown on screen (probably because I am not a SharePoint developer).

My Rating: Presenter was really good. But not so sure about Sharepoint itself. After attending, I did not come away with “Holy Macro! I need to get my hands on Sharepoint and try this out!”.

Session Wiki here | Slides here

[Cross posted from Mashup Developer Community]

How exactly does the mashup process work? What does Presto really do? These are a couple of common newbie questions. I have had different explanations for this, but of late, I have narrowed down on the following elevator pitch (trust me, this textual explanation looks long, but I can explain really fast in person) that I have used successfully with other developers recently. So I thought I will share this with the community in case it helps others to understand the process and artifacts around enterprise mashups.

I found it easier to explain the whole mashup workflow using three terms: Mashables, Mashups and Shareables (OK, I confess, these may not be in the English Dictionary yet ).

As a mashup developer or user, we need to start somewhere. To me that starting point is what I call Mashables. These are things that one can use, invoke to get data and send data. Things like services such as WSDL based web services, REST based web services,  RSS or Atom services, proprietary XML/RPC services, or even the conventional RDBMS tables, view and stored procedures. I would also include other items such as spreadsheets, XML documents and unstructured information on internal and external websites. These are the raw material for mashups. These need to be made Mashable! And this is exactly what happens when you ‘publish’ one of these things to Presto. It becomes a Mashable artifact that can be normalized, secured and managed.

And then comes the second thing called Mashups. I don’t want to go into a philosophical discussion about what a mashup is or isn’t. However, I think mashup is a user-driven, user-focused thing that encapsulates the kind of data processing and manipulation actions a user would normally do to turn any data into real information. Such actions include joining, merging, sorting, filtering, constructing, transforming, clipping, and so forth. And in Presto, a mashup is represented by an small file written using EMML (EMML is Enterprise Mashup Markup Language). EMML is an XML-based dynamic declarative domain specific mashup language. Again, a Mashup becomes this artifact which can be secured and managed just like the Mashables.

The third and final thing is the Shareables. Once you have Mashables, and Mashups, you want to be able to share them with co-workers, partners, friends, whoever. Shareables can be exposed as a service interface so others can use it as a REST or RSS or Atom or WSDL service. Another popular type of Shareable is what we call Mashlets, which are enterprise widgets that offer a rich interface to the Mashups. Mashlets are not full blown applicaitons, but can be small micro-applications that encapsulate a very specific functionality. Mashlets can be shared by publishing them on Wiki pages, blogs, websites, portal servers. You can even email a mashlet or call it directly from a smart phone like iPhone. Other types of shareables include mashups and services shared as REST urls, RSS feeds, data feeds, spreadsheets, email and so on.

There you have it. Now I can just describe Presto simply as a platform to securely create, publish, consume and collaborate with Mashables, Mashups, and Shareables !

Let me know what you think.

A few days ago, we released the complete Presto Enterprise Mashup Platform for all mashup developers to use free: Click here for more details and to download it. Enjoy!

Works With
JackBe Presto is bundled with and runs on the popular Apache Tomcat server out of the box when you download and install it. But as a pure Java application, Presto is designed to run on any standard compliant J2EE application server that has JSP/Servlet support.

I wanted to deploy Presto on Sun’s open source J2EE application server, GlassFish, since a few of our friends at Sun were interested. If you are new to GlassFish, it is the name for the open source project for building a Java EE 5 application server sponsored by Sun & Oracle (more details here).

The process of deployment was very easy. If you have downloaded and installed Presto, it is easy to locate the Presto war files that represent different Presto capabilities and deploy them using the GlassFish administration console or the command line asadmin utillity that comes with the GlassFish installation. With just a click of a few buttons, the following Presto components were deployed on GlassFish:

• Presto Edge Enterprise Mashup Server with Service Explorer and Administration Console applications for managing Edge
• Dash, our user driven dynamic desktop application
• Sample applications to show mashup examples and data binding examples

That and an evaluation license key you get when you download our software is all you need to run Presto on GlassFish. Kudos to our development team for a great job in maintaining standard compliance and pure Java in our code. Pretty cool!

[Cross-posted from http://blogs.jackbe.com]

In my last blog entry, I defined what I mean by a mashup. In this entry, I want to expand upon how I think mashups differ in the enterprise compared to some of the consumer mashups out there.

I mentioned in my earlier post that mashups based on maps are ubiquitous and something that the users can immediately grasp. But, once you step inside an enterprise, things can be a lot different for mashups. Enterprises are not greatly interested in map-based mashups, neither are they interested in RSS or ATOM services which I think are still not fully leveraged inside an enterprise. Over the past few years, enterprises have invested heavily in SOA and because of that, they are just about getting done with service orienting their enterprise with Web Services (primarily using WSDL). And there are many applications in the enterprise that are still very database oriented. It has become relatively easy for an IT developer to expose services as WSDL based web service. And almost every middleware product out there in the enterprise is capable of exposing services via WSDL or makes it really easy to do so. Hence if you start looking around in an enterprise, what you will find is what I call the Service Cloud.

So what you have in an enterprise is a cloud of services where some are WSDL based, some are REST based, some or XML/HTTP, some are database objects, and so forth. Now, the real challenge is how to mashup these disparate kinds of services, with different service contracts and data formats. Any respectable enterprise platform that offers to mashup services in the enterprise must negotiate these disparate contracts these services expose (e.g. while a WSDL based web service defines a service contract in a WSDL document, a REST based web service has no such contact definition). And not only that, it must be done so that that we can make it easy to access for developers and users alike, and to be able to do that securely and with high-performance and scalability. Some enterprises might regulate the service consumption of even public web services that most of us can freely access on the net (think of the ubiquitous RSS feeds for example). Enterprises might allow consumption of these services, but would like to do so with governance underneath to manage, monitor and secure such activity within the enterprise. This is why we built our enterprise mashup platform at JackBe from the ground up, to address the unique challenges of mashing in the enterprise so that we allow our users to do the following:

• Create and customize mashups that consume all kinds of services: RSS, ATOM, WSDL, REST, DB, SDO, Java Objects, etc.
• Securely govern the mashups: policies for who can mashup, what can they mashup
• Share the mashups to collaborate in the enterprise

My colleague John Crupi wrote about enterprise mashups becoming the new front-tier in the enterprise. I would like comment a bit on what he said in his post. While SOA efforts have been IT driven and IT oriented, even with involvement by the business units, the outcome has been primarily IT and developer focussed. It has neglected an important stakeholder in the enterprise, and that is the User. Therefore, I view the new enterprise mashup layer as a new service layer in the enterprise application architecture that finally begins to leverage SOA from the end user perspective and to make the services layer more user-friendly (and developer-friendly) to build, deploy, share the next-generation enterprise web 2.0 mashup applications.

What do you think?