venu report

8/8/2019 Venu Report

1/89

A PROJECT REPORT ON

WEBKIT PORTOF

MOBILE SOA

Submitted in partial fulfillment of the requirements for the

Award of the degree of

MASTER OF TECHNOLOGYIn

COMPUTER & INFORMATION SCIENCEBy

VENU R

Under the Esteemed Guidance ofMr. Ennai Anuraj Mr. G Santhosh KumarSenior Staff Engineer Lecturer

Motorola India Research Labs Dept. of Computer Science

Bangalore CUSAT

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITY OF SCIENCE &TECHNOLOGY

KOCHI 682022JUNE 2008


2/89


3/89

DEPARTMENT OF COMPUTER SCIENCE

COCHIN UNIVERSITYUNIVERSITY OF SCIENCE &

TECHNOLOGY, KOCHI-682022

CERTIFICATE

Certified that project work entitled Webkit Port of Mobile

SOA is a bonafide work carried out by Venu R in partial

fulfillment for the award of Master of Technology in Computer

& Information Science from Cochin University of Science &

Technology during the academic year 2007-2008

Dr. K Poulose JacobProfessor &

Head Of Department

Dept. of Computer ScienceCUSAT

G Santhosh KumarInternal Project Guide

Lecturer

Dept. of Computer ScienceCUSAT


4/89


5/89

Acknowledgement

I am greatly indebted to Mr. Ennai Anuraj Kunnummel,

Senior Staff Engineer, Motorola India Research Labs for his technical

support, constant encouragement, consistent guidance and inspiration

throughout the course of this investigation. I am extremely happy to thank

Mr. Siddhartha Bosefor his valuable suggestions, technical support and

guidance during the course of my project work. I am extremely happy to

thank Mr Shrikant S Naidu for for his valuable suggestions.

I express my sincere thanks to our H.O.D, Prof. Dr. Paulose

Jacob for being a great pillar to all our achievements.

I feel immense pleasure in thanking my guide Mr. G.

Santhosh Kumar, Lecturer, Department of Computer Science for his valuable

suggestions and support during the course of the project work. I am

extremely happy to thank Dr.Sumam Mary Idicula and Mr. David Peter S,

Professors, Department of Computer Science for their excellent guidance and

valuable help rendered throughout this project in a versatile manner.

Above all I thank God Almighty for helping me to complete

this work successfully.

Venu R


6/89


7/89

Abstract

Rich Internet applications (RIA) are Web applications that have the features and

functionality of traditional desktop applications . RIAs typically transfer the processing

necessary for the user interface to the Web client but keep the bulk of the data (i.e.,

maintaining the state of the program, the data etc) back on the application server. SOA

can also be regarded as a style of information systems architecture that enables the

creation of applications that are built by combining loosely coupled and interoperable

services. These services inter-operate based on a formal definition (or contract, e.g.,

WSDL) that is independent of the underlying platform and programming language. In

recent times, emergence of WEB 2.0 paradigms based on technologies like AJAX and

user behaviors like social networking has pushed RIAs forward as the applications of

choice for a variety of enterprise and consumer uses.. By integrating SOA and WEB 2.0

technologies on a mobile device, RIA applications running on the mobile device can

access SOA applications available from the device, thus supporting SOA control on the

mobile device. To support Mobile SOA functionality from RIA platform, a JavaScript

Object that can be accessed from the browser platform and that gives access to mobile

SOA functionality in the device has to be developed. This project aims to develop such a

JavaScript Object on a RIA platform and use it to run SOA applications on the RIA

platform.


8/89


9/89

CONTENTS

Acknowledgement vii

Abstract vii

INTRODUCTION 1

1.1 Organization Profile 11.1.1 Overview: 11.1.2 Motorola India Operations: 2

1.1.3 Motorola India Research Labs (MIRL): 21.2 Project Overview 2

Chapter 2 5

BACKGROUND 5

2.1 Webkit Architecture 62.1.1JavaScriptCore 62.1.2 WebCore 6

2.2 ECMA Script 8

2.2 Mobi Linux 8

Chapter 3 11

SERVICE ORIENTED ARCHITECTURE 11

3.1 An Introduction to Service Oriented Architecture 12

3.2 A Reference Model for Service Oriented Architecture[1]

13

3.3 Decomposing the Interaction Model 16

3.4 A Reference Architecture for Service Oriented Architecture[1]

17


10/89

3.5 Client Tier 20

3.6 Architectural Conventions Spanning Multiple Tiers[1] 22

3.7 Service composition 233.7.1 Request-Response 243.7.2 Request-Response via Service Registry (or Directory) 243.7.3 Subscribe-Push 25

3.8 Data push 26

Chapter 4 27

MOBILE SERVICE ORIENTED ARCHITECTURE 27

4.1 Problem Statement 28

Chapter 5 31

CLIENT-SERVER WITH MOBILE THIN CLIENT & BROWSER 31

Chapter 6 35

IMPLEMENTATION ARCHITECTURE 35

6.1 Mobile Browser: 36

6.2 Shared Library: 37

6.3 Device Layer Daemon: 38

6.4 Shared Memory: 38

Chapter 7 39

IMPLEMENTATION DETAILS INCLUDING PORTING 39

7.1 Existing Implementation 397.1.1 Purely OS Specific (Windows V/s Linux) 407.1.2 Device Specific 42


11/89

7.2 Mobile Browser Implementation 44

7.3 Communication b/w Shared Library and Device Layer 45

7.4 Porting Implementation 49

Chapter 8 51

TESTING 51

8 .1 Testing Strategy 51

8.2 Test Documentation 538.2.1 SOAJavaScript object JavaScript Interface 538.2.2 Presence Service Input Script 54

8.3 OUTPUT Screen Shots 56

8.4 Status 578.3.1 Work Completed 578.3.1 Work Remaining 57

8.4 Testing Status 58

Chapter 9 59

LEARNING FROM IMPLEMENTATION 59

CONCLUSION 61

Appendix A 63

Browser Architecture 63

The web browser domain 63

Appendix B 69

ECMA SCRIPT 69


12/89

Brief History 69

Web Scripting 71

Language Overview 71

References 75


13/89

LIST OF FIGURES

Figure 2.1 Webkit Architecture 7

Figure 2.2 Mobi Linux Architecture 9

Figure 3.1 Reference Model SOA 14

Figure 3.2 SOA Interaction Model 16

Figure 3.3 Architectural Frame Work SOA 18

Figure 3.4 Client Operation Architecture 20

Figure 3.5 Service within Overall Architecture 23

Figure 3.6 SOA Request Response Pattern 24

Figure 3.7 SOA Request Response Pattern with service registry 25

Figure 3.8 SOA Subscriber-Push pattern 26

Figure 6.1 Porting specific implementation Architecture 36

Figure 7.1 Webkit JavaScript Object addition 44

Figure 7.2 Mobile SOA Communication Architecture 45

Figure 7.3 Communication Protocol 47

Figure 7.4 Overall Communication 48

Figure 7.5 Porting Class Diagram 49

Figure 8.1 Browser Testing 52

Figure 8.2 Communication Testing 52


14/89

Figure 8.3 Service Manager Testing 53

Figure 8.4 Testing Individual services 53

Figure a.1. Browser evolution 65

Figure a.2 Browser Architecture 68


15/89

Chapter 1

INTRODUCTION

1.1 Organization Profile

1.1.1 Overview:

Motorola is known around the world for innovation and leadership in wireless

and broadband communications. Inspired by our vision of Seamless Mobility, the people

of Motorola are committed to helping you get and stay connected simply and seamlessly

to the people, information, and entertainment that you want and need. We do this by

designing and delivering the "must have" products, "must do" experiences and powerful

networks - along with a full complement of support services


16/89

2 Chapter 1

1.1.2 Motorola India Operations:

Motorola India is headquartered at Gurgaon, Haryana, with offices at Delhi,

Mumbai and Bangalore. It has research and development centers at Bangalore and

Hyderabad. Motorola's operations in India are divided into three businesses: Mobile

