CloudTran Home

 
  
 
Contents  >   4.  Concepts
 


4.5 Concepts - Messaging

CloudTran supports messaging, with modelling, grid (i.e. GigaSpaces) integration and ESB integration. This chapter discusses the modelling aspects. Other aspects are discussed in the Congestion Charge example. Messaging in CloudTran can be implemented using a number of ESBs. CloudTran provides a default integration with Mule 2.2.1.

This chapter addresses the modelling concepts of messaging. The integration details of Mule are covered in the Rather than try to support multiple ESBs, transport mechanisms and deployment scenarios CloudTran has abstracted the common parts of a message infrastructure. These common message components are modelled and from these the common code is generated. Depending on the options chosen some of the message configuration files will also be generated. For example if the default ESB (mule) is used CloudTran will generate part of the mule configuration, which can be included in the deployers configuration files.

 4.5.1  Mule
 4.5.2  Modelling Concepts

4.5.1  Mule
As mention the default ESB, integrated into CloudTran is Mule 2.2.1

Mule ESB (http://www.Mulesoft.org/what-Mule-esb) is the open-source Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily using messaging patterns.

The following image explains the JVM boundaries in a typical mule supported application:

JVM boundaries explained


4.5.2  Modelling Concepts
The concepts used to model messaging are:
  • Receiver
  • Sender
A Receiver is an Endpoint of messages coming into the modelled system, so it represents Inbound messages to the system. A Receiver references a java-bean and a space. The java-bean represents the data and the space represents the destination or Endpoint of the data. So, from the point of view of the ESB the Receiver is In reality this turns into a Polling Container on the space listening on the defined java-bean. When the java-bean arrives in the space, having been written there by the ESB it is taken out and passed

The Sender is the opposite of Receiver. Again it is an Endpoint but this time it represents an Outbound Message - from the system's point of view. From the viewpoint of the ESB this is the inbound Endpoint. Again the Sender references a space and a java-bean. The java-bean is written to the defined Space, where the ESB can process it. In the case of Mule (the default ESB) the implementation is also a Polling Container which takes the java-bean out of the space and places it on its message queue.

A working example can be seen in the \jeewiz\examples\CloudTran\CongestionCharge, where messages are used to feed JavaBeans into a space The modelling concepts and the generated code and configuration are shown in Chapter 3 Tutorial - Congestion Charge.


Copyright (c) 2001-2011 CloudTran Inc.