Home > Articles

  • Print
  • + Share This
This chapter is from the book

7.4 Ubiquitous Integration

Enterprise mobile clients need to integrate with many different back end or middleware systems. In this section, we introduce several common integration technologies and discuss how to use them judiciously. Table 7.1 is a brief layout of the pros and cons of each approach. Figure 7.3 illustrates the characteristics of each integration scheme.

07fig03.gifFigure 7.3. J2ME smart client and J2EE backend integration schemes.

7.4.1 Proprietary Binary Protocols

Since HTTP support is mandatory on all J2ME devices, it is the basis for most other approaches. HTTP can transport text as well as any arbitrary binary content. Our examples iFeedBack (Chapter 3) and Smart Ticket (Chapter 5) both demonstrate the use of custom-designed binary protocols over HTTP. The binary protocols are designed to tailor the application needs and minimize the number of bytes needed to be sent over the network.

Table 7.1. Integration Comparison Chart

Scheme

Interoperability

Coupling

Footprint

Binary over HTTP

poor

tight

light

RPC frameworks

OK

tight

light

Messaging

OK

loose

OK

XML Web Services

excellent

loose

heavy

However, this approach results in tight coupling between the servers and clients. We have to develop both serverside and clientside components to interface with the custom protocol. If the design changes in the future, we have to change the application on both sides. If we do not have control over the server, we cannot take this approach. For applications that require frequent updates, the custom protocols are also not optimal.

7.4.2 Use Mobile RPC Frameworks

A more standardized integration approach is to use commercially available RPC frameworks. Such examples include the Open Source kCommand toolkit and the Simplicity transaction engine. The kCommand toolkit defines a set of open APIs that both the client and server can call to pass generic RPC parameters. Please refer to the link in the "Resources" section to find out more about its use. The Simplicity transaction engine is a proprietary solution tightly bundled with the Simplicity IDE. Using Simplicity RAD tools (Chapter 14), you can drag and drop your remote transaction components on an application composer and let the IDE generate the code for you. It is very easy to use for simple applications. However, the auto-generated source code can be hard to customize.

With the mobile RPC frameworks, we save the time to develop proprietary and hard-to-maintain interface components. But the server and client remain tightly coupled.

7.4.3 Messaging Is Our Friend

Messaging solutions, especially asynchronous messaging, decouple the client and the server through the messaging middleware. Properly designed messaging solutions could greatly improve the reliability and scalability of the system because resources can be allocated to respond to requests on a priority basis rather than a first-come-first-served basis. Chapter 10 discusses enterprise messaging based on mobile messaging-oriented middleware.

7.4.4 XML and Web Services

XML Web Services advocate platform-agnostic open interfaces. It supports both RPC style and messaging style integration. However, since XML Web Services pose large bandwidth and CPU overheads, we have to use them carefully. I suggest the use of XML Web Service only when the mobile client is interfacing external components or multiple client interoperability is required. We saw an example of Web Services integration in Chapter 3 and will see many more in Chapters 16 and 17.

  • + Share This
  • 🔖 Save To Your Account