Devices, Networks & Enterprise, and Connected Home Solutions. The Companys focus

areas include, Mobile handsets, Wireless Infrastructure, Managed and Hosted Services,

Broadband Equipment (wired as well as wireless), Trunking & Two Way Radios,

Software Development, Applied Research and Development on Seamless

Mobility/Convergence technologies.

1.1.3 Motorola India Research Labs (MIRL):

Motorola launched its applied research labs in Bangalore on 7th April 2005.This

is Motorolas 11th research facility world wide and first in India. The Lab in India was

launched by Ms. Padmasree Warrior, former executive vice president and chief

technology officer.

With access to Indias proven best-in-class scientific and engineering talent and

the ability to collaborate with world-class universities and institutes, Motorola believes

India is the ideal region for applied research and software development. The Motorola

Labs Bangalore mainly focuses on key application research.

1.2 Project OverviewMobile devices are basically becoming new client platforms, and thus need to

support most of the new computing paradigms, including SOA. Web Services, in the

context of mobile computing, is all about the notion of devices that can move in and out


17/89

Introduction 3

of service areas, and at the same time find and leverage Web services as needed, and with

the right validation. This should be a bidirectional mechanism where mobile devices can

both consume and provide services; in essence the mobile device becomes a peer.

Enterprise computing is going through a paradigm shift from proprietary monolith

systems to service oriented solutions. Also, business processes and work in general are

becoming increasingly independent from location and other contextual limitations,

raising the need for multiple access channels to processes. Another emerging need is

shifting between access modalities; for example, making preparatory work using a

limited capability mobile device while traveling towards office, and changing to a full-

scale PC application upon arrival. To address these phenomena, we propose the concept

ofMobile SOA, which combines service oriented design of systems and applications with

the domain of lightweight mobile devices. This document discusses the implementation

options of porting the mobile SOA from windows mobile platform to MobiLinux

platform where an open source browser acts as the client.


18/89


19/89

Chapter 2

BACKGROUND

WebKit is an open source web browser engine. WebKit is also the name of the

Mac OS X system framework version of the engine that's used by Safari, Dashboard,

Mail, and many other OS X applications. It is also used as the browser engine of web run

times like Adobe AIR. It is also included supported by mobile platforms, the iPhone,

Nokia's Series 60 browser, and Google's Android platform. Webkit and its components

are known for being small and fast, having clean source code, and supporting the latest

standards for web content. JavaScriptCore provides powerful garbage collector, is

developed using object-oriented C++, is highly portable (depends only on standard C and

C++ libraries and a Unicode implementation). ECMAScript compliance and

compatibility with major ECMAScript implementations are other advantages.


20/89

6 Chapter 2

2.1 Webkit Architecture

WebKit began when Apple created a software forkof the KDE projects HTMLlayout

engineKHTML and KDE's JavaScript engine (KJS). KHTML and KJS were ported to

Mac OS X with the help of an adapter library and renamed WebCore and

JavaScriptCore.WebKit was first included with Mac OS X v10.3, and is available as a

software update forv10.2.7 and later. The Webkit has two following major components

2.1.1JavaScriptCore

JavaScriptCore is a framework that provides a JavaScript engine for WebKit

implementations, and provides this type of scripting in other contexts within Mac OS X.

JavaScriptCore is originally derived from KDEs JavaScript engine (KJS) library (which

is part of the KDE project) and the PCREregular expression library. Since forking from

KJS and PCRE, JavaScriptCore has been improved with many new features and greatly

improved performance.

2.1.2 WebCore

WebCore is a layout, rendering, and DOM library for HTML and SVG developed by the

WebKit project, originally developed by Apple as a fork of KHTML. It is licensed under

the LGPL. The WebKit framework wraps WebCore and JavaScriptCore, providing an

Objective-C application programming interface to the C++-based WebCore rendering

engine and JavaScriptCore script engine, allowing it to easily be referenced by Cocoa-

based applications; later versions also include a cross-platform C++ platform abstraction,

and various ports provide additional APIs.


21/89

Background 7

Fig 2.1: Webkit Architecture

WebCore can be divided into two principal areas: KWQ and KHTML.

KWQ - KWQ (pronounced "quack") is an adapter layer used to communicate with

KHTML. It is written in Objective C++. The KHTML engine used in Konqueror was

written on top of a cross-platform toolkit called Qt. KWQ is essentially an

implementation of the subset of Qt required to make KHTML work on OS X

WebKit

WebCore JavaScript

CoreKWQ

KHTML

CSS DOM ECMA XML HTML Render MISC


22/89

8 Chapter 2

KHTML - KHTML is the layout engine and contains all of the code for constructing and

rendering HTML and XML. This code is written entirely in C++, with the exception of

some glue code that communicates with WebKit (using Objective C++).

2.2 ECMA ScriptECMAScript is an object-oriented programming language for performing computations

and manipulating computational objects within a host environment. ECMAScript as

defined here is not intended to be computationally self-sufficient; indeed, there are no

provisions in this specification for input of external data or output of computed results.

Instead, it is expected that the computational environment of an ECMAScript program

will provide not only the objects and other facilities described in this specification but

also certain environment-specific host objects, whose description and behaviour are

beyond the scope of this specification except to indicate that they may provide certain

properties that can be accessed and certain functions that can be called from an

ECMAScript program.

2.2 Mobi Linux

Mobilinux is an optimized Linux operating system and development environment, ideally

suited for wireless handsets and mobile devices, with requirements for power

management, hard real-time performance, fast start-up, and small footprint. MontaVista

engineered Mobilinux. Its based on Linux 2.6 kernel and supports high resolution

POSIX timers and O(1) Real-time Scheduler with up to 1024 levels of priority. With

Mobilinux, handset manufacturers have the freedom to differentiate throughout the

software stack and add the functionality necessary to address the needs of their mark with

delivering unique devices into the market.


23/89

Background 9

2.2: MobiLinux Architecture (courtesy of MontaVista Software, Inc.)


24/89


25/89

Chapter 3

SERVICE ORIENTED ARCHITECTURE

Service Oriented Architecture is an architectural paradigm and discipline that

may be used to build infrastructures enabling those with needs (consumers) and those

with capabilities (providers) to interact via services across disparate domains of

technology and ownership. Services act as the core facilitator of electronic data

interchanges yet require additional mechanisms in order to function. Several new trends

in the computer industry rely upon SOA as the enabling foundation. These include the

automation of Business Process Management (BPM), composite applications

(applications that aggregate multiple services to function), and the multitude of new

architecture and design patterns generally referred to as Web 2.0

The latter, Web 2.0, is not defined as a static architecture. Web 2.0 can be generally

characterized as a common set of architecture and design patterns, which can be

implemented in multiple contexts. The list of common patterns includes the Mashup,

Collaboration-Participation, Software as a Service (SaaS), Semantic Tagging


26/89

12 Chapter 3

(folksonomy), and Rich User Experience (also known as Rich Internet Application)

patterns among others. These are augmented with themes for software architects such as

trusting your users and harnessing collective intelligence. Most Web 2.0 architecture

patterns rely on Service Oriented Architecture in order to function.

When designing Web 2.0 applications based on these patterns, architects often have

highly specialized requirements for moving data. Enterprise adoption of these patterns

requires special considerations for scalability, flexibility (in terms of multiple message

exchange patterns), and the ability to deliver these services to a multitude of disparate

consumers. Architects often need to expand data interchanges beyond simple request-

response patterns and adopt more robust message exchange patterns, triggered by

multiple types of events. As a result, many specialized platforms are evolving to meet

these needs.

3.1 An Introduction to Service Oriented Architecture

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing

distributed capabilities that may be under the control of different ownership domains and

implemented using various technology stacks. In general, entities (people and

organizations) create capabilities to solve or support a solution for the problems they face

in the course of their business. It is natural to think of one persons needs being met by

capabilities offered by someone else; or, in the world of distributed computing, one

computer agents requirements being met by a computer agent belonging to a different

owner. The term owner here may be used to denote different divisions of one business or

perhaps unrelated entities in different countries.

