enterprise developing end to end systems v2 0 en
TRANSCRIPT
-
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
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.
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
3/82
Enterprise: Developing End-to-End Systems 3
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
4/82
Enterprise: Developing End-to-End Systems 4
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
5/82
Enterprise: Developing End-to-End Systems 5
Forum.Nokia.com
14 Further reading............................................................................................................................................8015 References ..................................................................................................................................................... 8116 Evaluate this resource ............................................................................................................................... 82
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
6/82
Enterprise: Developing End-to-End Systems 6
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.
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
7/82
Enterprise: Developing End-to-End Systems 7
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/14/2019 Enterprise Developing End to End Systems v2 0 En
8/82
Enterprise: Developing End-to-End Systems 8
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/ -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
9/82
Enterprise: Developing End-to-End Systems 9
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.
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
10/82
Enterprise: Developing End-to-End Systems 10
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.
Figure 2.2: The 2-tier architecture
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
11/82
Enterprise: Developing End-to-End Systems 11
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
12/82
Enterprise: Developing End-to-End Systems 12
Forum.Nokia.com
processing and business-critical functions are performed on the business logic layer residing on the
application server.
Figure 2.3: The 3-tier architecture
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
Client-side BusinessLogic (Engine)
Presentation Layer(Series 80 UI)
J2ME/MIDP Client
Presentation Layer(MIDlet UI)
Client-side BusinessLogic (MIDlet engine)
Presentation Layer(S60 UI)
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
13/82
Enterprise: Developing End-to-End Systems 13
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
Presentation Layer(S60 UI)
Client-side BusinessLogic (Engine)
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 -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
14/82
Enterprise: Developing End-to-End Systems 14
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
15/82
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
16/82
Enterprise: Developing End-to-End Systems 16
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
17/82
Enterprise: Developing End-to-End Systems 17
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
18/82
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
19/82
Enterprise: Developing End-to-End Systems 19
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/ -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
20/82
Enterprise: Developing End-to-End Systems 20
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
21/82
Enterprise: Developing End-to-End Systems 21
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
22/82
Enterprise: Developing End-to-End Systems 22
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.
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
23/82
Enterprise: Developing End-to-End Systems 23
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
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
24/82
Enterprise: Developing End-to-End Systems 24
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 -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
25/82
Enterprise: Developing End-to-End Systems 25
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.
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
26/82
Enterprise: Developing End-to-End Systems 26
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 -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
27/82
Enterprise: Developing End-to-End Systems 27
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/ -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
28/82
Enterprise: Developing End-to-End Systems 28
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/ -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
29/82
Enterprise: Developing End-to-End Systems 29
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
Mobile Client Base Station
Firewall
Servers
Enterprise Network
HTTP(wired network)
HTTP(wired
network)
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
30/82
Enterprise: Developing End-to-End Systems 30
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
Mobile Client Base Station
Firewall
Servers
Enterprise Network
Socket(wired network)
Socket(wired
network)
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
31/82
Enterprise: Developing End-to-End Systems 31
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 -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
32/82
Enterprise: Developing End-to-End Systems 32
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 -
8/14/2019 Enterprise Developing End to End Systems v2 0 En
33/82
-
8/14/2019 Enterprise Developing End to End Systems v2 0 En
34/82
Enterprise: Developing End-to-End Systems 34
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