Wednesday, December 1, 2010

Rails Sample App Status

Oh well, it seems the restful authentication is incompatible with my version of ruby. I think it requires rails 2.1? At any rate, going to install rvm to see if I can play with the ruby versions and get it to work.

I am using:

balexander@ubuntu001:~/SampleApp$ gem environment

RubyGems Environment:
- RUBYGEMS VERSION: 1.3.5
- RUBY VERSION: 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
- INSTALLATION DIRECTORY: /var/lib/gems/1.8
- RUBY EXECUTABLE: /usr/bin/ruby1.8
- EXECUTABLE DIRECTORY: /var/lib/gems/1.8/bin
- RUBYGEMS PLATFORMS:
- ruby
- x86_64-linux
- GEM PATHS:
- /var/lib/gems/1.8
- /home/balexander/.gem/ruby/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- "gem" => "--http-proxy http://XXXX"
- :sources => ["http://gems.rubyforge.org", "http://gems.github.com"]
- REMOTE SOURCES:
- http://gems.rubyforge.org
- http://gems.github.com

balexander@ubuntu001:~/SampleApp$ script/console development
Loading development environment (Rails 2.2.3)

Monday, November 29, 2010

Rails Sample App Status

I got the sample rails movie application running and am now working on integrating the restful-authentication plugin from technoweenie on github.

Setting up proxy to pull the source from Git was somewhat of a pain though, git config --global http.proxy user:pw@hostname:port is your friend in this case.

Thursday, November 18, 2010

1st Baby Step Toward RESTful Authentication

Installed rails today and going to work through the "Getting Started With Restful Authentication in Rails" tutorial.

Installing rails on Ubuntu is brain dead simple:

sudo apt-get install rails



Wednesday, November 17, 2010

Setting Up A REST User Sign-In Service

I wanted to document my progress (both success and failures) in setting up a RESTful service to authenticate users and store user preferences in a Hadoop data store. There is will several attempts at this I think because there are already plenty of examples and sample code out there which to try. I know of solutions using Ruby on Rails and Grails. But none that I know of that use Hadoop as the underlying data store.

I started my exercise by choosing a development platform OS. I chose Ubuntu Server because it is free, well supported and it has enterprise cloud support (more on that later). I am using a virtual machine to install Ubuntu using Oracle's VirtualBox.

At first I used the latest and greatest version of Ubuntu Server 10.10. This turned out to be a false start as I had some install issues with Hadoop. Hadoop 0.20 is only supported up to the lucid, 10.04 version of Ubuntu. I found this link to be quite useful in getting me setup correctly. People say Cassandra is better, but I will stick with Cloudera's distribution of Hadoop and HBase for now. I used the "pseudo distributed" package.

So at this point I have Hadoop-0.20 installed on Ubuntu Server 10.04 Enterprise Cloud. My next step is to trial Grails to setup a basic user authentication REST service using Hadoop.

Monday, April 12, 2010

Mule Summit Overview - Part II Digging Deeper

Following up from last weeks post on my first impressions of Mule Summit in San Francisco, I wanted to cover the major areas covered at the conference a little deeper. I will try not to regurgitate their marketing pitch, but offer my insight on why a certain feature would be beneficial of better than another solution.

The Mule Summit presentations are available and can be accessed with username: Summit2010, password Summit2010.

Mule 3.0 Preview

Mateo Amenta, Mulesource ESB Product Manager presented a preview of new features in Mule 3.0. The main objective of Mule 3.0 offered by Mateo was "simplification". I can certainly appreciate that. I have worked with the current 2.0 version and while I can say it is no more complicated than say working with Spring or any other XML driven configuration, it can a bit daunting to the novice. I am much more a fan of "convention over configuration", but that's another topic entirely and that is not the type of simplification Mule had in mind for 3.0 of their ESB product.

One area of simplification introduced in Mule ESB 3.0 relates to "Web Middleware", which was explained as light weight, cloud oriented and distributed. This is a new definition of the traditional ESB which was typically a central hub, usually running on "big iron" from a legacy vendor provider. The traditional ESB software suite usually consisted of numerous packages and modules that required extensive "carnal" knowledge of install, configure and develop against. Been there, done that.

One thing I like about Mule is you can just take the pieces you want and install, configure and deploy. You can start with the Community Edition (CE) and upgrade when you are ready. You can add HA or Mule MQ when and if you need it later. You don't need to buy the whole stack.

