ESME Blog

In my last blog, I mentioned my tests with the Stax.net cloud as hosting opportunity for ESME.  Well, after fighting various issues dealing with proxies and request timeouts,  I finally got ESME installed at Stax, then logged in via OpenID and posted my first cloud-based ESME message.

I really think the Stax environment is great once you get the hang of it.

To get ESME working, I used the sample application from Stax and then copied the files from the ESME war file from the Google Code site. I copied all the esme files into the “webapp” directory and then did a “stax deploy” command to load it all up into the Stax system.  I had to make some adjustments to the ant build file for the Stax deployment, because I have a limitation on the size of files that I can send via HTTP ( Therefore, the source code currently available in Stax is missing all the Jar files.)  Besides that problem, everything worked out well.

I also was able to use the cloud-database in the Stax environment rather than the existing Derby implementation. If you wanted to use a remote DB (for example, behind the firewall), you just have to change the details.

I just added the following snippet to the web.xml file:

<resource-ref>
<res-ref-name>esme</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

and the following snippet to the stax-application.xml

<resource name=”esme” auth=”Container” type=”javax.sql.DataSource”>
<param name=”username” value=”esme_2″ />
<param name=”password” value=”xxx” /> [password is hidden for this blog]
<param name=”url” value=”jdbc:stax://esme” />
</resource>

Now, that ESME is installed, it is possible to perform operations-related tasks -all from my browser.

Still open

• There are still exceptions dealing with file-based activities.  For example. the search interface via Compass currently doesn’t work, because it uses file. These have to be changed as well to have a fully functional application.
• It would be cool to be able to clone this application(including database)  for others.
• It would be useful to have the ability to restrict access to particular IP addresses (maybe, this is a function for which Stax could charge?)

I’m been playing with Stax -  “the fastest way for developers to build, manage and scale Java applications on EC2″ as a means to get ESME into the cloud. I’ve already created an example application (not ESME) based on the standard functionality and am now exploring the environment to get ESME up and running. Currently, the main problem is associated with the fact that ESME uses a local Apache Derby database for test purposes. One requirement on Stax is that local files can’t be created, so I have to use a JDBC data-source to a DB hosted in the Amazon cloud or somewhere else. I’ve created a database in the Amazon cloud (via Stax – real easy by the way -) and am now looking at configuring ESME to use this database. Once this step is done, the next step/scenario would be to use a remote database. This is an interesting scenario that I’ve discussed in another blog about architectural patterns which describes the possibility of a ESME server that  is cloud-based but the database is in the DMZ behind the firewall.  This pattern is interesting, because corporations often have problems with cloud-based installations, because the data is usually not under their control. There may be performance problems associated with such a pattern but this is something that might be able to be lessened via hardware and/or network-related measures.

Once we get the ESME server up and running, I’ll post another blog with our experiences.

I just created a Zoho Creator application that creates ESME messages. The application includes a very rudimentary UI to create the message. I’ve made the application public so that everyone can test it.

Note: Please remember that currently, the information entered in the form is also be stored in the internal application database so that anyone can see the tokens that are being used. It would be pretty easy to add  a small routine to the script to delete the data after it has been sent to ESME.

The code to create the esme message is very simple and is linked to the submit button.

MyMap = map(); Response = postUrl(”http://api.esme.us/esme/api/login?token=” + input.Token, MyMap);

Response = postUrl(”http://api.esme.us/esme/api/send_msg?message=” + input.Message + “&tags=” + input.Tags + “&via=zoho”, MyMap);

Response = getUrl(”http://api.esme.us/esme/api/logout“);

What is cool is that there is also the possibility to use the “out-of-the-box” functionality of ZohoCreator applications to import information from Excel to fill internal database tables.  Thus, you can rapidly create a series of ESME messages. The first ESME spammer is born.

Why is the integration interesting:  Zoho has a series of business applications (CRM, Invoice, etc.) where it might be relatively easy to integrate ESME and micro-blogging into this environment.  I could imagine interesting scenarios where a company has some applications hosted by Zoho and some internally – ESME could act as a information bridge between both environments.

ESME (Enterprise Social Messaging Experiment) has been officially accepted into the prestigious Apache Incubator – http://incubator.apache.org/projects/esme.html.

ESME is a microblogging tool and community project which originated in conversations amongst members of the SAP Community, moved to Google Code, and was the first submission in the history of SAP TechEds which was present at all three Demo Jams (Las Vegas, Berlin and Bangalore) in one year.

The Apache Incubator is the entry path into The Apache Software Foundation (ASF) for projects and codebases wishing to become part of the Foundation’s efforts. All code donations from external organizations and existing external projects wishing to join Apache enter through the Incubator. The Apache Software Foundation (ASF) provides organizational, legal, and financial support for a broad range of open source software projects. The Foundation provides an established framework for intellectual property and financial contributions that simultaneously limits contributors potential legal exposure.

Apache projects are considered the top open-source projects and many of have become standards in software development (Tomcat, Struts, etc.)

Why the inclusion of ESME in the Apache Incubator is ImportantAs I described in my last blog about innovation and the SCN community, I’d like to suggest that the evolution of ESME proves that the potential of the SCN community lies in looking beyond borders of the community itself and must include the experience gained from other communities in order to evolve itself. Although I am very much an Apache novice, I’ve been fascinated by the processes and policies that are present in this organization. For example, there is much that we (SCN) can learn from how Apache deals with IP-related issues. This cross-pollination is especially relevant based on the various open-source-related discussions occurring in background in the SCN.

 As SAP’s participation (including Senior Vice President of the SAP Community Network Mark Yolton) in the Open Source Meets Business (OSMB) Congress demonstrates, there is an increasing awareness that the relationship of corporations to open-source software should be more than just as consumers but also as contributors. This changing role requires a great deal of re-thinking in terms of corporate policies (legal, organizational, etc.); thus, the experience of the ESME team (many of whom are SAP mentors) in Apache will flow back into our involvement with the SCN as well as assist our respective corporations to deal with this new opportunity.

Note: This blog was also posted on the SDN.