Enterprise Developing End to End Systems v2 0 En

8/14/2019 Enterprise Developing End to End Systems v2 0 En

1/82

Enterprise: Developing End-to-End Systems

F O R U M N O K I A

Version 2.0; November 15, 2006

Enterprise


2/82

Enterprise: Developing End-to-End Systems 2

Forum.Nokia.com

Copyright 2006 Nokia Corporation. All rights reserved.

Nokia and Nokia Connecting People are registered trademarks of Nokia Corporation. Java and all Java-based

marks are trademarks or registered trademarks of Sun Microsystems, Inc. Other product and company names

mentioned herein may be trademarks or trade names of their respective owners.

Disclaimer

The information in this document is provided as is, with no warranties whatsoever, including any warranty of

merchantability, fitness for any particular purpose, or any warranty otherwise arising out of any proposal,

specification, or sample. Furthermore, information provided in this document is preliminary, and may be changed

substantially prior to final release. This document is provided for informational purposes only.

Nokia Corporation disclaims all liability, including liability for infringement of any proprietary rights, relating to

implementation of information presented in this document. Nokia Corporation does not warrant or represent

that such use will not infringe such rights.

Nokia Corporation retains the right to make changes to this specification at any time, without notice.

License

A license is hereby granted to download and print a copy of this specification for personal use only. No otherlicense to any other intellectual property rights is granted herein.


3/82


Forum.Nokia.com

Contents

1 Introduction.................................................................................................................................................... 71.1 Design considerations ............................................................................................................................71.2

Platforms and features...........................................................................................................................7

2 Distributed computing architectures ..................................................................................................... 9

2.1 Layers and tiers.........................................................................................................................................92.2 1-tier architecture ................. ................ ................ ................. ................ ................. ................ ................ .92.3 2-tier architecture .................................................................................................................................102.4 N-tier architecture.................................................................................................................................112.5 Intermediate architectures and examples ...................................................................................13

3 E2E technologies..........................................................................................................................................143.1 Basic models ...........................................................................................................................................14

3.1.1 Proprietary solution...........................................................................................................153.1.2 Object-oriented middleware...........................................................................................153.1.3 Distributed component models .....................................................................................17

3.2 Popular technologies ...........................................................................................................................183.2.1 Remote Procedure Call ......................................................................................................183.2.2 Object Request Broker.......................................................................................................193.2.3 Common Object Request Broker Architecture...........................................................193.2.4 CORBA Component Model .................................................................................................213.2.5 Java Remote Method Invocation....................................................................................23 3.2.6 Java Platform, Enterprise Edition ...............................................................................243.2.7 Web services.........................................................................................................................263.2.8 Component Object Model technologies and .NET Framework .............................27

4 Data transport..............................................................................................................................................294.1 Hypertext Transfer Protocol...............................................................................................................294.2 Sockets......................................................................................................................................................30 4.3 Short Message Service..........................................................................................................................304.4 Session Initiation Protocol .................................................................................................................314.5 File Transfer Protocol ...........................................................................................................................31

5 Payload protocols .......................................................................................................................................335.1 Proprietary format................................................................................................................................335.2 Extensible Markup Language ............................................................................................................335.3 SOAP...........................................................................................................................................................34 5.4 XML-RPC.....................................................................................................................................................35

6 Connection and data security..................................................................................................................366.1 Secure Sockets Layer and Transport Layer Security ...................................................................36


4/82


Forum.Nokia.com

6.2 Internet Protocol Security ..................................................................................................................376.3 Virtual Private Network.......................................................................................................................376.4 Making the decision .............................................................................................................................37

7 Connection establishment .......................................................................................................................398 Design patterns............................................................................................................................................40

8.1 Model-View-Controller.........................................................................................................................408.2 Interceptor...............................................................................................................................................41 8.3 Bridge........................................................................................................................................................42 8.4 Proxy..........................................................................................................................................................43 8.5 Adapter .....................................................................................................................................................448.6 Extension Interface...............................................................................................................................448.7 Faade ................. ................ ................ ................. ................ ................. ................ ................. ................ ...458.8 Iterator......................................................................................................................................................46

8.8.1 Block iterator........................................................................................................................468.9 Observer ...................................................................................................................................................478.10 Reactor......................................................................................................................................................47 8.11 Proactor ....................................................................................................................................................48

9 Limitations of the mobile environment ..............................................................................................5010 Practical performance study....................................................................................................................51

10.1 Test environment and implementation ........................................................................................5110.1.1 Client .......................................................................................................................................5110.1.2 Server ......................................................................................................................................53

10.2 Payload protocols..................................................................................................................................5310.2.1 Request message ................................................................................................................5410.2.2 Response message .............................................................................................................5410.2.3 Binary data handling .........................................................................................................5510.2.4 Proprietary protocol...........................................................................................................5610.2.5 XML...........................................................................................................................................57 10.2.6

WBXML ....................................................................................................................................59

11 Performance study results and conclusions .......................................................................................63

11.1 Transport protocol comparison........................................................................................................6311.1.1 Connection time ..................................................................................................................6311.1.2 Data transfer.........................................................................................................................6611.1.3 Keep-alive..............................................................................................................................68

11.2 Payload protocol comparison ...........................................................................................................6811.3 Impact of SSL/TLS on performance..................................................................................................71

12 Conclusions ................................................................................................................................................... 7613 Terms and abbreviations..........................................................................................................................77


5/82


Forum.Nokia.com

14 Further reading............................................................................................................................................8015 References ..................................................................................................................................................... 8116 Evaluate this resource ............................................................................................................................... 82


6/82


Forum.Nokia.com

Change history

January 9, 2006 Version 1.0 Initial document release

November 15, 2006 Version 2.0 Chapters 10, 11, and 12 added. Minor changes throughout the

document.


7/82


Forum.Nokia.com

1 Introduction

This document describes the most common architectures and technologies used in current end-to-end

(E2E) enterprise systems. It also gives an overview of the terminology and basic concepts of the

different technologies. The document also provides an introduction to the protocols used for datatransport and presentation, such as HTTP and XML, respectively; including a practical study that reveals

what effect different data and payload protocol combinations and using secure protocols have on

time and transmitted data.

When confidential data is being transferred over a wireless network, the security and encryption of

the data becomes an even more critical issue than in wired networks. Thus, the most important and

widely accepted methods for ensuring data integrity and security in mobile devices are also

examined.

There are two useful example E2E applications available on the Forum Nokia Web site:Symbian OS:

End-to-End HTTP API Example [4] andSymbian OS: End-to-End Sockets API Example[5] It is

recommended to download these examples for reference while reading this document; they provideexcellent practical examples of many of the topics discussed in this document.

This document targets the Series 40, S60, and Series 80 platforms. Series 40 provides developer

support only for Java Platform, Micro Edition (Java ME) applications, whereas applications for S60 and

Series 80 devices can be developed both in native Symbian C++ and Java ME environments.

1.1 Design considerations

The general requirements for enterprise applications are that they are scalable, can be run in

heterogeneous environments, and their development and deployment cycles are as short as possible.

These can be achieved by choosing the right architectural model and the right technology for the task

at hand. Chapters 2, Distributed computing architectures, and 3, E2E technologies, give an insightinto what kinds of solutions are available.

All these requirements apply to mobile applications as well. Most notably, the wireless environment is

yet another piece in the puzzle of heterogeneous environments. As a rule, the mobile environment is

