venu report
TRANSCRIPT
-
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
-
8/8/2019 Venu Report
2/89
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
4/89
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
6/89
-
8/8/2019 Venu Report
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/8/2019 Venu Report
8/89
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
12/89
Brief History 69
Web Scripting 71
Language Overview 71
References 75
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
18/89
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
23/89
Background 9
2.2: MobiLinux Architecture (courtesy of MontaVista Software, Inc.)
-
8/8/2019 Venu Report
24/89
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
29/89
Service Oriented Architecture 15
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.
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
31/89
Service Oriented Architecture 17
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
-
8/8/2019 Venu Report
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)
-
8/8/2019 Venu Report
33/89
Service Oriented Architecture 19
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
35/89
Service Oriented Architecture 21
(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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
37/89
Service Oriented Architecture 23
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
39/89
Service Oriented Architecture 25
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.
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
43/89
Service Oriented Architecture 29
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.
-
8/8/2019 Venu Report
44/89
30 Chapter 4
The browser can explore the device layer features either as pluggable component or
adding as a new JavaScript object.
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
48/89
-
8/8/2019 Venu Report
49/89
Chapter 6
IMPLEMENTATION ARCHITECTURE
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
57/89
Implementation Details Including Porting 43
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
-
8/8/2019 Venu Report
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..
-
8/8/2019 Venu Report
59/89
Implementation Details Including Porting 45
7.3 Communication b/w Shared Library and Device Layer
Fig. 7.2 Mobile SOA Communication Architecture
SOAJavaScriptObject 2
SOAJavaScriptObject 1
Dll Handler
SOAJavaScript Object 3
SOAJavaScriptObject 4
Dll Handler
Reg Listening
Thread
Communication Thread
SOA1 SOA2 SOA3 SOA4
Requestmem1
Responsemem1
SOAinterf
Process
Reg mem
Requestmem2
Responsemem2
SOAInterf
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
61/89
Implementation Details Including Porting 47
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
-
8/8/2019 Venu Report
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]
-
8/8/2019 Venu Report
63/89
Implementation Details Including Porting 49
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
-
8/8/2019 Venu Report
64/89
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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)
-
8/8/2019 Venu Report
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")
}
-
8/8/2019 Venu Report
70/89
56 Chapter 8
}
Presence URI :
8.3 OUTPUT Screen Shots
-
8/8/2019 Venu Report
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;
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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!
-
8/8/2019 Venu Report
74/89
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
76/89
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
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
-
8/8/2019 Venu Report
79/89
Browser Architecture 65
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)
-
8/8/2019 Venu Report
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,
-
8/8/2019 Venu Report
81/89
Browser Architecture 67
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.
-
8/8/2019 Venu Report
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.
-
8/8/2019 Venu Report
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