There is not necessarily a one-to-one correlation between needs and capabilities; the

granularity of needs and capabilities vary from fundamental to complex, and any given


27/89

Service Oriented Architecture 13

need may require a combination of numerous capabilities while any single capability may

address more than one need. One perceived value of SOA is that it provides a powerful

framework for matching needs and capabilities and for combining capabilities to address

those needs by leveraging other capabilities. One capability may be repurposed across a

multitude of needs. SOA is a view of architecture that focuses in on services as the

action boundaries between the needs and capabilities in a manner conducive to service

discovery and repurposing.

3.2 A Reference Model for Service Oriented Architecture[1]

As with any other architecture, Service Oriented Architecture can be expressed in

a manner that is decoupled from implementation. Software architects generally use

standardized conventions for capturing and sharing knowledge. This group of

conventions is often referred to as an Architecture Description Language (ADL). There

are also several normalized artifacts used to facilitate a shared understanding of the

structure of a system, its major components, the relationships between them, and their

externally visible properties. This white paper will make use of two special types of these

artifacts aReference ModelandReference Architecture.

A Reference Model is an abstract framework for understanding significant entities and

relationships between them. It may be used for the further development of more concrete

artifacts such as architectures and blueprints. Reference models themselves do not

contain a sufficient level of detail sufficient to enable the direct implementation of a

system. In the case of a reference model for SOA, the Organization for the Advancement

of Structured Information Systems (OASIS) has a standard Reference Model for SOA,

shown in Figure 2.1 that is not directly tied to any standards, technologies, or other

concrete implementation details.


28/89

14 Chapter 3

In order for SOA to be meeting these challenges, services must have accompanying

service descriptions to convey the meaning and real world effects of invoking the service.

These descriptions must additionally convey both semantics and syntax for both humans

and applications to use.

Each service has an interaction model, which is the externally visible aspect of invoking

a service. This will be decomposed further to examine the data service aspects of SOA.

Fig 3.1: The core OASIS Reference Model for Service Oriented Architecture

(courtesy of OASIS)

Visibility and Real World Effect are also key concepts for SOA. Visibility is the

capacity for those with needs and those with capabilities to be able to see and interact

with each other. This is typically implemented by using a common set of protocols,

standards, and technologies across service providers and service consumers. For

consumers to determine if they can interact with a specific service, Service Descriptions


29/89


provide declarations of aspects such as functions and technical requirements, related

constraints and policies, and mechanisms for access or response. The descriptions must

be in a form (or can be transformed to a form) in which their syntax and semantics are

widely accessible and understandable. The execution context is the set of specific

circumstances surrounding any given interaction with a service and may affect how the

service is invoked.

Since SOA permits service providers and consumers to interact, it also provides a

decision point for any policies and contracts that may be in force. The purpose of using

a capability is to realize one or more real world effects. At its core, an interaction is an

act as opposed to an object and the result of an interaction is an effect (or a set/series

of effects). Real world effects are, then, couched in terms of changes to this shared state.

This may specifically mutate the shared state of data in multiple places within an

enterprise and beyond.

The concept of policy also must be applicable to data represented as documents and

policies must persist to protect this data far beyond enterprise walls. This requirement is a

logical evolution of the locked file cabinet model which has failed many IT

organizations in recent years. Policies must be able to persist with the data that is

involved with services, wherever the data persists.

A contract is formed when at least one other party to a service oriented interaction

adheres to the policies of another. Service contracts may be either short lived or long

lived.


30/89

16 Chapter 3

3.3 Decomposing the Interaction Model

Whereas visibility introduces the possibilities for matching needs to capabilities (and vice

versa), interaction is the act of actually using a capability via the service. Typically

mediated by the exchange of messages, an interaction proceeds through a series of

information exchanges and invoked actions. There are many facets of interaction; but

they are all grounded in a particular execution context the set of technical and business

elements that form a path between those with needs and those with capabilities.

Architects building Rich Internet Applications (RIAs), are faced with special

considerations when

designing their

systems from this

perspective. The

concept of Mashups

surrounds a model

whereby a single

client RIA may

actually provide a

view composed by

binding data from

multiple sources

persisting in multiple

domains across many

tiers.


31/89


Fig 3.2: a decomposition of the interaction Model (courtesy of OASIS Reference

Model for SOA )

As depicted in Figure 3.2, the interaction model can be further decomposed into a data

model and behavior model. The data model is present in all service instances. Even if the

value is null, the service is still deemed to have a data model. The data models are

strongly linked to the behavior models. For example, in a Request-Response behavior

model, the corresponding data model would have two components the input (service

Request) data model and the output (serviceResponse) data model. Data models may be

further specialized to match the behavior model if it is other than Request-Response.

The behavior model is decomposable into the action model and the process model. The

sequence of messages flowing into and out of the service is captured in the action model

while the services processing of those signals is captured in the processing model. The

processing model is potentially confusing as some aspects of it may remain invisible toexternal entities and its inner working known only to the service provider.

3.4 A Reference Architecture for Service Oriented Architecture[1]

A reference architecture is a more concrete artifact used by architects. Unlike the

reference model, it can introduce additional details and concepts to provide a more

complete picture for those who may implement a particular class. Reference architectures

declare details that would be in all instances of a certain class, much like an abstract


32/89

18 Chapter 3

constructor class in programming. Each subsequent architecture designed from the

reference architecture would be specialized for a specific set of requirements. Reference

architectures often introduce concepts such as cardinality, structure, infrastructure, and

other types of binary relationship details. Accordingly, reference models do not have

service providers and consumers. If they did, then a reference model would have

infrastructure (between the two concrete entities) and it would not longer be a model.

The reference model and the reference architecture are intended to be part of a set of

guiding artifacts that are used with patterns. Architects can use these artifacts in

conjunction with others to compose their own SOA. The relationships are depicted in

Figure 3.3.

Fig 3.3: The Architectural frame work for SOA (courtesy of OASIS)


33/89


The concepts and relationships defined by the reference model are intended to be the

basis for describing reference architectures that will define more specific categories of

SOA designs. Specifically, these specialized architectures will enable solution patterns to

solve particular problems. Concrete architectures may be developed based upon a

combination of reference architectures, architectural patterns, and additional

requirements, including those imposed by technology environments. Architecture is not

done in isolation; it must account for the goals, motivation, and requirements that define

the actual problems being addressed.

While reference architectures can form the basis of classes of solutions, concrete

architectures will define specific solution approaches.

Architects and developers also need to bind their own SOA to concrete standards

technologies and protocols at some point. These are typically part of the requirements

process. For example, when building a highly efficient client side Mashup application, a

developer might opt for the

XML Remote Procedure Call (XML-RPC),

a watched folder being polled for content,

an email endpoint, and

other RESTviii style endpoints including plain old HTTP and HTTP/S.

Services may also be invoked by local consumers including environments like J2EE and

language specific interfaces (for example - Plain Old Java Objects or POJOs).

Each service invocation is often handed to a new instance of a service container. The

service container is responsible for handling the service invocation request for its entire

lifecycle, until either it reaches a successful conclusion or failed end state. Regardless of

its ultimate end state, the service container may also delegate responsibilities for certain


34/89

20 Chapter 3

aspects of the services runtime to other services for common tasks. These tasks typically

include logging functions, archiving, security, and authentication, among others.

To facilitate orchestration and aggregation of services into processes and composite

applications, a registry-repository is often used. During the process design phase, the

registry-repository provides a single view of all services and related artifacts. The

repository provides a persistence mechanism for artifacts during the runtime of processes

and workflows. If multiple system actors use and interact with a form, the repository can

persist while allowing access to privileged individuals.

3.5 Client Tier

While much attention has been focused on the server side aspects of SOA, less

has been written about the new breed of clients evolving for consuming services. The

clients have evolved to embrace many common architecture and design patterns

discussed in greater detail in the next section. A highly visible example of this is the

ability of most modern browsers to subscribe to RSS feeds.

Fig 3.4: Client application architecture(courtesy of OASIS)

As depicted in Figure 2.4, clients must have far more robust communications services