much more restrictive than, for example, a normal corporate intranet environment with regard to

how complex and heavy the client part of the application can be. These kinds of issues are covered

more closely in Chapter 9, Limitations of the mobile environment.

Many enterprises already have a good selection of applications to which they might want to add

access from the companys mobile devices. To totally rewrite the applications would be a waste of

time and resources. If possible, the mobile client applications should be adapted to these existing

applications and use existing code as much as possible. Some technologies are better than others for

this purpose of acting as a wrapper over existing systems. If, on the other hand, the developer can

make a clean start on both the client and the server side of the application, some other technology

might suit the needs better.

1.2 Platforms and features

The technologies introduced in this document have variable support in the Series 40, S60, and Series

80 platforms. Table 1.1 lists the features and technologies supported by various editions of these

platforms.
http://www.forum.nokia.com/info/sw.nokia.com/id/5f4f909e-7e6a-42fa-8c4c-0e028b96a44f/Symbian_OS_End-to-End_Sockets_API_Example_v1_2.zip.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/4d725d07-06d1-4c11-b2a1-717c2bad832f/Symbian_OS_End-to-End_HTTP_API_Example_v1_2.zip.html


8/82


Forum.Nokia.com

Series 40 platform S60 platform Series 80

platform

1st

Ed

2nd

Ed

3rd

Ed

1st

Ed

2nd

Ed

3rd

Ed

2nd Ed

Symbian C++

SMS Messaging - - - X X X X

Web Services APIs(including XML and SOAP)

- - - - - X X

Socket connections - - - X X X X

SSL 3.0 / TLS 1.0 - - - - X X X

HTTP version - - - - 1.1 1.1 1.1

