Middleware and Integration Services

Web Application Platform / Application Server


Originally, a middleware layer was created to glue together and standardize web appliations connecting, Java, Perl, and mainframe Cobol applications. The middleware also centralized and standardized common mid-layer functionality like security, DB access, logging, etc. With all the enterprise-grade options available now, there is no longer a need to invest in a proprietary, home-grown middleware solution. We have an initiative to replace our "home-grown" middleware and have done an assessment and selected RedHat JBoss Enterprise Middleware (or at least some of its components) for the new middleware. The assessment is summarized within the ESB findings and linked just below.

Enterprise Service Bus (ESB)


We have an initiative to replace our "home-grown" middleware and have done an assessment and selected RedHat JBoss Enterprise Middleware (or at least some of its components) for the new middleware. RedHat Fuse ESB has been identified as the first middleware component to implement. We are in POC/assessment mode with Fuse, and we have started looking at other products to fill gaps that we see in Fuse (Mule, Talend). Of course, one of the lures of Fuse has been the potential benefits of several UCs converging on the same product.

At this point, we are concerned by a specific limitation of Fuse that we have discovered. Much of the data transformation/mapping has to be done by hand where other ESB products provide visual tools for this, in addition to added security, governance, API management, etc. Specific question for current Fuse adopters: Since, Fuse doesn’t have graphical data transformation tool, how are Fuse users actually implementing the transformations? Fuse has recommended to do it by hand, but for a large transformation, it is going to be very time consuming and error prone.

In summary, it seems difficult to address local campus needs while attempting to converge on one single UC-wide ESB product. We like the idea of identifying a small set of products so that support/knowledge can be leveraged across those campuses.

Update as of 11/07/2013: 

UCSD recently completed a comprehensive ESB assessment and has selected WSO2 as our ESB solution (for the central Administrative IT department). Last year there was a bigger initiative to replace all Middleware components because our home-grown solution had served us for 10+ years and had reached its limits. Attached is a summarized presentation of the Middleware replacement initiative that was started last year and concluded with the recommendation of JBoss Enterprise Middleware as the complete solution. Recently we started our proof of concept with two JBoss components: JBoss Enterprise Application Platform for our Java Web Apps, and JBoss Fuse ESB for integration and web services and realized that Fuse would not be the best solution for our ESB needs. The tail end of the presentation focuses on ESB and our assessment process and results.

Business Process Modeling (BPM) tool


The next business need and expansion to the middleware stack was the BMP. This presentation summarizes the BPM assessment and recommendation. The long list of potential solutions got reduced quickly. Long list included: BPM Suite, Bonita, Talend, jBPM, Activiti, Imixs, Stardust, Camunda, WSO2 Business Process Server, ActiveVOS, Intalio. Short list: jBPM, Bonita, Intalio, Activiti. Bonita and jBPM were the two top, and at the end, jBPM seemed more robust and with better development and integration tools. We are currently in the Proof of Concept (POC) phase.

Resources & Training