Another simplification feature touted in Mule was using Java Domain Specific Languages (DSL) and XML Views. They didn't actually show how DSL was implemented in Mule, but they did demo some use of XML views. It does indeed reduce the verboseness of Mule XML configuration. I googled around XML Views and in and of themselves (outside of Mule) look intriguing.

Another feature added to Mule 3.0 was support for annotations, specifically support for Google Guice. Reading over the specifics of Guice on Google's site does strongly suggest it would offer a more lightweith alternative to dependency injection (DI) using Spring. Guice might also offer supplement to lcfg.

Web Transports in Mule


Mule 3.0 will support Ajax transports and JSON and JAXB data bindings. This supports the movement towards HTTP clients as a common integration point to an organization's data services. Also to be supported is RESTPack integration using JAXRS, ATOM and RSS.

jBPM Transport

One of the non-core benefits of an open source ESB is support for long running processes/state engines that can handle business processes and choreography. I don't know much about jBPM, but what I gleamed from the brief overview at the Mule Summit and my own Googling, it seems promising.

Other Transport Honorable Mentions...

XMPP - The chat protocol

WS-Security, SAML (single sign on) 1.1b via CXF

wss4j 1.5.8

Mule MQ

One thing that really perked me up during the conference was the talk on Mule MQ. This is Mulesoft's message queue offering which complete obviously with IBM Websphere MQ and open source equivalent Active MQ. One claim by the Mulesoft guys is that Mule MQ is "Independently benchmarked as the fastest messaging product on the market."

They listed some bif financial houses that use Mule MQ and FX transactions. Which on the surface anyway would seem to be impressive since financial transactions are very demanding in terms of availability, robustness and reliability.

The Mule MQ Enterprise Manager looked pretty cool. It seemed to give much more monitoring information than what I am used to seeing from IBM MQ Explorer. For troubleshooting and diagnostics, it seems like it would be very useful.

The performance statistics presented were a comparison with Active MQ. Queue performance was about 2x for Mule MQ versus Active MQ. I would like to do a similar comparison with IBM MQ. I am hoping to get a hold of their test setup so I can compare with IBM MQ. Topics were even faster with publish and subscribe being about 4 times faster than Active MQ.

Another possible financial benefit of Mule MQ is that is is not licensed based on number of processors. I don't know how that compares with IBM's licensing for Websphere MQ but it would be something to look into further.

High Availability for Mule

For a messaging system, high availability is crucial. Specifically, any enterprise level messaging system must provide failover and uninterrupted processing of in-flight messages. Mule ESB 2.2 supports active-passive failover using shared state of cluster transport and cluster service.

Mule ESB also supports active/active HA. From what I could gather, it accomplishes this using SEDA (staged event-driven architecture) shared state, in memory queues. In Mule, this equates to the VM transport which is their internal, native transport mechanism. There was also talk of some kind of partnership with Gigaspaces to achieve HA. I will look more into this.

A configuration that was presented being used at CIGNA, was an active/active (2 node) cluster of 2 Mule ESB instances running on one host with one MQ instance. This configuration is repeated on another host:

F5 Big IP

Host 1 Host 2
Mule 1 Mule 1
Mule 2 Mule 2
MQ MQ

This setup is somewhat similar to configurations that I am familar with using IBM Websphere Message Broker and IBM MQ where you can have multiple broker instances shared on a single MQ instance and have a cluster of brokers.

Glu

One surprise development from the Mule Summit which also got me excited was Glu. In particular, was the fact that Glu is a new open source project that can be used stand alone outside of Mule ESB. From their slide deck, here is how they describe Glu: "Framework to simply build integration resources"

Glu is RESTful providing a common interface for all HTTP enabled clients (Java, JS, Groovy, Ruby, Python, Perl, PHP, etc). From the looks of the sample code, it looks very "convention over configuration" like. The claims of ease of use and a common store for RESTful components causes me to want to investigate this more. It seems kind of too good to be true, but I am willing to see how far it goes in matching claims.

Friday, April 9, 2010

Mule Summit Overview - Part I (1st Impressions)

