From JRapid

Jump to: navigation, search

This article is about integrating JRapid apps to other apps in an application ecosystem.



JRapid applications have a three-layer architecture:


  • Data layer
  • Presentation layer
  • Business Logic layer

Every time an n-tier application enters an application ecosystem, it can be integrated through any of these layers.

So, there are three patterns to be followed:


  • Data Integration: Many applications store loads of information in storage like plain text files, relational databases, etc. Other applications that may require to access this information can do it directly from these storages. There are three typical integration patterns in this data layer: Shared database, Maintain data copies and File Transfer. One of the advantages of this approach is that there are plenty of tools for performing the job. But there is also a restriction when these storages cannot be easily accessed.
  • Functional Integration: Applications can reuse the business logic encapsulated in the business layer (not just the data stored, or just the data presented) through APIs and interfaces. Unfortunately, not every applications existing in integration architectures are compliant with this approach. The patterns here are: Distributed objects, Message-oriented integration and Service-oriented integration.
  • Presentation Integration: Data is integrated at UI layer. This is the least intrusive way of accessing information, but there is an important disadvantage: the access level that other applications have is the same as the user has. Moreover, there is a big coupling: if the application UI changes, the integration must be changed in order to adapt to these changes.

In the following examples, there will be 2 different cases considered for each pattern (data, functional or presentation):

  1. JRapid app is the preexisting application, and other app wants to plug JRapid app.
  2. Other app is the preexisting application, and JRapid app wants to plug this app.

Data Integration

When JRapid app is the preexisting application, it can offer raw data through the Shared Database integration pattern, as JRapid apps persist the information in a relational database (default is MySQL), accessible from external apps.


Access information can be found in the configuration file, (check out Configuration files)

If performance is in danger (perhaps the external app needs to query heavy amounts of information, for example), Maintain data copies pattern can be adopted.

When other apps are the preexisting applications, JRapid can use Java power to open any storage, mainly through:

  • RDBMS access through JDBC
  • Reading streams like files or sockets (

JRapid can connect to existing RDBMS and discover the data model so as to extend it using Reverse Engineering

Presentation Integration

When other apps are the preexisting applications, JRapid (being a web application) can apply screen scraping to include screens from these other systems. This can be achieved through frames or iframes, and embedding contents through a proxy (see next section).


When JRapid app UIs need to be included in other apps, programmers can use screen scraping, obviosly. But, hence, they can use Jrapid-runtime.js library to include easily forms inside their current applications.

Functional Integration

Functional integration is perhaps one of the strongest features in JRapid apps environments.

Every JRapid app can be integrated through the web services API (Check out [1]])

So, when there are 2 apps to be integrated, the simplest case is when you have 2 JRapid apps. In this case, you can use file, which will map local services to remote services (all the stub automation is ready to be used).

Here is a example:

# general urls

# per schema urls

# general proxies
# per schema proxies

JRapid is very easy to integrate with market standard tools like Mule ESB

You may choose any of the built-in transports defined by Mule, and also implement your own's.


All you need to do if you want to connect to a Mule ESB server, is to declare it as another url in the file


Here is an example mule-config.xml file to try out some examples:

<flow name="files">
  <http:inbound-endpoint host="localhost" port="18888" keep-alive="true" exchange-pattern="request-response" />
  <http:outbound-endpoint host="" port="80" path="/preexistingapp/xml/Role/0" />

External links

Connecting to layered applications, Microsoft MSDN Getting started with Mule ESB

Personal tools