IPsec and VPN client - - - - X (FP2 X X

SIP API - - - X (a X (a X -

FTP API - - - - X (b - -

Java Platform, Micro Edition

CLDC version 1.0 1.1 1.1 1.0 1.1 (FP2 1.1 1.1

CDC 1.0 and Personal Profile - - - - - - X

MIDP version 1.0 2.0 2.0 1.0 2.0 2.0 2.0

Wireless Messaging API version 1.0 (c 1.1 1.1 1.0 1.1 2.0 1.1

Socket connections - X X - X X X

SSL 3.0 / TLS 1.0 - X X - X X XHTTP version 1.1 1.1 1.1 1.1 1.1 1.1 1.1

Web Services API(including XML and SOAP)

- - - - X (FP3 X X (d

SIP API - - - - - X -

a) A separate plug-in installation of the SIP stack is available on the Forum Nokia Web site

(http://www.forum.nokia.com/).

b) The S60 2nd Edition: FTP Example [2] for S60 2nd Edition (FP1, FP2, and FP3) containing the required

FTP libraries is available on the Forum Nokia Web site.

c) Not supported by all Series 40 1st Edition devices.d) Not JSR-172, but a CDC-based Nokia Web Services Enhancement for Java.

FP) Functionality added/version changed in Feature Pack of the platform edition.

Table 1.1: Summary of Series 40, S60, and Series 80 platform features
http://www.forum.nokia.com/info/sw.nokia.com/id/0041e19b-c315-4a6b-b86a-11f304771516/Series_60_Platform_FTP_Example_v1_0.zip.htmlhttp://www.forum.nokia.com/


9/82


Forum.Nokia.com

2 Distributed computing architectures

This chapter gives an overview of different architectural models used in distributed computing. It

explains the terminology related to these architectures along with the pros and cons of each of them.

The chapter is not intended to be a comprehensive description; it merely presents what kinds of

options are available to the application developer. The more complex models typically build on theones presented here. There are also intermediate models that lie somewhere in between these

models. The readers are encouraged to look for more information on the Web or in the several books

written on this subject.

2.1 Layers and tiers

The terms tierand layerare often used interchangeably to mean the same thing. In some cases, the

term tier is used to refer to a physical separation and the term layer to refer to a logical separation of

components of an application. When used in this document the terms are not considered synonymous

nor separated by physical or logical factors, as explained in what follows.

Generally, an application can be thought to consist of three logical layers: a presentation layer, abusiness logic layer, and a data access layer. The name of the business logic layer comes from the fact

that it contains the business rules that drive a given enterprise in some contexts it is also called an

application logic layer. The presentation layer provides the user interface and is therefore responsible

for handling the input from and presenting the output to the user. The data access layer provides

some additional services, typically a database access.

A tier can be either a logical separation or physical separation of components and each tier can

contain one or more layers, depending on the architecture used. In other words, each tier can be

physically located on separate computers or devices, but all the tiers might as well be located on a

single computer. Therefore, in this document, the separation into tiers is considered to be more of a

logical than a physical one.

2.2 1-tier architecture

A 1-tier application is one in which all the layers are tightly integrated. Here the presentation layer has

detailed knowledge of the data access layer and the business logic is interwoven with both the

presentation layer and the data access layer. In fact, it is sometimes hard to tell where one layer ends

and the other one begins. This type of monolithic architecture is nowadays very uncommon in

distributed computing solutions and is described here in brief only for reference.

The very first distributed computing solutions were based on the 1-tier model. There was usually just

a single mainframe computer (a server) that provided all the computing and logic for maybe tens or

hundreds of very simple, typically text-based terminals acting as clients. In this case the terminals

performed no processing, but were so-called dumb terminals intended merely for displaying theinformation to the user. Although the terminals provided the user interface, the interpretation of the

input and formatting of the output was done on the server and the user interface was not an

independent part of the application. Thus, also the presentation layer is considered here to be located

on the same single server tier as the other layers, as shown in Figure 2.1.


10/82


Forum.Nokia.com

Figure 2.1: The 1-tier architecture

Applications utilizing this architecture are easy to design and cheap to implement. They also perform

fairly well as long as the number of concurrent users stays low. The problems with this architecture

relate mostly to reusability of code and to scalability, since the load on the server can easily grow tobe too much for a single computer to handle efficiently enough.

2.3 2-tier architecture

The 2-tier architecture was the first one that could efficiently make use of the computing power

provided by the PCs that, at the beginning of the 1980s, were starting to show up on every desktop in

every office.

In this architecture the presentation layer and some or all of the business logic is spread across to the

PCs and the central mainframe becomes more or less just a database server. The simple nature of the

architecture can be seen in Figure 2.2 depicting that all the business logic has been moved to the

client. Now we have two distinct, independent tiers: the client tier and the server tier. Thepresentation layer and business logic layer are also functionally separated from each other.


The figure shows three separate clients, based on the S60 platform, the Series 80 platform, and Java

ME/MIDP, just to give an example. In this case, the presentation layer part is the S60 or Series 80 C++

application UI, or the MIDlet UI. The business logic (C++ application engine) is essentially the same in

both Symbian platforms thus promoting reuse of code. As a programming convention the Symbian

C++ client applications are typically implemented using the MVC pattern, which is described in Section8.1, Model-View-Controller.

Server

S60 Client

Presentation Layer(S60 UI)

Business Logic Layer(Engine)

Data Access Layer

Series 80 Client

Presentation Layer(Series 80 UI)

Business Logic Layer(Engine)

Java ME/MIDP Client

Business Logic Layer(MIDlet engine)

Presentation Layer(MIDlet UI)

Server

Terminal 1

Presentation Layer

Business Logic Layer

Data Access Layer

All layers tightlycoupled on theserver

Terminal 2 Terminal N


11/82


Forum.Nokia.com

With the MIDP application, both the engine and UI parts would ideally be the same in each supported

platform (Series 40, S60, and Series 80; device-specific optimization might sometimes be needed).

MIDP typically provides fewer capabilities for an application developer so the developer has to

carefully select the programming language based on the features needed by the application. It is even

possible to create both Symbian C++ and MIDP clients that access the same data access layer on the

server.

Using the 2-tier architecture, applications are easy and relatively inexpensive to develop and their

performance is good. No special hardware or software is needed and there is a vast tool support for

software development available. If as much of the business logic as possible is embedded on the so-

called fat clients, the database server needs to do very little processing on the data, thus relieving the

servers burden and enabling it to serve more clients. Another solution is to still have some or most of

the business logic on the server tier and use so-called thin clients. For small and simple applications

the 2-tier approach can be highly efficient.

Unfortunately this architecture also has its more or less obvious drawbacks. First of all, the part of the

application on the clients might be very complex and expensive to maintain. For example, any change

to the application needs to be updated on all the clients and it is not always easy to make sure that all

the clients get updated correctly at the same time. Also, the application logic cannot be reused, since itis bound to an individual application and the client-side code might contain application-specific

database query statements. This leads to poor scalability in applications.

The network load can also be considerably high since a lot of or all the data has to be transported over

the network to the client to be processed the data also needs to be encrypted somehow, which

increases the network load even more. Especially this fact makes the 2-tier architecture in many cases

unsuitable for a mobile environment. Furthermore, advanced transaction techniques such as two-

phase-committing cannot be run, since the client controls how the transactions are conducted. Finally,

in terms of security, the clients always need to be considered as untrusted entities. Still, sensitive data

is passed to the clients for lack of an alternative.

The newer n-tier architectures try to solve all these problems primarily by moving the business logicfrom the client back to a separate server.

2.4 N-tier architecture

In n-tier architectures, the system is divided into three or more separate tiers in a distributed network.

The most common form of this architecture is the 3-tier architecture, where the presentation layer is

located on the client device, business logic layer on a shared computer usually called an application

server and the data access layer on a database server.

The division into tiers is purely logical and, for example, the business logic and the database can be

physically located either on a single computer or on separate computers across the network. Actually,

it is often beneficial to implement both of these tiers on the same machine for easier and fasterdatabase access.

This section concentrates on the 3-tier model, since in distributed computing the possible additional

tiers in other n-tier models are usually the product of dividing the application server tier into more

fine-grained tiers. Also, in Web-based applications the presentation layer is sometimes divided into a

client-side presentation layer and a server-side presentation layer, thus creating an extra tier for the

latter.

The 3-tier architecture also uses the client/server computing model, where the business logic has a

dual role: towards the client device it acts as a server and towards the database it acts as a client. The

structure of this architecture is depicted in Figure 2.3, again containing three separate clients. As in

the 2-tier solution, the client tier still contains some logic that can be considered to be a slice of the

business logic layer. The client is typically implemented using the MVC pattern described in Section 8.1,

but in this case the responsibilities of the client-tier business logic are very limited. All the heavy


12/82


Forum.Nokia.com

processing and business-critical functions are performed on the business logic layer residing on the

application server.


There are several advantages related to this model. All tiers the client tier, the application server

tier, and the database server tier can be developed concurrently and independently from each

other. Each tier can even be programmed using different programming languages and run on

different operating systems. This separation also allows each tier to be replaced by a newimplementation when needed, providing that the interfaces between the tiers are well-designed and

thus do not need to be modified. An important aspect is also that now the client code does not

contain any database query statements or similar direct ties to the database.

Since at least the critical part of the business logic layer which usually is the layer most prone to

changes is now located on its own separate tier rather than on the client tier, replacing it is easier

and cheaper than in the 2-tier architecture: the software needs to be installed and tested only once.

The code used for the business logic can be reused by other applications running on the same

application server, thus enabling considerable savings when extending the current business logic or

creating new applications.

Critical business processes that work on security-sensitive data are now run on a trusted serverinstead of the untrusted client. This means that if the client is a mobile device, a lesser amount of

possibly sensitive data needs to be sent over a wireless network.

In this architecture, dynamic load balancing is also possible. If too many clients try to connect to the

server at the same, the server can forward some of the requests at run time to another server running

the same server process. Better scalability also means that better performance on the server side can

be achieved simply by adding more hardware to the server.

This architecture can even be used as a wrapper over, for example, 1-tier legacy systems. The request

from the clients to the business logic can be forwarded to the legacy system and served there. Then,

later on, the legacy system can be replaced by a more modern solution still keeping the business logic

layers interface towards the client tier unchanged.

Database Server

Data Access Layer

Application Server

Business Logic Layer For efficiency reasons it isoften beneficial toimplement these on the

same physical computer

S60 Client

Client-side BusinessLogic (Engine)

Series 80 Client


Presentation Layer(Series 80 UI)

J2ME/MIDP Client

Presentation Layer(MIDlet UI)

Client-side BusinessLogic (MIDlet engine)



13/82


Forum.Nokia.com

2.5 Intermediate architectures and examples

As mentioned, the architectures presented in previous sections of this chapter are not the only ones

available they merely present the guidelines. Your particular solution might not fit directly into any

of these categories but might end up being somewhere in between instead. In some situations the

same functionality can be implemented using the same architecture in many different ways that, at

first look, do not resemble each other at all.Symbian OS: End-to-End HTTP API Example [4] andSymbianOS: End-to-End Sockets API Example [5] do just that.

Both examples are implemented using the 3-tier model. They have a client tier with two separate

clients, an application server tier with business logic, and a database server tier with a MySQL

database. The application server in the examples contains both a PHP-based and a JSP-based

implementation for the business logic layer and the presentation layer.

In the examples the location of the layers depends on the type of client used. The browser client

contains no logic whatsoever; it merely presents the HTML pages formatted by the server to the user.

Thus, even most of the presentation layer could be considered to be located on the server, as is the

case with many 3-tier Web applications. With the Symbian C++ client the situation is more like the

basic 3-tier model presented in Figure 2.3; the client decides how it formats and presents the data tothe user. Figure 2.4 presents the architectural model of the examples.

Figure 2.4: Architectural model of the Socket and HTTP API examples

S60 Client



Application / Database Server

Business Logic Layer

Data Access Layer

Presentation Layer

Browser Client

Presentation Layer

Not the same as the 1-tier model; each layer isdecoupled from theothers and the serveractually contains twotiers
http://www.forum.nokia.com/info/sw.nokia.com/id/5f4f909e-7e6a-42fa-8c4c-0e028b96a44f/Symbian_OS_End-to-End_Sockets_API_Example_v1_2.zip.htmlhttp://www.forum.nokia.com/info/sw.nokia.com/id/4d725d07-06d1-4c11-b2a1-717c2bad832f/Symbian_OS_End-to-End_HTTP_API_Example_v1_2.zip.html


14/82


Forum.Nokia.com

3 E2E technologies

If a developer wants to create an enterprise application, there is a vast pool of different technologies

to choose from all the way from proprietary socket-based technologies to more advanced

technologies such as Web services and Enterprise JavaBeans. This chapter first describes what types of

factors a developer needs to consider when choosing a technology for the application. Then thechapter gives an insight into various technologies available on the market and explains briefly what

kinds of situations each of them is suitable for.

The first step to designing an enterprise application, besides architectural issues, is deciding the

technology to be used. There is no one size fits all type of solution available and the choice must be

based on the characteristics and requirements of the particular application.

The basic components involved in distributed computing using a mobile client are presented in Figure

3.1. Your application utilizes the data connection provided by your device (be it based on GPRS, 3G, or

some other wireless technology) to connect to the base station. The base station, in turn, is connected

to the enterprise network via the public IP network. One way of sending and receiving SMS messages

from your server-side applications is to use an SMS gateway service provided by a mobile serviceprovider. Certain technologies might bring their own additional devices into the model. Although the

figure and the basic concept are simple, there is a lot more to it than what meets the eye.

Figure 3.1: Basic components needed in mobile enterprise applications

There are a number of basic approaches to developing distributed applications. These range from

implementing the whole application yourself to using sophisticated middleware and component-

based solutions as a basis for the application. And, of course, the final implementation can be

anything in between. The three basic types of solutions are described in Section 3.1 and the most

popular implementations and specifications conforming to these models in Section 3.2.

3.1 Basic models

There are three basic models for building distributed applications, each having their own pros and

cons. The basic properties of these models are briefly explained here. However, you should keep in

mind that the models do not have clear boundaries and by extending one or choosing not to use

some extra features of another, you can customize the models to fit your particular needs.

GPRS / 3G

SMS

IP Network

Mobile Client Base Station

Firewall

Servers

Enterprise Network

SMS Gateway


15/82


16/82


Forum.Nokia.com

Figure 3.2: The principle of middleware

The client application cannot directly create or destroy objects of the class it wants to use; the client-

side stub represents the remote object to the client. The call goes through the stub, which merely

marshals the parameters (in other words, turns method calls into messages) and passes the call to the

server-side skeleton. The skeleton then unmarshals the parameters (turns messages back into method

calls) and makes the actual method call to the appropriate object. The return value is returned in the

reverse order through the skeleton and the stub.

Although setting up a system like this might seem time-consuming and tedious at first, it usually isworth while if the application under development is not just a trivial one. The time spent when

choosing a suitable middleware implementation and vendor will most likely be time saved later on in

the development and maintenance phases. The structure of the application becomes simpler and

application code is not overloaded with details concerning the location of the server and the remote

object. The client code is also not affected by the network, transport, and other communication

details, such as the format of the messages passed between the client and the server.

Middleware in general provides several other benefits as well. Depending on the implementation,

middleware can contain features for managing the CPU load and memory resources on the server. In

many cases, it also provides various automatic services typically needed in distributed applications,

such as naming, persistence, transaction, and connection security services. Now the application

developer can concentrate on the logic of the application itself, rather than worrying about all theadditional functionalities separately with every single application.

As mentioned, the downside of using commercial middleware is that it takes time and effort to learn

to use all its features. And to really be able to make full use of all the capabilities, takes even longer.

Furthermore, commercial products are rarely inexpensive (although there are exceptions to this, such

as Java RMI), so in some cases it is not very logical to acquire such a product just in case. Your

applications current and future needs should be determined very carefully before any decisions on

purchasing a middleware product are made.

There are several middleware solutions and specifications to choose from, most of which are in one

way or the other related to the Object Request Broker technology described in Section 3.2.2.

Server

Middleware

Skeleton

Client

Float Result := A.Foo(4);

Middleware

Stub

unmarshal

results

marshal

arameters

receive

unmarshal

arameters

marshal

results

sendreceive

Object A:

Float Foo (X: Integer) {

return (Float) X / 2;

send


17/82


Forum.Nokia.com

3.1.3 Distributed component models

As the complexity and size of enterprise applications have increased, the need for a more refined

technology has become apparent. The object-oriented middleware technologies are nowadays simply

not sufficient in many cases.

Distributed component models are such that deal with software components rather than plain objects.The term component can be described as a self-contained unit of software code consisting of its own

data and logic, with well-defined connections or interfaces exposed for communication. It is designed

for repeated use in developing applications, either with or without customization [1]. The most

commonly known distributed component models are CORBA Component Model (CCM), Enterprise

JavaBeans (EJB), and Component Object Model+ (COM+). All of these are described later in this chapter.

The distributed component models, in essence, specify how classes (objects) should be written in

order for them to be accessible from the outside world as components. The central part of these

models is the component container, which provides many useful features. The most notable of these

features are transaction supportand resource pooling (thus distributed component models are

sometimes called transactional component middleware). A reference model of these distributed

component models is depicted in Figure 3.3.

Figure 3.3: Reference model of distributed component models

A component typically has several interfaces, one of which is the home interface. The home interface

is responsible for managing the component and it provides facilities for lifecycle management and for

locating the correct components to handle the clients request.

The general idea of distributed component models is that standard facilities, or services, are

implemented by the container rather than by each individual application or component (which would

result in lots of unnecessary system calls). The containers are typically implemented with the

interceptor design pattern described in Section 8.2, where the container intercepts the call from the

client, utilizes the services needed, and then forwards the call to the component itself.

These services can be taken into use at deployment time using a deployment descriptorso that, for

example, starting or ending a transaction, or storing the components state into persistent storage

does not need to be hard-coded into the component itself. It is simply sufficient to declare the

component to be persistent. After this the container takes care of where and how the state is stored.

The way the container implements the persistence service can be changed at any time transparently

to the component. If, for some reason, the component needs to make use of the services explicitly, itcan do so through the container API.

Container

Container API

ComponentHome

Client

Transactions Persistence Security

Deployment descriptor

Containerintercepts andadds automatic

services


18/82


19/82


Forum.Nokia.com

with other vendors implementations. One can, however, achieve similar results by using SOAP or XML-

RPC for relaying method calls. These protocols are described in Chapter 5, Payload protocols.

3.2.2 Object Request Broker

In general, Object Request Broker (ORB) is a middleware technology that manages communicationand data exchange between objects. Object request brokers promote interoperability of distributed

objects because they enable users to build systems using objects from different vendors that

communicate with each other via the ORB. The developers are generally not interested in the inner

workings of the ORB, only in the details of the object interface accessed using the ORB. The ORB hides

and isolates object communication details from the application.

An object request broker can be thought of as kind of a telephone exchange, where the exchange

provides a directory of services and connects the clients to these services. The principle of the ORB is

illustrated in Figure 3.5.

Figure 3.5: The principle of the object request broker

ORB functions can be implemented, for example, by compiling them into the client applications, by

using separate processes or by embedding them into the operating system kernel. There are several

ORB or ORB-like implementations available today. The most important ones CORBA, COM/DCOM, and

Java RMI are described later in this chapter.

3.2.3 Common Object Request Broker Architecture

The Common Object Request Broker Architecture (CORBA) is Object Management Groups (OMG,

http://www.omg.org/) open, vendor-independent specification for an ORB architecture and

infrastructure that computer applications use to work together over networks. The specification

comprises of two parts described in Sections 3.2.3.1, Interface Definition Language, and 3.2.3.2,Inter-ORB protocols. [10]

CORBA was one of the first object-oriented middleware specifications and in modern standards is old-

fashioned and hard to use. For example, many automatic services provided by modern distributed

component models, such as Enterprise JavaBeans, must be implemented manually in CORBA.

Nonetheless, understanding the principles of CORBA helps to understand the general properties of

distributed object-oriented middleware.

Server-side applications developed using CORBA cannot currently be directly accessed from Series 40,

S60, or Series 80 devices. To do this, a proxy implementation similar to the one presented in Figure 3.6

is needed. The proxy server in this case could be, for example, a Java EE server that accepts pure HTTP

requests and uses Enterprise JavaBeans to connect to the server-side CORBA. The functionality and

properties of the Java EE server are presented in Section 3.2.6, Java Platform, Enterprise Edition.

Communicate

Establishconnection

Locate service Activate service

Client application

ORB

Remote service (object)
http://www.omg.org/


20/82


Forum.Nokia.com

Figure 3.6: Connecting to CORBA using a proxy server

CORBA is widely used and has a strong industry support behind it. There are several implementations

available from different companies, although one important company never joined the CORBA front:

Microsoft developed its own solutions, as described in Section 3.2.8, Component Object Model

technologies and .NET Framework.

3.2.3.1 Interface Definition Language

The interfaces of the server objects are defined using a special OMG Interface Definition Language

(OMG IDL). A client uses the IDL interface to specify which operation it wants to perform, and to

marshal the parameters it sends to the server object. When the invocation reaches the target object,

thesame interface definition is used to unmarshal the parameters. The target object then performs

the operation and the return values are again marshaled and unmarshaled when they are sent back to

the client.

IDL itself is independent of programming language, but it maps to many popular programming

languages via OMG standards: OMG provides standardized mappings from IDL to C, C++, Java, and

Python, just to mention the most popular ones.

An important part of CORBA relating to IDL is the IDL processor. The processor reads the interface

definition written using IDL and generates client-side stubs and server-side skeletons automatically

for each interface.

3.2.3.2 Inter-ORB protocols

The CORBA specification contains two protocols: General Inter-ORB Protocol (GIOP), for the

communication between ORBs, and its TCP-based implementation, Internet Inter-ORB Protocol (IIOP).

CORBA requires that all implementations support IIOP to ensure the interoperability of ORBs from

different vendors.

GIOP is an abstract protocol, which means that it only specifies the messages used and how they

should be handled. It does not care which transport protocol is used underneath. It merely states

some requirements for the protocol, such as that it needs to be reliable and connection-oriented. IIOP

fulfils these requirements by using TCP, but other types of GIOP implementations are also available.

3.2.3.3 Wireless CORBA

The current CORBA specification is not directly suitable for wireless networks because it assumes that

the network is reliable and no or few connection failures happen. Moreover, CORBA does not take into

account that devices can move from one access point or network technology to another while the

connection is open. That is why OMG has developed a new specification called Wireless Access and

Terminal Mobility in CORBA specifically for CORBA over wireless networks [11]. Implementations of

e.g. IIOP

e.g. HTTP

Java EE server

CORBA implementationEJB

Mobileclient

Servlet / JSP


21/82


Forum.Nokia.com

Wireless CORBA can be used with existing CORBA and CORBA Component Model implementations

transparently.

3.2.4 CORBA Component Model

The CORBA specification has evolved to the next stage through the development of CORBA ComponentModel (CCM) in CORBA 3.0 specification. CCM defines, for example, the programming model for

constructing component implementations, a container programming model describing how an

Enterprise JavaBeans (EJB, described in Section 3.2.6.1) component can be used by CORBA clients

including CORBA components and how component implementations may be packaged and

deployed [9]. It provides a consistent component architecture framework for creating distributed n-

tier middleware.

A typical CCM architecture consists of the following elements:

CCM containers

CORBA components that run in the CCM containers (that is, CORBA components are components

that are written to the CCM specification)

Portable Object Adapter (POA)

Object Request Broker (ORB)

CORBA services, such as transaction, security, persistence, and notification (that is, event) channels

Figure 3.7 depicts the relationship between these elements [1]. The containers and components are

described in more detail in Sections 3.2.4.1, CCM containers, and 3.2.4.2, CORBA components. The

CORBA components running in CCM containers can be accessed from mobile clients by, for example,

using the same proxy setup as illustrated in Figure 3.6.

Figure 3.7: A typical CCM architecture

An important part of the architecture which is not shown in Figure 3.7 is a special entity called home.

Each component has a home entity that manages the component. It provides lifecycle and additional

services on behalf of the component. For example, homes provide factory operations that are used to

create instances of the components they manage, and to remove the components when they are not

needed anymore.

ORB/POA

Container

CORBAComponent

Transactions Security Persistence


22/82


Forum.Nokia.com

3.2.4.1 CCM containers

CCM containers are typically provided by application server manufacturers along with the application

server itself. These servers contain the CCM containers, which in turn contain pre-built CORBA

components that can then be used to develop other components and distributed applications. [7]

The container is defined in terms of how it uses the underlying CORBA infrastructure and it can only beimplemented on CORBA. This guarantees interoperability with other implementations of CCM

containers.

The CCM containers act as the interface between a CORBA component and a client application using

the services of the component. The client accesses the CORBA component through container-

generated methods which, in turn, are mapped to the methods of the component. The containers can

be either transient or persistent in nature, depending on what kinds of components they contain.

An important aspect of the CCM which should not be overlooked is its specification of a CORBA-based

container for hosting Enterprise JavaBeans. This is essential for providing two-way interoperability

between EJBs written in Java programming language and CCMs written in any CORBA programming

language. [1]

3.2.4.2 CORBA components

Each CORBA component can provide and use multiple interfaces. In CCM, the interfaces that the

component uses are called receptacles and the interfaces that it provides are called facets. Existing

CORBA objects can be converted into components by hiding them behind a facet by using a special

supports clause in the interface definition, thus promoting reuse of code.

There are four categories of CORBA components. These are listed in Table 3.1. The table also shows the

relations to container types and the component equivalents in the Enterprise JavaBeans technology.

Comp. category Container type Primary key? EJB equivalent

Service Transient No Session bean (stateless)

Session Transient No Session bean (stateful)

Process Persistent No None

Entity Persistent Yes Entity bean

Table 3.1: CORBA component categories

Eachservice componentis usually associated with one client and its lifetime is restricted to that of a

single service request (method call). This component can never have a notion of state. A service

component instance is created and destroyed by the particular client using it.

Session components are also usually associated with one client and the client is responsible for

creating and destroying the component instance. Session components can have states or they can be

stateless. However, the state of a session component is not stored in persistent storage.

Process components always have states. Each process component may, however, be shared by multiple

clients. The state of a process component can be stored in persistent storage. Process components

differ from entity components only in the way that they do not have a primary key for being uniquely

identifiable to the client. While entity components are used to represent entities like customers or

accounts, process components represent business processes like applying for a loan or creating a work

order.


23/82


Forum.Nokia.com

Persistence can in context of process and entity components be handled in two ways. When container-

managed persistence is used, the CCM container is responsible for storing the state of the component.

The component then has no control over or dependency on where and how the state is stored. When

component-managed persistence is used, the component is responsible for storing its own state.

Persistence is thus hard-coded into the component in the form of, for example, database calls. This

way the application has more control, but the solution is less adaptable.

3.2.5 Java Remote Method Invocation

Java Remote Method Invocation (Java RMI) technology, developed by Sun Microsystems, is the object-

oriented middleware equivalent of Remote Procedure Calls (RPC). In RPC, a client can only call

procedures over a network, but in RMI the concept of classes and objects is strongly present. RMI bears

many similarities to CORBA and can in many cases be used to solve similar programming problems.

The biggest difference between the two is that while CORBA is independent of the programming

language, RMI works only with the Java programming language and cannot be used as a wrapper for

legacy systems written in other programming languages.

In RMI, client applications can use services provided by objects residing in another Java Virtual Machine

(JVM) using a remote reference to the remote object. The same remote object can also be used through

a regular object reference by other objects in the same (server-side) JVM. The details of the

communication between the client and the server are handled by RMI and the remote method call

looks exactly like a standard Java method invocation, which makes RMI relatively easy to adapt.

The basic components of RMI are shown in Figure 3.8. The figure also shows which communication

method is used between the entities. The server application registers its remote objects to the registry

using RMIs simple naming facility. The client application can then use the registry to locate the

remote objects it needs to use. Remote references can also be passed or returned as part of the

applications normal operation.

Figure 3.8: RMI components

If, for some reason, the class definition of the remote object is unknown to the client (or the calling

client object is unknown to the remote object), RMI allows for the byte code and data of the unknown

object to be loaded from an existing Web server. This is a very powerful feature, since it allows new

types to be introduced in another JVM.

URLprotocolURLprotocol

RMI (invoke)

RMI (register)RMI (lookup)

Client Server

Webserver

Registry


24/82


Forum.Nokia.com

Figure 3.9: Mobile RMI using a proxy server

Support for RMI has not been included in the MIDP 1.0 or 2.0 specifications (JSR-37 and JSR-118), and

thus cannot be directly utilized from mobile clients. If one already has a running RMI application, a

mobile client can be connected to it using, for example, a system based on a proxy server. One

possible solution of this type is depicted in Figure 3.9 (the registry and Web server are not shown here

for simplicity). In this case it does not really matter whether the mobile client application is a Symbian

C++ or Java application.

3.2.6 Java Platform, Enterprise Edition

Sun Microsystems Java Platform, Enterprise Edition (Java EE, http://java.sun.com/javaee) is a platform specifically

indented for designing, developing, and deploying n-tiered, component-based enterprise applications. The

platform provides an ability to reuse components, a unified security model, and a flexible transaction control.

Figure 3.10 shows the Java EE components and containers. These components are examined more

closely later in this section. [12]

Figure 3.10: Java EE server and containers

The figure clearly shows the n-tier nature of the platform (client tier, application server tier, and the

database server tier). As illustrated in the two enterprise application examples mentioned in Chapter

1, the client can be a browser application that connects to the Web container, or another type of an

application that connects either to the Web container or directly to the EJB container using RMI-IIOP or

SOAP protocols, as described in Section 3.2.6.1.

The Java EE platform also delivers interoperability with Web Services by providing a set of APIs for

building and exposing services as Web Services. Web Services are examined in Section 3.2.7.

JavaEETM

Server

Client Device

Browser

Client

ApplicationClient

Servlet JSP

EJB Container

EnterpriseBean

EnterpriseBean

Database

HTTP

HTTP

e.g. RMI-IIOP(or possibly

SOAP)

Web Container

e.g. XML / SOAPover

HTTP / socket /

Existing RMIapplication

Proxy server

ServerClient

Mobileclient
http://java.sun.com/javaee


25/82


Forum.Nokia.com

3.2.6.1 Enterprise JavaBeans

Enterprise JavaBeans (EJB) is a distributed component model developed by a consortium lead by Sun

Microsystems as part of Java EE. Although the name might suggest otherwise, EJB has essentially

nothing to do with the slightly older JavaBeans component model, which is meant for building

traditional applications. EJB provides very similar services as CORBA Component Model, such as

transaction, security, and persistence services.

In EJB the components are called enterprise beans and they run inside an EJB container. The basic

model for the EJB architecture is quite the same as the one shown in Figure 3.3. There are three types

of beans:

Entity beans represent data in the database

Session beans represent processes or act as agents performing tasks (can be either stateless or

stateful, meaning that they either hold or do not hold a notion of state during the session with

the client)

Message-driven beans allow applications to asynchronously handle messages arriving from, for

example, the client, another enterprise bean, or a Web component

Beans can be compiled, configured, and taken into use independently. As in general with distributed

components, beans provide multiple interfaces for different purposes. The central interfaces and parts

of a bean are

Remote interface the beans interface towards the client, defines the functionality of the bean

(that is, the business logic, visible outside the container)

Remote home interface contains methods for locating the bean and for managing its life cycle

(creating and destroying the bean, also visible outside the container)

Local interface the same as remote interface, but only visible inside the container

Local home interface the same as remote home interface, but only visible inside the container

Bean class implements the beans business logic and the methods in the home interface

Primary key a simple class that corresponds to the primary key in a database, needed for

persistent beans

EJB implementations are specific to the Java programming language but still, as Java technologies in

general, platform independent. Any enterprise bean should be able to be run in any EJB compliant

container, no matter who the vendor is.

As in CORBA Component Model, in EJB the entity beans persistence can be handled in two ways: using

container-managed persistence (CMP) or bean-managed persistence (BMP). In CMP no database access

code needs to written in the bean itself, but in BMP the bean must contain all the code needed for it to

store its state.

The EJB specification states that each EJB implementation must support at least the RMI-IIOP protocol

for connections from clients. RMI-IIOP merely defines how RMI is used over CORBA IIOP (described in

Section 3.2.3.2). The advantage of this is that CORBA clients can also connect to EJB implementations

and EJB clients to CORBA implementations. Some implementations might also support SOAP (described

in Section 5.1) and other protocols.

To use RMI-IIOP the mobile client needs to use a proxy solution similar to the one shown in Figure 3.9

on page 24. Support for SOAP would mean easier access from mobile clients through the Web Services

APIs described in Section 3.2.7. Currently the best way to connect to the business logic is perhaps

through the Web container using HTTP.


26/82


Forum.Nokia.com

3.2.6.2 Web components

Java Servlet and JavaServer Pages (JSP) technology components are so-called Web components.

Servlets and JSP have many features in common and both can be used for serving up dynamic Web

content (Web pages). An excellent introduction to JSP and servlets can be found at

http://java.sun.com/developer/onlineTraining/JSPIntro/contents.html.

In short, JSP provides a way to separate the look and feel of the Web page from the underlying business logic. For

example, a browser can connect to a servlet running in the Web container using HTTP. JSP is then used to

dynamically create the page that is finally sent back to the client. A JSP page can contain code snippets for

connecting to the business logic (EJB) or directly to the database. This behavior was illustrated earlier in this

chapter in

Figure 3.10.

3.2.7 Web services

Web services have one big advantage over all the other technologies listed in this document: they are

truly interoperable across vendors, platforms, and programming languages. This stems from the fact

that they use XML-based SOAP as a payload protocol and universally accepted HTTP as a transport

protocol (these are described in Sections 4.1, Hypertext Transfer Protocol, and 5.3, SOAP). SOAP

being a purely textual format is usable in any environment. HTTP has the advantage of typically having

no trouble navigating through firewalls.

Unfortunately Web services biggest advantage is also their biggest disadvantage especially SOAP

adds a considerable amount of overhead to the messages sent across a network. In addition to HTTP

being a fairly slow transport protocol, parsing the SOAP messages takes also a considerable amount of

time. Thus Web services are slower than most of the other technologies and not very suitable for high-

performance systems. Problems arise also, for example, on how to send binary data using a text-based

payload protocol. Furthermore, Web services are inherently stateless, that is, a new object is created

to service each request sent by the client. Callbacks are not directly supported at all.

Web services can be discovered and invoked by several different applications alike, as well as by other

Web services (in other words, server applications can connect to other server applications if needed,

transparently to the client). Using Web services, businesses can share data among partners and across

legacy applications. For security, Web services rely on the security extensions developed for SOAP, as

explained in Section 5.3.

In Web services jargon, clients are called consumers and server applicationsproviders of services.

Providers publish their Web services described in Web Services Description Language (WSDL) by

placing the WSDL documents into a special directory. The directories, in turn, use the Universal

Description, Discovery and Integration (UDDI) technology that allows the directories to be searched for

a particular Web Service. The basic usage of Web services is shown in Figure 3.11 (here the consumer

would be a mobile device). The communication along each arrow in the figure is conducted usingSOAP messages.
http://java.sun.com/developer/onlineTraining/JSPIntro/contents.html


27/82


Forum.Nokia.com

Figure 3.11: Basic usage of Web services

The Nokia Web Services Framework provides APIs and ease of use of Web Services for both Java and

Symbian C++ applications. For Java applications Web Services APIs are available from S60 2nd Edition,

Feature Pack 3 onwards and for Symbian C++ applications from S60 3rd Edition onwards.

The Nokia Web Services Framework is also available on the Series 80 platform for Symbian C++applications. For Java applications the platform provides an implementation called Nokia Web Services

Enhancement for Java.

The various APIs provide basic services to the calling applications from XML parsing to messaging

functions. Using the standard Web services interfaces the applications can act both as consumers or

providers. To read more about the Nokia Web Services Framework, consult the Forum Nokia Web site

(http://www.forum.nokia.com/). The Series 40 platform does not provide built-in support for Web

services.

3.2.8 Component Object Model technologies and .NET Framework

Component Object Model (COM) is a component technology developed by Microsoft that can be used to

develop reusable software components and enables those components to communicate. The COM

technology family also includes Distributed COM (DCOM) and COM+.

As the name implies, DCOM is used for creating distributed COM-based applications; in other words,

DCOM allows COM processes to communicate across a network. COM+ is a sort of an umbrella

technology that brings together COM/DCOM and the application host of Microsoft Transaction Server

(MTS).

COM+ can be compared to Java EE and EJB in a sense that it provides similar platform and automatic

services to distributed applications and Web applications. The similarity of the two can also be seen by

comparing

Figure 3.12 showing the relationship between the COM technologies to the corresponding one

for Java EE, namely

Figure 3.10.

5. Service response based on WSDL

4. Service request based on WSDL

3. WSDL forthe requested

service

2.Directory

1. Publish servicedescription using

WSDL

Consumer Provider

Directory (UDDI)
http://www.forum.nokia.com/


28/82


Forum.Nokia.com

Figure 3.12: COM technologies

The Internet Information Server (IIS) is actually a group of Internet servers, but in this example it is

used as a Web server serving HTTP requests. Active Server Pages (ASP) can be functionally compared to

JavaServer Pages described briefly in Section 3.2.6.2. Together IIS and ASP can be used to achieve

similar results as with servlets and JSP in Java EE environment, for example, to create dynamic Web

pages and Web applications.

For new development Microsoft recommends the use of .NET Framework, which in practice is a very

wide concept that can be called a platform, a framework, or even an operating system. It encompasses

a virtual machine that runs the applications created for .NET and compiled into bytecode. Since the

whole concept is very broad and complicated, it will not be described in detail here. For more in-depth

information on .NET, see the Microsoft Developer Forum Web site (http://msdn.microsoft.com/library/).

The components created in .NET are exposed to clients as Web services. This behavior is very easy to

implement it is simply a matter of placing a certain directive on a method to be exposed this way

and makes the components accessible from practically anywhere. For example, .NET server

applications can be accessed from S60 and Series 80 devices using the Web Services Framework

described in Section 3.2.7.

COM/DCOM/COM+ applications and .NET applications are completely interoperable and applications on

both sides can use services provided by the other. The biggest advantage of both COM and .NET

technologies is that they provide support for multiple programming languages, such as C++, Java,

Visual Basic, and Visual C#. A third-party solution from AppForge (http://www.appforge.com/) enables

application development for S60 devices with Visual Basic and Visual C#, which is very beneficial for

developers who want to be able to implement both the server and client side of the application using

just one familiar language.

The disadvantage of COM technologies is that they can only be used on Windows platforms. Today

there are a few solutions available that enable applications developed with .NET to be run, for

example, on Linux, but these solutions are still under development and typically lack some features

that are available for .NET applications on Windows.

Windows 2000

Client Device

Browser

ApplicationClient

IIS ASP

COM+ Runtime

COMObject

COMObject

Database

HTTP

HTTP

DCOM
http://www.appforge.com/http://msdn.microsoft.com/library/


29/82


Forum.Nokia.com

4 Data transport

When designing enterprise applications in, for example, a corporate intranet, the choice of transport

method is fairly trivial. Application developers can choose whatever solution that suits their needs the

best, since typically there are no firewalls disturbing the data connections inside the intranet.

When the enterprise application is meant to be accessed from outside the intranet, or as in this case,

from a mobile device, the number of suitable transport methods is considerably reduced. This chapter

lists some typical methods for data transport and briefly explains their pros and cons.

4.1 Hypertext Transfer Protocol

Hypertext Transfer Protocol (HTTP) is an application-level, request-response type of protocol that was

originally designed for transferring raw data, such as Web pages, across the Internet. Today the

protocol is used for various other purposes as well, not just for basic Internet access.

The current version of the protocol is HTTP/1.1 and, compared to the earlier version (HTTP/1.0), itcontains more enhanced features. For example, the underlying Transmission Control Protocol (TCP)

connections can now be utilized more efficiently. Two of these features are the support for persistent

connections and pipelining. By specifying the HTTP header value Connection: keep-alive, the

underlying TCP connection can be kept alive for the duration of more than one request-response pair.

This feature is useful in many situations related to enterprise applications, since bandwidth is not

wasted by unnecessarily opening multiple TCP connections (with multiple TCP handshake messages

for each). With pipelining, multiple requests can be sent at once in a single TCP segment. In addition

to these, HTTP/1.1 has incorporated transport compression of data types to further reduce the use of

bandwidth. [18]

There are a couple of properties that make HTTP an attractive choice. Through the success of the Web,

HTTP has become a very widely used protocol and today practically every device that has networkaccess supports it including mobile devices. There are many ready-to-use commercial and free HTTP

servers available on the market. Moreover, since HTTP traffic typically uses TCP port 80 or 8080, it can

easily navigate through firewalls without any additional reconfiguration. Figure 4.1 shows the setup

of a typical HTTP connection.

Figure 4.1: A typical HTTP connection

The downside of HTTP is that despite the improvements in HTTP/1.1, it is still not the fastest protocol

available. This is mainly due to the properties of TCP, such as the so-called slow start mechanism, and

the fact that HTTP traffic has low priority in the routers along a network. This means that especially

when the network is congested, HTTP traffic slows down considerably.

Symbian C++ APIs for HTTP/1.1 are provided from S60 2nd Edition and Series 80 2nd Edition onwards.

HTTP/1.1 is also supported in MIDP 1.0 and MIDP 2.0 implementations.

HTTP(GPRS / 3G)

IP Network


Firewall

Servers

Enterprise Network

HTTP(wired network)

HTTP(wired

network)


30/82


Forum.Nokia.com

When secure connections are needed, HTTP can be run transparently over SSL/TLS protocols if the

particular platform supports these protocols. SSL and TLS are described in Section 6.1, Secure Sockets

Layer and Transport Layer Security.

4.2 Sockets

Sockets are the oldest and as a concept probably the simplest form of communication between

applications on different devices. You simply create an application on the server to listen to an

appropriate port for incoming connections and then you set up your client application to connect to

that host and port. Now you can transport raw bytes from one place to another in whatever form suits

your needs best. Naturally, if there is a firewall between the client and the server, you probably need

to reconfigure it to pass the traffic of your application. The typical setup of a socket connection, shown

in Figure 4.2, is very similar to the one of HTTP (shown in Figure 4.1).

Figure 4.2: A typical socket connection

Depending on the needs of your application, there are two types of socket connections available; the

socket connection can use either User Datagram Protocol (UDP) or Transmission Control Protocol (TCP).

Both of these are available essentially in all networked devices. The difference here is that with TCP a

connection is always made between the client and the server and the same connection is used for

consecutive messages, whereas each UDP datagram contains the target and source addresses and isforwarded individually through the network. This means that TCP guarantees that the messages are

delivered in correct order to your application UDP does not even guarantee that the datagrams are

delivered at all. On the other hand, establishing and tearing down the connections takes more time

and generates a lot more traffic than merely sending a single datagram when needed.

Support for both kinds of sockets is available in S60 and Series 80 devices for Symbian C++

applications. MIDP 1.0 applications cannot establish socket connections; this feature is available only

in MIDP 2.0.

Although the concept of sockets is simple and they provide the developer with flexibility when

implementing the communication channel, using sockets has its cost: practically everything needs to

be done by hand for each application separately.

Secure socket connections are provided by the SSL and TLS protocols as described in Section 6.1,

Secure Sockets Layer and Transport Layer Security.

4.3 Short Message Service

If an application can cope with asynchronous, infrequent, but reliable data transfer, the Short Message

Service (SMS) might be the way to go. SMS datagrams are especially useful when the client application

needs to be able to receive notifications or small amounts of data from the server as soon as the data

becomes available. The S60 and Series 80 platforms provide Symbian C++ APIs and the Wireless

Messaging API (WMA) for Java applications for registering an application as a message listener and for

sending and receiving SMS datagrams. The Wireless Messaging API is also available in Series 40devices.

Socket(GPRS / 3G)

IP Network


Firewall

Servers

Enterprise Network

Socket(wired network)

Socket(wired

network)


31/82


Forum.Nokia.com

The biggest restriction is that each datagram can only contain a maximum of 140 bytes (8-bits) of

binary data or 160 (7-bits) text characters. The APIs in the Series 40, S60, and Series 80 platforms

support concatenating multiple SMS datagrams, but still the user has to pay separately for each of

them.

There are many ways to enable your server-side system to send and receive SMS datagrams. For

example, you can subscribe and connect your server to a mobile service providers SMS gatewayservice or fit your server-side system with an additional device capable of receiving and sending SMS

datagrams. This first situation is illustrated in Figure 3.1. Other options are also available, but the issue

is out of scope of this document and it will not be discussed in more detail here.

4.4 Session Initiation Protocol

Session Initiation Protocol (SIP) is an application layer signaling protocol developed for initiating,

modifying, and terminating interactive user sessions that involve multimedia elements (such as voice,

instant messaging, and video) over IP. Like HTTP, SIP is human readable, simple, and utilizes the

request-response mechanism. As a protocol SIP is standardized by the IETF, but the Third-Generation

Partnership Project (3GPP) is standardizing the way SIP is used in wireless networks.

SIP has an extensive amount of features, but it can also simply be used for messaging between two

applications. The body part of a SIP message can be used to exchange textual and binary data. SIP

contains header and payload encryption and other security facilities as built-in mechanisms that can

be utilized directly, thus avoiding the need to use security mechanisms that are external to the

protocol.

The disadvantages of using SIP are that typically the client application, or User Agent (UA), must be

able to act both as a client and a server, which might add unnecessary complexity to some

applications. In order to be able to utilize SIP at all, one has to have a few additional network devices:

a SIP proxy, a SIP registrar, and the actual SIP application server among others. SIP typically has

problems with firewalls and to work around them, the proxy would most likely need to sit on the

firewall and open the necessary ports for SIP traffic as needed. Moreover, SIP is not meant fordistributed applications by design and it has many features that will probably not be needed at all.

This might make it unnecessarily heavy for some applications.

The S60 platform provides Symbian C++ and Java SIP APIs from 3rd Edition onwards. The Series 40 and

80 platforms do not have built-in support for SIP. A very useful document on SIP called SIP Frequently

Asked Questions [3] can be downloaded from the Forum Nokia Web site.

4.5 File Transfer Protocol

Although the first impression of File Transfer Protocol (FTP) does not relate it to enterprise

applications, it has its place among the other protocols mentioned here. After all, FTP can be used to

transfer files regardless of the content of those files. If needed, the files can even contain remotemethod invocations formatted using, for example, XML or SOAP.

FTP is a simple, reliable and very efficient protocol for transferring files. Probably the most intuitive

situation to use FTP is one where there are several clients that need to access shared files and where

there is the need to identify each client by a username and a password. These mechanisms are built

into the protocol itself, so little extra work is required on behalf of the application. Like HTTP, FTP is a

mature and stable protocol. It is easy to learn and take into use. There are many commercial and free

FTP servers available.

FTP is an IETF standard originally specified in RFC0959 (ftp://ftp.rfc-editor.org/in-notes/rfc959.txt).

Unfortunately the basic FTP specification does not contain built-in security mechanisms, which are

specified separately in RFC2228 (FTP Security Extensions, ftp://ftp.rfc-editor.org/in-notes/rfc2228.txt).
ftp://ftp.rfc-editor.org/in-notes/rfc2228.txtftp://ftp.rfc-editor.org/in-notes/rfc959.txthttp://www.forum.nokia.com/info/sw.nokia.com/id/4e5f782f-1848-49f6-9cb1-63c553d1a7b0/SIP_FAQ_v1_0_en.pdf.html


32/82


Forum.Nokia.com

The S60 platform is the only platform that provides any FTP support for developers, although the

required FTP libraries may not be present in all S60 devices. The S60 Platform: FTP Example [2] for S60

2nd Edition, Feature Pack 1, 2, and 3 containing these libraries can be downloaded from the Forum

Nokia Web site. The example and the libraries conform to the original FTP specification and thus do

not support the security extensions. If security is needed in the file transfer, some external mechanism

is required.
http://www.forum.nokia.com/info/sw.nokia.com/id/0041e19b-c315-4a6b-b86a-11f304771516/Series_60_Platform_FTP_Example_v1_0.zip.html


33/82


34/82


Forum.Nokia.com

solution. There are many commercial and open-source solutions available, but embedding them into

the application increases the size of the application. This size might not be an option especially with

Java applications, whose size is typically limited to 64 kB.

S60 3rd Edition contains the Nokia Web Services Framework with XML APIs for both Symbian C++ and

Java applications. In addition to this, S60 2nd Edition, Feature Pack 3 provides XML support for Java

applications. The Nokia Web Services Framework is also available for Symbian C++ applications on theSeries 80 platform. For Jav

Enterprise Developing End to End Systems v2 0 En

Documents

Transcript of Enterprise Developing End to End Systems v2 0 En