Yesterday I attended the Mule Summit event in San Francisco. It was rather conveniently located just up the street at the Spear Tower -- in the penthouse none the less! Great view up there. Paul Dividian from Mulesoft was kind enough to invite me to this one day event gratis. Thanks Paul! The event consisted of announcements around the upcoming Mule ESB 3.0 release, feature updates to existing products and new product announcements including Mule HA, Mule MQ, Mule Data Integrator (a mapping tool), Tcat, Cloudcat and something new called "Glü" (REST. I will try to give my impressions of the products, people and atmosphere.

The structure of the event consisted of short product feature overviews, customer testimonials, and ended with break out sessions. The attendants were allowed to vote on which areas they wished to here more on from a list of preselected and write ins. I chose the Scalability session. Other topics touched graphical and feature enhancements, and other things I wasn't really that jazzed about. Mainly I was curious what there HA and scalability plans were.

Attendance was good with folks from all over the globe. i estimate that there were around 100+ there. Granted, a lot of those folks were Mulesoft employees. I heard Italian, Russian, Spanish, Hindi and Finnish among other languages being spoken in among the attendees.

The Mulesoft people had good energy and enthusiasm about there products and features. Receiving $12 million in venture capital may have enhanced their moods too.

Ross Mason, founder and CEO opened things up. Now here's a very charismatic guy. Looks good in a suit and can talk the talk. But he also has this slightly bad habit of stealing fellow underlings' thunder. He often jumped in on fellow Mulesofters presentations to clarify or emphasize important points to the chagrin of the presenter.

Buzz worthy stuff

I'll give more in depth reports on the following items, but for my 1st impressions.

Mule HA with Gigaspaces - In the Scalability breakout, this Russian guy named Igor was touting a distributed HA cluster solution with Gigaspaces at GM Capital.

HDFS transport - Support was mentioned for Hadoop HDFS transport in Mule ESB.

RESTful (Glü) - This seemed very intriguing. Glü is basically their RESTful integration offering. This in theory will allow RESTful access to all our data services from any HTTP client suing Ruby, AJAX, JSON, Groovy, etc. This replaces the current "iBeans" product from Mule. Apparently they are dropping the 'beans' moniker as it congers up complexity in people's minds.

Mule MQ - Supposedly the fastest message queuing solution out there. It deserves further looking into if the SEDA claims are true.

Cloudcat - Mule's cloud computing offering.

Tcat - Mule's Tomcat enterprise server management and deployment tool. It had some seemingly useful monitoring tools of active sessions, threads and connections of Tomcat deployed applications.

Friday, October 23, 2009

Mule POC Part III

Moving on to my next and last interface for my Mule POC, I chose our refund check processing system. Currently this system using IBM Message Broker that accepts a message from a queue, transforms the XML message and inserts into an Oracle database. Records are accumulated until a timed event occurs and another message broker flow reads the records from the database and generates an Excel csv file and emails this to our finance department.

I chose to start with the reading from the database part of this process as I was interested in seeing how easy or hard it was to access a database and also sending an email attachment through Mule.

My ever so helpful Solutions Architect from MuleSoft, Puneet was able to come by a give my a head start. Before he arrived I made sure I at least got the new Mule project started by myself as I wanted to test my knowledge of what I had learned from my first POC interface with Mule.

The first 'mistake' I made in my solo effort to start a new project was to use New/Other/Mule Project to get started. Although this is the simplest and most intuitive way to get started, as Puneet pointed out, it is better to use Maven and a POM file to seed the project structure then import the project into Eclipse.

I not that familar with Maven but am learning to like it. We are more of an Ant and Ivy shop here but so far I like working with Maven. I especially like that it combines build dependency management and code repository functions in one package.

JDBC Connector and Data Source

The first order of business for me was to hook up a JDBC connector so I could read our refund check database table. My first try at this did not work, I used the org.springframework.jdbc.datasource.DriverManagerDataSource. This data source was referenced in the "Mule in Action" book but when Puneet finally arrived to assist me, he suggested to use the org.enhydra.jdbc.standard.StandardDataSource instead.

Our course you need to include schema references and locations in the mule configuration and update your Maven POM file with dependencies. Below are the data source and jdbc connectors:

<spring:bean id="dataSource"
class="org.enhydra.jdbc.standard.StandardDataSource">
<spring:property name="driverName" value="oracle.jdbc.driver.OracleDriver" />
<spring:property name="url" value="jdbc:oracle:thin:@localhost:1521:TOOLSDB" />
<spring:property name="user" value="user" />
<spring:property name="password" value="****" />
</spring:bean>

<jdbc:connector name="jdbcConnector" dataSource-ref="dataSource">
<jdbc:query key="refundQuery" value="SELECT lst_nm, fst_nm, addr_ln1_txt, addr_ln2_txt, addr_ln3_txt, addr_ln4_txt, city_nm, st_prov_cd, zip_cd, phn_nbr, rfnd_amt, rfnd_dt, cust_nbr, inv_nbr, rfnd_chk_nbr, orig_ord_nbr FROM YANTRA_GIDFINANCE1_TMP_T where CRT_DT < sysdate" />
</jdbc:connector>

It is pretty straight forward, I am using the Oracle 14 thin client odbc driver jar. I added the dependency to the Oracle driver in the project Maven POM file and inserted the jar in the Maven project repository.

mvn install:install-file -DgroupId=com.oracle -DartifactId=oracle.driver.OracleDriver -Dversion=14.0 -Dpackaging=jar -Dfile="D:\\workspace\\GIDFinancePOC\\lib\\ojdbc14-10.2.0.1.0.jar"

Within the jdbc connector, there is the query to be run. It simply returns all rows for the listed columns that are less than sysdate. I tested this by first sending the output to an outbound, pass through router using stdio. It worked fairly easily after I fixed my botched SQL syntax errors. I am such a SQL klutz.

CSV File Output

Encouraged by the relative ease of getting the refund check data rows, I jumped right into using a file outbound end point. Realizing we would need a transformer to get our database results into a CSV file, Puneet suggested the FlatPack package once again to help. He pointed me to the MapsToCSVTransformer and we plugged it into the outbound file connector.

After building and running this configuration we quickly discovered this didn't fly. The output from our jdbc inbound endpoint was gererating a Map when the CSVTransformer was expecting a list. Strange, because the name of the transformer is MapsToCSVTransformer?

The MapsToCSVTransformer accepts a mapping file to configure the columns to generate in the CSV and a delimter:

<custom-transformer name="MapsToCSVTransformer"
class="com.mulesource.mule.transport.jdbc.transformers.MapsToCSVTransformer">
<spring:property name="mappingFile" value="map.refundcheck.xml"/>
<spring:property name="delimiter" value=","/>
</custom-transformer>

The map file details are here:

<?xml version="1.0"?>
<!-- DTD can be pulled from the Jar or over the web-->
<!DOCTYPE PZMAP SYSTEM "flatpack.dtd" >
<!--<!DOCTYPE PZMAP SYSTEM "http://flatpack.sourceforge.net/flatpack.dtd" >-->
<PZMAP>
<COLUMN name="lst_nm" />
<COLUMN name="fst_nm" />
<COLUMN name="addr_ln1_txt" />
<COLUMN name="addr_ln2_txt" />
<COLUMN name="addr_ln3_txt" />
<COLUMN name="addr_ln4_txt" />
<COLUMN name="city_nm" />
<COLUMN name="st_prov_cd" />
<COLUMN name="st_prov_cd" />
<COLUMN name="st_prov_cd" />
<COLUMN name="zip_cd" />
<COLUMN name="phn_nbr" />
<COLUMN name="rfnd_amt" />
<COLUMN name="rfnd_dt" />
<COLUMN name="cust_nbr" />
<COLUMN name="inv_nbr" />
<COLUMN name="rfnd_chk_nbr" />
<COLUMN name="orig_ord_nbr" />
</PZMAP>

To fix the Map to List issue, Puneet quickly created a MapToList custom transformer and tried it out. Well, it worked, kind of. But now we were getter a CSV file for each row! As there were well over 500 rows, I quickly killed the running Mule server. I made an attempt to add an outputAppend option to the file connector, but this didn't work either. Back to the drawing board.

My next post will hopefully resolve this issue such that we get one CSV file containing all the rows returned from the jdbc connector. Stay tuned.

Here is the pass through router and file connector used in this project:

<file:connector name="fileConnector" outputAppend="true" />

<pass-through-router>
<file:outbound-endpoint connector-ref="fileConnector" path="data" outputPattern="refundcheck-#[UUID].csv" transformer-refs="MapToList MapsToCSVTransformer" synchronous="true"/>
</pass-through-router>