than a decade ago. In fact, any communication standards, protocols and technologies


35/89


(such as SOAPix, ActionScript Messaging Format, or XML-RPC) have to be

implemented on both sides to facilitate proper communications. Client side

communications buses also need to monitor the state of communications including

potentially both synchronous and asynchronous exchange patterns.

The main controllerof each client application must be capable of launching variousruntime environments. This is typically done via launching one or more virtual machinesthat can interpret scripting languages or consume bytecode as in Adobe Flash. The

architecture for these virtual machines varies greatly depending upon the language used.

Some compile an intermediate level bytecode just in time to run a program while others

must be launched and make multiple passes over a script (usually once to check it for

errors, another time to run the script, and a concurrent iteration to collect garbage and

free up memory as it becomes possible to reallocate.

Most modern clients have some form of data persistence and state management. This

usually works in conjunction with the clients communications services to allow the

controller to use cached resources rather than attempting to synchronize states if

communications are down. Additionally, rendering and media functionality specific to

one or more languages is used to ensure the view of the application is built in accordance

with the intentions of the application developer.

The security models used by different clients also vary somewhat. The usual tenets are to

prevent unauthorized and undetected manipulation of local resources. In distributed

computing architectures, identity (knowing who and what) is a major problem that

requires a complex architecture to address. Each client side application must be

architected in accordance with the acceptable level of risk based on the user

requirements.


36/89

22 Chapter 3

3.6 Architectural Conventions Spanning Multiple Tiers[1]

While examining the client and service tiers of the reference architecture, developers will

note some commonalities. Architects need to employ common models for determining

what constitutes an object, what constitutes an event, how an event gets noticed or

captured, what constitutes a change in state, and more. As a result, architecture must take

note of several common architectural models over all tiers of modern SOAs.

First and foremost, the core axioms of service oriented architecture should be observed.

Services themselves should be treated as subservient to the higher level system or

systems that use them. If you are deploying services to be part of an automated process

management system, the services themselves should not know (or care) what they are

being used for. Services that are designed otherwise are architecturally inelegant for a

number of reasons.

First, if services were required to know the state of the overall process, state

misalignment would likely result if two services had differing states for even a fraction of

a second. In such instances, errors might be thrown when this is detected or worse,

developers would have to rely on using a series of synchronous calls to services rather

than forking a process into asynchronous calls. As depicted in Figure 2.5, services should

remain agnostic to what they are used for. The state of a process or other application

using services should be kept within the higher layer of logic that uses consumers to

invoke the services


37/89


Fig 3.5: Service within overall architecture (courtesy of OASIS)

Second, if the overall process stalled or failed for some reason, each service used wouldhave to be notified and rolled back to a previous state. Having services maintain or store

the overall state of a process that uses more than one service is an anti-pattern of SOA

and should be avoided.

Another core architectural convention is to keep the service consumers agnostic to how

the services are delivering their functionality. This results in a clean decoupling of

components, another architecturally elegantfeature of modern service oriented systems.

Having dependencies on knowing the internal working of the services functionality is

another anti-pattern of SOA and should also be avoided.

3.7 ServicecompositionThe act of building an application out of multiple services, is likewise an anti-pattern of

SOA, if composition is defined as per Unified Modeling Language (UML) 2.0x.

Composition is depicted as a has a relationship and the whole is composed of the parts.

The correct terminology should be service aggregation.Aggregationis a uses a type of

relationship. The differences are quite subtle but nevertheless important to grasp. In

composition relationships, the life cycles of parts are tied to the lifecycle of the whole and


38/89

24 Chapter 3

when the whole no longer exists, the parts no longer exist either. In aggregation, the parts

exist independent of the whole and can go on living after the entity that uses them no

longer exists. This terminology is common within both OOPSLAxi and UML.

Regardless, the term service composition has been misused widely within the computer

industry and will likely prevail as a norm. Architects and developers should pay close

attention to the types of binary relationships between components in loosely coupled,

distributed systems and bear these definitions in mind.

3.7.1 Request-Response

Request-Response is a pattern in which the service consumer uses configured client

software to issue an invocation request to a service provided by the service provider. The

request results in an optional response, as shown in Figure 3.6.

Fig 3.6: SOA Request-Response pattern(courtesy of Adobe)

3.7.2 Request-Response via Service Registry (or Directory)An optional service registry can be used within the architecture to help the client

automatically configure certain aspects of its service client. The service provider pushes

changes regarding the services details to the registry to which the consumer has

subscribed. When the changes are made, the service consumer is notified of these


39/89


changes and can configure its service client to talk to the service. This is represented

conceptually in Figure 3.7.

Fig 3.7: SOA Request-Response pattern with a service registry(courtesy of Adobe)

3.7.3 Subscribe-Push

A third pattern for interaction is called Subscribe-Push, shown in Figure 3.8. In this

pattern, one or more clients register subscriptions with a service to receive messages

based on some criteria. Regardless of the criteria, the externally visible pattern remains

the same.

Subscriptions may remain in effect over long periods before being canceled or revoked.

A subscription may, in some cases, also register another service endpoint to receive

notifications. For example, an emergency management system may notify all fire stations

in the event of a major earthquake using a common language such as the OASISxv

Common Alerting Protocol (CAP)xvi.


40/89

26 Chapter 3

Fig 3.8: SOA Subscribe-Push pattern(courtesy of Adobe)

Note that this pattern can be triggered by a multitude of events. In figure 3.8, an auditable event is triggering a message

being sent to a subscribed client. The trigger could be a service consumers action, a timeout action, or a number of other

actions that are not listed in the example above. Each of these represents a specialization of the Subscribe-Push pattern.

3.8 Data pushSome services offer data-push capability, enabling data to automatically be pushed to the

client application without polling (contrast this pattern to the Subscribe-Push pattern

listed above). This can be done via intuitive or inference methods to ensure data is

provided as required. This highly scalable capability can push data to thousands of

concurrent users, providing up-to-the-second views of critical data, such as stock trader

applications, live resource monitoring, shop floor automation, and more.

Data push can be further specialized into broadcast, unicast, multicast, and several other

specializations of the basic pattern.


41/89

Chapter 4

MOBILE SERVICE ORIENTED ARCHITECTURE

Mobile services hold a promise of utilizing the phone also for other purposes

than voice and SMS communication. Turning the promise into reality has been proven to

be more complex than what was anticipated in the dawn of digital mobile

communication. Offering highly usable, value adding services to consumers and

enterprise users has challenged the technology developers, business developers and the

mobile service concept developers. The mobile service field became divided into content

service and added value functional service. The main function of content service is to

deliver media contents such as ringing tones, greeting cards and background pictures into

the mobile phone. Such services were originally built on top of mobile messaging


42/89

28 Chapter 4

technology such as SMS and achieved continuously growing success in consumer

segment.

4.1 Problem StatementDifferent brands, run-time platforms, screen sizes, network and many other

factors all contribute to the fact that there is a large variety of mobile devices on the

market. To provide the best user experience, software developers of mobile applications

must specialize their software for specific devices in order to take advantage of device

specific features or device specific implementations of common features. A number of

problems with device specific software exist:

- A number of devices that can be supported by specialized software is much

smaller than the total number of devices. Specializing software for device

specific features in any way causes the potential target market to shrink

- Devices are sold on the market only for short periods of time and are generally

replaced by new devices months or at most a year after their introduction on the

market.

- Developing software for a group of similar devices with a common set of specific

features requires testing the software on all these devices

- Device specific software may be hard to port to other devices that do not support

the device specifics

The goal of mobile service is to allow users to access these services

through a mobile device. It means that a mobile service consists of a client-side

component and a server-side Component. The server-side component offers a set of

features then the client side component makes it available to the user and at the same

time also offers some device specific features like context, and location specific

information back to the server-side. Necessarily, features and usability of those features

in the client-side component depend strongly on the capabilities of the client device.


43/89


Mobile service oriented architectures need to address the following goals

-Number of devices. The service must be provided on a wide variety of mobile

devices. The more devices it supports, the larger the market is.

- Native features. The service must make full use of native features. Native

features add value to the phone and therefore to the services provided on that

phone. Native features include both software and hardware features. Native

features relevant to the service should be preferably be used.

- Time to market. The service must have a quick time to market. It is important to

reach the market before the competition

Architectural Drivers:

As the processing capability of the terminal devices has kept growing and faster

data protocols that have been deployed in the mobile networks, it has become feasible to

closely emulate the user experience of a PC with fast Internet access. The recent devices

included HTML browser that are capable of displaying dynamic HTML pages with

interactive scripts. Browser based services are evolving rapidly as the capability of the

terminal is growing. Another approach to offer highlyusable mobile services applications

is to open the phone software platform for user installable native applications. A user

installable application has access to all phone resources and can integrate with the native

UI with no restrictions. A challenge in this approach is to ensure the compatibility of the

phone software platform and installed applications.

The third approach is installing a device layer framework on the mobile which

provides a platform independent interface to the browser. So the user can use all the

capabilities provided by the browser apart from what is offered by device layer frame

work. The device layer frame work takes care of all the device restrictions and portability

problems. The restriction of this approach is the availability of an open source browser.


44/89

30 Chapter 4

The browser can explore the device layer features either as pluggable component or

adding as a new JavaScript object.


45/89

Chapter 5

CLIENT-SERVER WITH MOBILE THIN CLIENT &BROWSER

The browser based approach has been very successful in the Internet and PC

world. The emergence of de facto browser functionality and technologies like browser

side scripting has improved the user acceptance of these services significantly.

Nowadays, developing browser based services for mobile clients are facing similar

problems in many ways.

As developing browser based services for the pc in the nineties: But rapid advances can

be observed in mobile browsers. Despite this, its not always possible to apply the user

interface patterns of the pc world tothe mobile world. The screen size requires different

approaches to efficiently present Information and allow user to work with the on screen

information effectively.


46/89

32 Chapter 5

A browser based implementation of the service can rely on the client side mobile service

framework to provide the required service components. Integration to the local phone

resources can be restricted through the device layer framework. The interaction between

the device layer framework and browser can be facilitated through browser plug in

component or through a new Asynchronous JavaScript object.

- Usability. Usability of an individual browser based service can be reasonably

good for suitable applications. Typically, applications where the interaction

between user and application is based on a forums paradigm fit well to the

browser client architecture. High graphical user interfaces using direct

manipulation paradigms are difficult to implement within a browser but emerging

technologies like the AJAX will offer some level of support. Since the service

components and resource are controlled by the device layer framework and also

off-line operation that are possible with the help of the device layer frame work.

A limitation is that an open source browser is required for modification.

- Portability. The client side portability obstacles can be restricted within the

JavaScript object. Even so, the architect of a browser based mobile service is

forced to select between many alternative technology stacks that are largely

incompatible with each other. The new HTTP/HTML capable device generations

offer the same PC features with the added advantage of mobility factor.

- Deployability. It includes normal deployment and configuration of the device

layer framework and server side components. A phone equipped with the device

layer framework installed and a browser that is compatible with the service can

start using services immediately. Any registration and authentication functions

can be taken care inside the browser session.

- Scalability. The scalability in capacity of browser based architectures can be

controlled by device layer framework and by the traditional design solution of the


47/89

Client-Server With Mobile Thin Client & Browser 33

server side. This involves two main areas: the scalability of access to the service

and the scalability of the device layer framework. The business scalability of

browser based architecture is very good. One can start with a low capacity server

solution and increase the capacity gradually as the service become more popular.


48/89


49/89

Chapter 6

IMPLEMENTATION ARCHITECTURE


50/89

36 Chapter 6

Fig 6.1: Porting Specific MSOA Implementation Architecture

The architecture composed mainly three components in addition to a shared memory.

6.1 Mobile Browser:A JavaScript object is added into the existing browser domain. When implemented,

the browser will support a new SOAJavaScript object and can be instantiated using

Mobile Browser

SOAJSObject

Shared library

SOAIntShared

memory

Application Request Queue

Application Response Queue

Service

Manager

Device

ManagerContext

Manager

Call

Service

Web

Service

RIL

InterfaceCall

Interface

Weps

MSOA

TransportTAPI Http

Stack

SOA

Object


51/89

Implementation Architecture 37

the new operator. The browser will create the SOAJavaScript object which in turn

try to load the shared library and will call the exported factory methods. The

invocation of this method will return an SOAInterface interface which refers to the

Proxy JavaScript object , instantiated by the shared library .The SOAJavaScript

Object registers a call back with the Proxy JavaScript Object through

IJavaScript interface .On a push from the device layer daemon, a call back function

is invoked. The Java Script object in turn will create a DOMEvent with attributes and

initialized. The propagation and handling of this event will result in the invocation of

user defined JavaScript call back function.

6.2 Shared Library:The shared library act as the bridge for inter-process communication between the

browser and the device layer Daemon. On the very first loading, it will map the

shared memory to it. The library exports factory methods to create a proxy

JavaScript object which is liable for creating a new service object in the Daemon. It

also exports a set of methods to register the browser application with the Device

Layer daemon. Each SOAJavaScript object will try to load this library; if its not

already loaded and obtain a handle to factory method. It contains the ProxyMailBox

object. The ProxyMailBox implements the SOAInterface interface. It supports

synchronous and asynchronous access to shared memory with the help of mutexes.

The Proxy JavaScriptobject translates each request from the SOAJavaScript

object into a general packet format and transfers to the device layer SOA object. The

packet will contain the SOAobjectId and is capable of holding any number of

arguments. Depending on the command type, the access mechanism is chosen. The

notification to the Daemon is implemented using a semaphore. The shared library

provides a thread which is always waiting for an asynchronous response from the


52/89

38 Chapter 6

Daemon. On an asynchronous response from the Daemon, the ProxyMailBox will

invoke the call back function.

6.3 Device Layer Daemon:The area inside dashed lines represents the Device Layer Daemon The Service

Daemon will be loaded on device boot up. On loading, it maps the shared memory in

to its work space. The service daemon implements the Device layer functionalities.

Corresponding to each SOAJavaScript object in the browser, one SOAobject is

created in the Daemon.

6.4 Shared Memory:Here, we use two types of shared memories; one is shared among all applications

and other is allocated for each process which interacts with the device layer daemon.

The Process Registrationmemory is shared among all applications through which

each process registers with the daemon. The memory allocated for each process

consists of two segments: Request Memory and Response Memory. The packed

messages from the ProxyJSObject object are written into the Request area and the

corresponding responses from SOA Object are written into the Response area. This

implementation restricts one write at a time through the both the memory, the next

write operation can only be done after the first written data has been read by the

intendant.


53/89

Chapter 7

IMPLEMENTATION DETAILS INCLUDING PORTING

7.1 Existing Implementation

At Present, a Windows Mobile Implementation of Device layer frame work exists. The

lack of an open source browser in windows is one of the major obstacles for providing a

browser based implementation. In the Windows Mobile Implementation, a native client

application can only be the end user for SOA framework. Since its a Herculean task to

provide the capabilities of a browser in a native application. It has to take care of the

device specific properties such as limited GUI features. The availability of an open


54/89

40 Chapter 7

source browser in Linux is one of the attractive features. The MSOA provides a set of

services such as present services, web services, call services, location services, directory

services etc.Some of these services are device specific i.e. depends on protocol stack

implementation such as connectivity, HTTP etc but others are be device independent.

The porting work can be divided into two sets:

1 Purely OS Specific (Windows V/s Linux)

2 Device Specific

7.1.1 Purely OS Specific (Windows V/s Linux)

Since the picture is clear from the implementation architecture. In both

implementations, the SOA Interface to the outside world is exported through a shared

library (Its a .dll in windows and .so in Linux). Since the services are loosely-coupled,

independent to each other and independent to instance count, threading primitives are

brought into the picture. The application uses the MSOA framework, has to attach the

library into its own address space, an inter-process communication has also been brought

into picture. The existing Windows Mobile Implementation uses the IOCTL and

Windows Event mechanism for communication and synchronization. The WM

implementation uses a Request memory (to write requests from the application to device

layer framework) and a Response memory (through which the frame work writes

response back to the application). In WM implementation, memory mapped files are used

as shared memory. When the memory-mapped files are used for inter-process

communication, the name has to be shared among the applications. The sharing of name

raises the security vulnerability, an intruder who is aware of the public name can tap the

secured enterprise data. To alleviate the security vulnerability threat and to extend

multiple process interaction in an independent way, Linux implementation provides pre-

process shared memory to applications so that one process doesnt want to get queued

due to other applications slow performance. Sine two different applications cant use an


55/89

Implementation Details Including Porting 41

IPC mechanism with out a shared name; we too use the same but restrict it in a way as

its only used for a process registration.

Every application which wants to use the MSOA, has to register with the framework

through the registration memory. Its a kind of hand-shaking in which the application and

the device layer framework reaches on agreement of Response memory Id, Request

memory Id and semaphore set for synchronization. The Read/Write permissions of the

Registration Memory, Request Memory and Response Memory are provided in such a

way that no other process can tap another processs confidential data. Since the name is

chosen dynamically at run time and restriction in access permission both ensures that an

intruder cant tap the information. But it still has some of the vulnerability that data can

be distorted but chances are less due to dynamic name fixing. Shared memory in Linux is

chosen as the candidate for IPC due to the fact that its the fastest IPC mechanism

available in Linux. Considering the portability factor into other platforms, a semaphore

based protocol implementation will be the right choice to implement communication

protocol. Both synchronized and asynchronized communication should be there to

support MSOA functionality. It can also be initiated from both ends. The rest includes

threading primitives, synchronization, IPC (shared memory), and daemons. The windows

specific code uses Events, Mutexes. When used in one of the wait functions, timeout

value can be specified for Windows semaphore objects. This is not provided for Linux - it

needs to be handled in the application logic only. An unnamed POSIX semaphore can be

used between threads of the same process. System V semaphore can be used between

threads of different process. This is used to achieve the functionality of a Windows

named semaphore.

The following points should be considered during migration:

Windows provides named and un-named event objects. Named event objects are

provided for synchronization between processes, but in Linux, both the pthreads and


56/89

42 Chapter 7

POSIX provides synchronization between threads. To achieve functionality of named

event objects in Linux, System V semaphore or signals can be used.

Windows provides two types of event objects - manual and auto-reset. Linux

provides only auto-reset event features

In Windows, event objects initial state is set to signaled. In Linux, pthreads does

not provide an initial state, but POSIX semaphores provide an initial state.

Windows event objects are asynchronous. In Linux, POSIX semaphores and

System V semaphores are asynchronous but pthreads conditional variables are

not asynchronous.

It is also important to note that:

POSIX semaphores are count semaphores, but when the count is set to 1 they

provide similar functionality to the Windows event object. They don't provide

timeout in the wait functions. POSIX semaphores are preferred when the timeout

is not the factor in the porting.

When used along with the Mutex, pthreads, conditional variables provide event-based

synchronization between threads, but they are synchronous. Based on the applicationlogic, this can be selected as a choice for implementing the functionality on Linux during

porting.

7.1.2 Device SpecificThe MSOA makes use of some device specific functionalities such as HTTP

based services, Telephone API based services and some context specific information such

as cellId, connectivity status and imei number. In Windows Mobile, the Radio Interface

Layer provides the APIs for connectivity status, CellId and imei number etc. The RIL


57/89


interface provides asynchronous replies to queries and provides notification call backs on

events such GPRS connected, disconnected , new base station is registered etc. The

context manager, device manager is using the RIL interface for context updating in

Windows Mobile Implementation. The Mobilinux port of Motorola provides a TAPI

library in which both synchronous/ asynchronous reply and asynchronous notifications

are supported. Most of the context specific APIs used in RIL are asynchronous . The

porting work tries to provide a RIL interface on top TAPI which will be similar to the

RIL interface in signature but all the device specific things are buried under RIL interface

so that it can be viewed as a pluggable component that makes further porting to any

platforms much easier. The synchronous v/s asynchronous responses to queries are taken

in to account in the Linux implementation. In case of HTTP/HTTPS services, the

windows, a WinINet function provides internet connectivity APIs using this. We have to

start internet connection and then uses HttpOpenRequest to open an http connection.The WinINet only provides synchronous API for http ssrvices. The Mobilinux port of

Motorola provides a Weps API which offers both synchronous and asynchronous access

to http/https services. In the linux port, asynchronous mechanism is used for reducing

the number of threads. The Microsoft Windows Telephony API (TAPI) allows

applications to support telephone communication. TAPI facilitates include Connecting

directly to a telephone network, Automatic phone dialing, Transmission of data (files,

faxes, electronic mail), Access to data (news, information services), Conference calling,

Voice mail, Caller identification, Control of a remote computer, Collaborative computing

over telephone lines .etc. In the Linux port, the TAPI in Mobi Linux port provides both

call service and RIL services. As in the case of RIL interface provided, one another call

interface is provided, which hides the internal implementation and provides

functionalities which relevant to the MSOA adding the advantage that the same can also


58/89

44 Chapter 7

be treated as pluggable unit where interface remains same and implementation differ for

various platforms.

7.2 Mobile Browser Implementation

DOMObjectObjectImp

KJS_Window

MSOAEvent MSOAEvent Impl

EventImplEvent

1n 1n

SOAJavaScriptConstructorImp

DocumentImpl

SOAJavaScriptProto Func

JSEventListener

Document1

1

1

1

1

n

1

n

MailBoxListenerDllHandler

JSAbstractEventListener

Listener

ISOA

SOAJavaScript

1

1

1

1

1

1

1

1

1

1

1

1

1

n

1

n

1..11..1

11

11

Fig 7.1: WebKit JavaScript Object Addition [class diagram]

The open source Webkit code is modified to append our new SOAJavaScript object into

the existing Java Script Object domain. The JavaScript Object act as the interface to

MSOA frame work. Apart from various set and get methods, it provides an onResponse

attribute. The JavaScript programmer can assign his own JavaScript function as a call

back function. Whenever there is a response from the device layer daemon, the call back

function will get executed. The call back function is implemented as a DOMEvevnt. The

class diagram is shown in fig..


59/89


7.3 Communication b/w Shared Library and Device Layer

Fig. 7.2 Mobile SOA Communication Architecture

SOAJavaScriptObject 2


Dll Handler

SOAJavaScript Object 3


Dll Handler

Reg Listening

Thread

Communication Thread

SOA1 SOA2 SOA3 SOA4

Requestmem1

Responsemem1

SOAinterf

Process

Reg mem

Requestmem2

Responsemem2

SOAInterf


60/89

46 Chapter 7

Whenever a new SOAJavaScript Object is created, the browser will in turn try to register

it with the device layer daemon if it is not already registered. The shared library creates

its own response memory with its having the read permission and others have write

permission. It also creates the semaphore set for synchronization and writes this IDs into

registration memory that can be read only form device layer. The device layer in turn

creates request memory that can be read only form device layer. It write backs the ID of

request memory to the shared librarys response memory so that it can only read that

information. The further communication can be done through this newly created request

and response memory. Further request from SOAJavaScript object are packed and

communicated through request memory. The corresponding responses are packed at

daemon side and conveyed trough response memory. The asynchronous and synchronous

communication protocol in terms of semaphore is depicted in fig 6.4


61/89


Proxy Synch

T

Proxy Async

T

cReqWrite

M=1

cRespSync

Read M=0

cRespAsyn

c Read M=0

Req Mem Resp Mem sReqRead

M=0

sRespWrite

M=1

Server Sync

T

ServerAsync

T

1: Wait

3: write

4: signal

5: Wait

2: wait

6: Read

7: Wait

8: Write

9: Signal

10: Read

11: Signal

12: Signal

13: Wait

14: Wait

15: Write

16: Signal

17: Read

18: Signal

20: Wait

19:

21: write

22: Signal

24: Read

23: Wait

25: Signal

26: Signal

Fig 7.3: Communication protocol in terms of semaphores


62/89

48 Chapter 7

Browser Shared

Library .so

proxy java

script object

Client

Respo...

Client Request

Writing Thread

Client

requ...

Semaphore

set

Process Reg

istration memory

Response

memory

Request

MemoryDLresponse

Queue

DL request

Listen...DLresponse

Writing Thread

SOA object

Proc Registration

ListeningThread

Device

La...1: create process registration memory

2: createThread

3: doDaemoninitilization

4: Wait for newprocess registration

6: initLibrary

5: LoadLibrary

7: Mapregistration memory

8: create ResponseMemory

9: createsemaphore set

10: write process registrationrequest ID(Resp mem, Semaphore)

11: wait for registration response

12: read registration request, ID(resp mem,semaphore)

13: map ResponseMemory

14: map Semaphores

15: create request memory

16: create Q

17: create Thread

19: create Thread

18: wait for Requests

20: wait on ResponseQ

21: write registrationresponse ID(request mem)

22: ReadRegistration resp ID( Req mem)

23: Map Request Memory

24: wait on ResponseMemory

26: create Thread

25: create Queue

27: create thread

28: wait on this Q

29: create SOAJavaScript Object

30: write create SOAJavaScript request

31: readrequest

32: create SOAobject

33: write soaobject creation status

34: read response

35: create client mailbox

36: returnsoaInterface

37: proxyobject.sendMessage

38: insert request

39: Q.popFront

40: write sendMessage request

41: readrequest

42: SOAobject.insertRequest

43: insert Response

44: Q.popFront

45: write Response

46: readResponse

47: insert response

48: proxyJSobject.notif yResponse

49: proxyJSobject.deleteInstance

50: write deleteInstance request

51: readrequest

52: deleteSOAobject

53: deletethis

54: terminateLibrary

55: writr unregister process request

56: readrequest

57: unregister this process

58: closerequest memory

59: free ResponseQ

60: close thread

66: close thread

61: free Q

64: free Thread

65: free Thread

67: unload library

62: free semaphoreset

63: free response memory

Fig 7.4 Overall Communication [Interaction Diagram]


63/89


7.4 Porting ImplementationAs discussed in porting section, using Macro definition, the corresponding APIs in

windows and Linux are mapped. That code logic which cant be simply mapped isrewritten with the help of compiler directives. Using the new adapter interfaces (RIL

Interface, Call Interface and Weps) the device specific part is ported.

CallSvc

CallInterface

n

1

n

1

deviceManager

ContextManager

RILInterface

n

1

n

1

n

1

n

1

MSOTransportProvider

1n

1n

1

nn

1

Fig 7.5: Porting Class Diagram


64/89


65/89

Chapter 8

TESTING

8 .1 Testing Strategy

Software testing is the process used to assess the quality of computer software. Software

testing is an empirical technical investigation conducted to provide stakeholders with

information about the quality of the product or service under test , with respect to the

context in which it is intended to operate. This includes, but is not limited to, the process

of executing a program or application with the intent of finding software bugs. In MSOA,

the following components have to be tested independently.

1. The browser

2 Shared Library

3 Device Layer Daemon

Since the Shared Library and Device Layer Daemon do not have any terminal; their

results can only be viewed from there logs. The browser is only having the terminal

interface. The MSOA services are defined in the Atom Syndication Format. The test

input to the browser is java scripts.

The browser can be tested by providing a loop back kind of hard coded stuff. Instead of

communicating with library the browser will loop back responses to send Message after

sleeping for some time. Once the browser test is over it can be used for testing both

shared library and daemon.


66/89

52 Chapter 8

Fig 8.1: Browser Testing

The shared library and daemon can be tested together because its a

communication protocol contains lot of inter-process communication. By setting the

device layer SOA object as a stub i.e. (with out invoking methods), the communicationprotocol can be verified.

Fig 8.2: Communication Testing

Once the communication protocol is verified we can test the service manager by

each service will return hard coded responses to service requests with out invoking the

actual services.

Mobile Browser

Input

SOAJS

Object

Shared

Library

SOA

Object

Service

Manager

Context

manager

Callservic

Webservic

Mobile Browser

InputSOAJS

Object

Shared

Library

SOA

Object

Service

Manager

Context

manager

Call

servic

Web

servic


67/89

Testing 53

Fig 8.3: Service Manager Testing

Once the service manager is verified each actual service can be invoked and can be

verified.

Fig 8.4: Testing Individual Services

Verification can be done checking the responses and also verifying three logs. The logs

will contain time stamp and message unique Ids and SOA Object IDs wherever will be

relevant.

8.2 Test Documentation

8.2.1 SOAJavaScript object JavaScript Interface

Mobile Browser

Input

SOAJS

Object

Shared

Library

SOA

Object

Service

Manager

Context

manager

Call

servic

Web

servic

Mobile Browser

InputSOAJS

Object

Shared

Library

SOA

Object

Service

Manager

Context

manager

Call

servic

Web

servic


68/89

54 Chapter 8

Interface SOAJavaScript {

//event handlerattribute EventListener onresponse;// get methodsout Array getMessage(in long msgid);DOMString getMessageAsText( in long msgid);Document getMessageAsXML(in long msgId);DOMString getContentType(in long msgid);int getContentLength(in long msgid);DOMString getParameter(in long msgid, in DOMString paramName);int getStatus(in long msgId);

// set methodsvoid setData(in Array data);void setContentType(in DOMString ctype);void setContentLength(in int len);void setParameter(in DOMString paramName, in DOMString paramValue);void setMethod(in DOMString method);long sendMessage(in DOMString msg);void deleteMessage(in long msgid);}

8.2.2 Presence Service Input Script

var mboxvar msgIDvar presurifunction handleResponse(event){

if(event.messageId == msgID){

length = mbox.getContentLength(msgID)if(length>0)


69/89

Testing 55

{type= mbox.getContentType(msgID)if(type=="text/plain")

{msg= mbox.getContentAsText(msgID)if(msg == "ONLINE")

alert(presuri+"is Online")else

alert(presuri+"is Offline")}

}}

}

function validate(thisform){

if(window.XMLHttpMailBox){

mbox = new SOAJavaScript("usr","pwd")

mbox.onresponse=handleResponse()

mbox.setContentType(text/plain)

mbox.setContentLength(0)

presuri = Tpresenceuri.value;

//send a presence request

msgID=mbox.sendMessage(pres: )

}else{alert(" Your Browser does not support SOAJavaScript Object")

}


70/89

56 Chapter 8

}

Presence URI :

8.3 OUTPUT Screen Shots


71/89

Testing 57

8.4 Status

8.3.1 Work CompletedThe coding of following components has completed

1 Browser

2 Shared Library

Debugging of browser is completed.

Only the first level testing of browser is completed

8.3.1 Work Remaining

The coding of Device Layer Daemon is partial;


72/89

58 Chapter 8

The debugging of shared library can only be done along with daemon, so

its pending.

The Communication Testing, Service Manager Testing and Individual Services

testing are remaining

8.4 Testing StatusThe browser testing is successful


73/89

Chapter 9

LEARNING FROM IMPLEMENTATION

1. Identified the usage of various design patterns in programming.

2. Identified the roles of various quality attributes like performance,

availability, security, interoperability, modifiability, portability, integrability

and testability in large scale system design.

3. Understood the importance of programming to an Interface than to an Object.

4. Learned the things to be taken into account while programming with

multithreaded programs to avoid chaos.

5. Understood the need for following development life cycles.

6. Studied how real time operating systems are incorporated in mobile devices.

7. Identified the vast scope of SOA in mobile devices.

8. Identified the real truth; academic pass out is not the end of the road but

actual journey starts from there!


74/89


75/89

CONCLUSIONThe enterprise solution vendors have yet to fully address the mobile enterprise

applications market for cell phones connected to Enterprise Web Services. The

innovative techniques employed by the Mobile framework as well as the pro-active user

interface and the alignment with the SOA strategy prevalent in business applications,

make the Framework a viable solution that merits further development and support. A

large portion of operations currently performed by desktop applications can be performed

by mobile applications just as well.

We have implemented a Mobile Application Framework that supports servicesdefined in atom syndication format .It is compatible with all the latest industry standards

and makes migrating existing business systems to mobile devices as a feasible task. The

browser based implementation doesn't require intensive coding at the client side because

the JavaScript acts as the client language. The world of technology is clearly moving

towards wireless solutions and our mobile framework greatly contributes to this trend,

allowing ubiquitous data access and enabling the advent of a new generation of mobile

business.


76/89


77/89

Appendix A

Browser Architecture

The web browser is perhaps the most widely used software application in history. It has

evolved significantly over the past fifteen years; today, web browsers run on diverse

types of hardware, from cell phones and tablet PCs to desktop computers. Web browsers

are used to conduct billions of dollars of Internet enabled commerce each year. Reference

architecture for web browsers can help implementers to understand trade-offs when

designing new systems, and can assist maintainers in understanding legacy code.Comparing the architecture of older systems with the reference architecture can provide

insight into evolutionary trends occurring in the domain.

The web browser domain

The World Wide Web (WWW) is a universal information space operating on top of the

Internet. Each resource on the web is identified by a unique Uniform Resource Identifier

(URI) (Berners-Lee et al., 2005). Resources can take many different forms, including


78/89

64 Appendix A

documents, images, sound clips, or video clips. Documents are typically written using

HyperText Markup Language

(HTML) (Berners-Lee and Connolly, 1995; Raggett et al., 1999), which allows the author

to embed hypertext links to other documents or to different places in the same document.

Data is typically transmitted via HyperText Transfer Protocol (HTTP) (Berners-Lee et

al., 1996), a stateless and anonymous means of information exchange. A web browser is a

program that retrieves documents from remote servers and displays them on screen,

either within the browser window itself or by passing the document to an external helper

application. It allows particular resources to be requested explicitly by URI, or implicitly

by following embedded hyperlinks. Although HTML itself is a relatively simple language

for encoding web pages,

Other technologies may be used to improve the visual appearance and user experience.

Cascading Style Sheets (CSS) (Bos et al., 2006) allow authors to add layout and style

information to web pages without complicating the original structural markup.

JavaScript, now standardized as ECMAScript (, 1999), is a host environment for

performing client-side computations. Scripting code is embedded within HTML

documents, and the corresponding displayed page is the result of evaluating the

JavaScript code and applying it to the static

HTML constructs. Examples of JavaScript applications include changing element focus,

altering page and image loading behavior, and interpreting mouse actions. Finally, there

are some types of content that the web browser cannot display directly, such as

Macromedia Flash animations and Java applets. Plug-in, small extensions that are loaded

by the browser, are used to embed these types of content in web pages. In addition to

retrieving and displaying documents, web browsers typically provide the user with other

useful features. For example, most browsers keep track of recently visited web pages and

provide a mechanism for bookmarking pages of interest. They may also store


79/89


commonly entered form values as well as usernames and passwords. Finally, browsers

often provide accessibility features to accommodate users with disabilities such as

blindness and low vision, hearing loss, and motor impairments.

2.2 History and evolution

Although key concepts can be traced back to systems envisioned by Vannevar Bush in

the 1940s and Ted Nelson in the 1960s, the WWW was first described in a proposal

written by Tim Berners-Lee in 1990 at the European Nuclear Research Center (CERN)

(Berners-Lee, 1999). By 1991, he had written the first web browser, which was graphical

and also served as an HTML editor. Around the same time, researchers at the University

of Kansas had independently

Fig a.1- Browser evolution( courtesy ofICSM05 Proceedings)


80/89

66 Appendix A

begun work on a text-only hypertext browser called Lynx; they adapted it to support the

web in 1993. In the same year, the National Center for Supercomputing Applications

(NCSA) released a graphical web browser called Mosaic, which allowed users to view

images directly interspersed with text. As the commercial potential of the web began to

grow, NCSA founded an offshoot company called Spyglass to commercialize its

technologies and Mosaics

primary developer, Marc Andreesen, left to co-found his own company, Netscape. In

1994, Berners-Lee founded the World Wide Web Consortium (W3C) to guide the

evolution of the web and promote interoperability among web technologies. In 1995,

Microsoft released Internet Explorer (IE), based on code licensed from Spyglass, igniting

a period of intense competition with Netscape known as the browser wars. Microsoft

eventually came to dominate the market, and Netscape released its browser as open

source under the name Mozilla in 1998. Figure 1 shows a timeline of the various releases

of several prominent web browsers. Since 1998, several Mozilla variations have

appeared, reusing the browser core but offering alternative design decisions for user-level

features. Firefox is a standalone browser with a streamlined user interface, eliminating

Mozillas integrated mail, news, and chat clients. Galeon is a browser for the GNOME

desktop environment that integrates with other GNOME applications and technologies.

The open source Konqueror browser has also been reused: Apple has integrated its core

subsystems into its OS X web browser, Safari, and Apples modifications have in turn

been reused by other browsers. Internet Explorers closed source engine has also seen

reuse: Maxthon, Avant, and NetCaptor each provide additional features to IE such as

tabbed browsing and ad-blocking. Although each browser engine typically produces a

similar result, there can be differences as to how web pages look and behave; Netscape 8,


81/89


based on Firefox, allows the user to switch between IE-based rendering and Mozilla-

based rendering on the fly.

The reference architecture is shown in Figure A-2. It comprises eight major subsystems

plus the dependencies between them:

(1) The User Interface subsystem is the layer between the user and the Browser Engine. It

provides features such as toolbars, visual page-load progress, smart download handling,

preferences, and printing. It may be integrated with the desktop environment to provide

browser session management or communication with other desktop applications.

(2) The Browser Engine subsystem is an embeddable component that provides a high-

level interface to the Rendering Engine. It loads a given URI and supports primitive

browsing actions such as forward, back, and reload. It provides hooks for viewing various

aspects of the browsing session such as current page load progress and JavaScript alerts.

It also allows the querying and manipulation of Rendering Engine settings.

(3) The Rendering Engine subsystem produces a visual representation for a given URI. It

is capable of displaying HTML and Extensible Markup Language (XML) (Bray et al.,

2004) documents, optionally styled with CSS, as well as embedded content such as

images. It calculates the exact page layout and may use reflow algorithms to

incrementally adjust the position of elements on the page. This subsystem also includes

the HTML parser.

(4) The Networking subsystem implements file transfer protocols such as HTTP and

FTP. It translates between different character sets, and resolves MIME media types for

files. It may implement a cache of recently retrieved resources.


82/89

68 Appendix A

Fig a-2 Reference Architecture Browser( courtesy ofICSM05 Proceedings)(5) The JavaScript Interpreter evaluates JavaScript (also known as ECMAScript) code,

which may be embedded in web pages. JavaScript is an object-oriented scripting

language developed by Netscape. Certain Java- Script functionality, such as the opening

of pop-up windows, may be disabled by the Browser Engine or Rendering Engine for

security purposes.

(6) The XML Parser subsystem parses XML documents into a Document Object Model

(DOM) tree. This is one of the most reusable subsystems in the architecture. In fact,

almost all browser implementations leverage an existing XML Parser rather than creating

their own from scratch.

(7) The Display Backend subsystem provides drawing and windowing primitives, a set of

user interface widgets, and a set of fonts. It may be tied closely with the operating

system.

(8) The Data Persistence subsystem stores various data associated with the browsing

session on disk. This may be high-level data such as bookmarks or toolbar settings, or it

may be low-level data such as cookies, security certificates, or cache.


83/89

Appendix B

ECMA SCRIPT

Brief HistoryThis ECMA[2] Standard is based on several originating technologies, the most well

known being JavaScript (Netscape) and JScript (Microsoft). The language was invented

by Brendan Eich at Netscape and first appeared in that companys Navigator 2.0 browser.It has appeared in all subsequent browsers from Netscape and in all browsers from

Microsoft