P. 1
Venu Report

Venu Report

|Views: 10|Likes:
Published by santosh_bp

More info:

Published by: santosh_bp on Dec 26, 2010
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less






  • 3.5 Client Tier
  • 3.6 Architectural Conventions Spanning Multiple Tiers[1]
  • 3.7 Service composition
  • 3.7.1 Request-Response
  • 3.7.2 Request-Response via Service Registry (or Directory)
  • 3.7.3 Subscribe-Push
  • 3.8 Data push
  • Chapter 4
  • 4.1 Problem Statement
  • Chapter 5
  • Chapter 6
  • Fig 6.1: Porting Specific MSOA Implementation Architecture
  • 6.1 Mobile Browser:
  • 6.2 Shared Library:
  • 6.3 Device Layer Daemon:
  • 6.4 Shared Memory:
  • Chapter 7
  • 7.1 Existing Implementation
  • 7.1.1 Purely OS Specific (Windows V/s Linux)
  • 7.1.2 Device Specific
  • 7.2 Mobile Browser Implementation
  • 7.3 Communication b/w Shared Library and Device Layer
  • 7.4 Porting Implementation
  • Chapter 8
  • 8 .1 Testing Strategy
  • 8.2 Test Documentation
  • 8.2.1 SOAJavaScript object JavaScript Interface
  • 8.2.2 Presence Service Input Script
  • 8.3 OUTPUT Screen Shots
  • 8.4 Status
  • 8.3.1 Work Completed
  • 8.3.1 Work Remaining
  • 8.4 Testing Status
  • Chapter 9
  • Appendix A
  • Browser Architecture
  • The web browser domain
  • Appendix B


Submitted in partial fulfillment of the requirements for the Award of the degree of MASTER OF TECHNOLOGY

COMPUTER & INFORMATION SCIENCE By VENU R Under the Esteemed Guidance of
Mr. Ennai Anuraj
Senior Staff Engineer Motorola India Research Labs Bangalore

Mr. G Santhosh Kumar
Lecturer Dept. of Computer Science CUSAT

JUNE 2008


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 Jacob Professor & Head Of Department Dept. of Computer Science CUSAT

G Santhosh Kumar Internal Project Guide Lecturer Dept. of Computer Science CUSAT

technical support and guidance during the course of my project work.Sumam Mary Idicula and Mr. Senior Staff Engineer. Santhosh Kumar. consistent guidance and inspiration throughout the course of this investigation. constant encouragement. Professors. I express my sincere thanks to our H. I am extremely happy to thank Mr. Venu R .O.D. Lecturer. I am extremely happy to thank Mr Shrikant S Naidu for for his valuable suggestions. Motorola India Research Labs for his technical support. David Peter S. Above all I thank God Almighty for helping me to complete this work successfully. Paulose Jacob for being a great pillar to all our achievements. Prof. Department of Computer Science for his valuable suggestions and support during the course of the project work. I feel immense pleasure in thanking my guide Mr. G. Siddhartha Bose for his valuable suggestions. Dr. I am extremely happy to thank Dr. Ennai Anuraj Kunnummel.Acknowledgement I am greatly indebted to Mr. Department of Computer Science for their excellent guidance and valuable help rendered throughout this project in a versatile manner.


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.. emergence of WEB 2. 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. e.e..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. These services inter-operate based on a formal definition (or contract.g.0 technologies on a mobile device. This project aims to develop such a JavaScript Object on a RIA platform and use it to run SOA applications on the RIA platform. RIAs typically transfer the processing necessary for the user interface to the Web client but keep the bulk of the data (i. By integrating SOA and WEB 2.. WSDL) that is independent of the underlying platform and programming language.Abstract Rich Internet applications (RIA) are Web applications that have the features and functionality of traditional desktop applications . maintaining the state of the program. In recent times. thus supporting SOA control on the mobile device. RIA applications running on the mobile device can access SOA applications available from the device. . the data etc) back on the application server.


1.2 Mobi Linux 5 5 6 6 6 8 8 Chapter 3 SERVICE ORIENTED ARCHITECTURE 3.2 Motorola India Operations: 1.1 Organization Profile 1.4 A Reference Architecture for Service Oriented Architecture [1] [1] 11 11 12 13 16 17 .1.1.CONTENTS Acknowledgement Abstract INTRODUCTION 1.3 Motorola India Research Labs (MIRL): 1.1JavaScriptCore 2.1.1 An Introduction to Service Oriented Architecture 3.2 WebCore 2.1 Overview: 1.3 Decomposing the Interaction Model 3.1 Webkit Architecture 2.2 ECMA Script 2.2 A Reference Model for Service Oriented Architecture 3.2 Project Overview vii vii 1 1 1 2 2 2 Chapter 2 BACKGROUND 2.1. Problem Statement 27 27 28 Chapter 5 CLIENT-SERVER WITH MOBILE THIN CLIENT & BROWSER Chapter 6 IMPLEMENTATION ARCHITECTURE 6.1 Mobile Browser: 6.2 Device Specific 39 39 39 40 42 .1 Existing Implementation 7.1 Request-Response Shared Library: 6.1 Purely OS Specific (Windows V/s Linux) 7.6 Architectural Conventions Spanning Multiple Tiers [1] 20 22 23 24 24 25 26 3.7 Service composition 3.5 Client Tier 3.8 Data push Chapter 4 MOBILE SERVICE ORIENTED ARCHITECTURE 4.2 Request-Response via Service Registry (or Directory) 3.4 Shared Memory: 31 31 35 35 36 37 38 38 Chapter 7 IMPLEMENTATION DETAILS INCLUDING PORTING 7.3 Subscribe-Push 3.3 Device Layer Daemon: 6.

4 Testing Status 51 51 51 53 53 54 56 57 57 57 58 Chapter 9 LEARNING FROM IMPLEMENTATION CONCLUSION Appendix A Browser Architecture The web browser domain 59 59 61 63 63 63 Appendix B ECMA SCRIPT 69 69 .3 Communication b/w Shared Library and Device Layer 7.1 Work Completed 8.2 Presence Service Input Script 8.4 Status 8.3.2 Mobile Browser Implementation 7.2.4 Porting Implementation 44 45 49 Chapter 8 TESTING 8 .3 OUTPUT Screen Shots SOAJavaScript object JavaScript Interface 8.2 Test Documentation 8.1 Work Remaining 8.1 Testing Strategy 8.

Brief History Web Scripting Language Overview 69 71 71 References 75 .

7 SOA Request Response Pattern with service registry Figure 3.2 Browser Testing Communication Testing .LIST OF FIGURES Figure 2.1 Webkit Architecture Figure 2.3 Architectural Frame Work SOA Figure 3.2 Figure 3.8 SOA Subscriber-Push pattern Figure 6.4 Overall Communication Figure 7.2 SOA Interaction Model Figure 3.3 Mobile SOA Communication Architecture Communication Protocol Figure 7.1 Figure 8.5 Service within Overall Architecture Figure 3.1 Mobi Linux Architecture Reference Model SOA 7 9 14 16 18 20 23 24 25 26 36 44 45 47 48 49 52 52 Figure 3.1 Porting specific implementation Architecture Figure 7.1 Webkit JavaScript Object addition Figure 7.4 Client Operation Architecture Figure 3.6 SOA Request Response Pattern Figure 3.5 Porting Class Diagram Figure 8.2 Figure 7.

1.3 Service Manager Testing Figure 8. Browser evolution Figure a.4 Testing Individual services Figure a.2 Browser Architecture 53 53 65 68 .Figure 8.

1 Organization Profile 1. We do this by designing and delivering the "must have" products.along with a full complement of support services . 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.Chapter 1 INTRODUCTION 1. and entertainment that you want and need.1 Overview: Motorola is known around the world for innovation and leadership in wireless and broadband communications. "must do" experiences and powerful networks .1.

Networks & Enterprise. 1. The Lab in India was launched by Ms.2 Project Overview Mobile devices are basically becoming new client platforms.1. The Company’s focus areas include.2 Chapter 1 1. Applied Research and Development on Seamless Mobility/Convergence technologies. Web Services. including SOA.This is Motorola’s 11th research facility world wide and first in India. It has research and development centers at Bangalore and Hyderabad.1. Haryana. with offices at Delhi. With access to India’s proven best-in-class scientific and engineering talent and the ability to collaborate with world-class universities and institutes. Motorola's operations in India are divided into three businesses: Mobile Devices. in the context of mobile computing. and thus need to support most of the new computing paradigms. is all about the notion of devices that can move in and out . Broadband Equipment (wired as well as wireless).3 Motorola India Research Labs (MIRL): Motorola launched its applied research labs in Bangalore on 7th April 2005. and Connected Home Solutions. The Motorola Labs Bangalore mainly focuses on key application research. Padmasree Warrior. former executive vice president and chief technology officer. Mobile handsets. Wireless Infrastructure.2 Motorola India Operations: Motorola India is headquartered at Gurgaon. 1. Managed and Hosted Services. Trunking & Two Way Radios. Mumbai and Bangalore. Motorola believes India is the ideal region for applied research and software development. Software Development.

and with the right validation. Another emerging need is shifting between access modalities. in essence the mobile device becomes a peer. raising the need for multiple access channels to processes. which combines service oriented design of systems and applications with the domain of lightweight mobile devices. and at the same time find and leverage Web services as needed. business processes and work in general are becoming increasingly independent from location and other contextual limitations. and changing to a fullscale PC application upon arrival. This should be a bidirectional mechanism where mobile devices can both consume and provide services. for example.Introduction 3 of service areas. . Enterprise computing is going through a paradigm shift from proprietary monolith systems to service oriented solutions. we propose the concept of Mobile SOA. 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. making preparatory work using a limited capability mobile device while traveling towards office. Also. To address these phenomena.


It is also included supported by mobile platforms. having clean source code. and many other OS X applications. ECMAScript compliance and compatibility with major ECMAScript implementations are other advantages. It is also used as the browser engine of web run times like Adobe AIR. is highly portable (depends only on standard C and C++ libraries and a Unicode implementation). JavaScriptCore provides powerful garbage collector. . the iPhone. Dashboard.Chapter 2 BACKGROUND WebKit is an open source web browser engine. Webkit and its components are known for being small and fast. Mail. Nokia's Series 60 browser. and Google's Android platform. is developed using object-oriented C++. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari. and supporting the latest standards for web content.

providing an Objective-C application programming interface to the C++-based WebCore rendering engine and JavaScriptCore script engine. and provides this type of scripting in other contexts within Mac OS X. and DOM library for HTML and SVG developed by the WebKit project.7 and later.1 Webkit Architecture WebKit began when Apple created a software fork of the KDE project’s HTML layout engine KHTML and KDE's JavaScript engine (KJS).WebKit was first included with Mac OS X v10. 2.2 WebCore WebCore is a layout. JavaScriptCore has been improved with many new features and greatly improved performance.2. originally developed by Apple as a fork of KHTML.1JavaScriptCore JavaScriptCore is a framework that provides a JavaScript engine for WebKit implementations.1.1.6 Chapter 2 2.3. later versions also include a cross-platform C++ platform abstraction. KHTML and KJS were ported to Mac OS X with the help of an adapter library and renamed WebCore and JavaScriptCore. . The WebKit framework wraps WebCore and JavaScriptCore. Since forking from KJS and PCRE. It is licensed under the LGPL. and is available as a software update for v10. The Webkit has two following major components 2. allowing it to easily be referenced by Cocoabased applications. JavaScriptCore is originally derived from KDE’s JavaScript engine (KJS) library (which is part of the KDE project) and the PCRE regular expression library. rendering. and various ports provide additional APIs.

KWQ .Background 7 WebKit WebCore KWQ Java Script Core KHTML CSS DOM ECMA XML HTML Render MISC Fig 2.KWQ (pronounced "quack") is an adapter layer used to communicate with KHTML. The KHTML engine used in Konqueror was written on top of a cross-platform toolkit called Qt.1: Webkit Architecture WebCore can be divided into two principal areas: KWQ and KHTML. KWQ is essentially an implementation of the subset of Qt required to make KHTML work on OS X . It is written in Objective C++.

6 kernel and supports high resolution POSIX timers and O(1) Real-time Scheduler with up to 1024 levels of priority. 2. with requirements for power management.2 ECMA Script ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. there are no provisions in this specification for input of external data or output of computed results. 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. indeed. This code is written entirely in C++. MontaVista engineered Mobilinux. Instead. With Mobilinux. . hard real-time performance. 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. 2. and small footprint.8 Chapter 2 KHTML .KHTML is the layout engine and contains all of the code for constructing and rendering HTML and XML.2 Mobi Linux Mobilinux is an optimized Linux operating system and development environment. with the exception of some glue code that communicates with WebKit (using Objective C++). 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. It’s based on Linux 2. ECMAScript as defined here is not intended to be computationally self-sufficient. fast start-up. ideally suited for wireless handsets and mobile devices.

Background 9 2.) .2: MobiLinux Architecture (courtesy of MontaVista Software. Inc.


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


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 requestresponse 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 person’s needs being met by capabilities offered by someone else; or, in the world of distributed computing, one computer agent’s 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

Service Oriented Architecture


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 – a Reference Model and Reference 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.

Visibility is the capacity for those with needs and those with capabilities to be able to see and interact with each other. Fig 3. services must have accompanying service descriptions to convey the meaning and real world effects of invoking the service. and technologies across service providers and service consumers. standards. Service Descriptions .14 Chapter 3 In order for SOA to be meeting these challenges. which is the externally visible aspect of invoking a service.1: The core OASIS Reference Model for Service Oriented Architecture (courtesy of OASIS) Visibility and Real World Effect are also key concepts for SOA. For consumers to determine if they can interact with a specific service. This will be decomposed further to examine the data service aspects of SOA. Each service has an interaction model. This is typically implemented by using a common set of protocols. These descriptions must additionally convey both semantics and syntax for both humans and applications to use.

Real world effects are. . 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 purpose of using a capability is to realize one or more real world effects. it also provides a decision point for any policies and contracts that may be in force.Service Oriented Architecture 15 provide declarations of aspects such as functions and technical requirements. then. Service contracts may be either short lived or long lived. A contract is formed when at least one other party to a service oriented interaction adheres to the policies of another. couched in terms of changes to this shared state. wherever the data persists. The execution context is the set of specific circumstances surrounding any given interaction with a service and may affect how the service is invoked. This requirement is a logical evolution of the “locked file cabinet” model which has failed many IT organizations in recent years. This may specifically mutate the shared state of data in multiple places within an enterprise and beyond. Policies must be able to persist with the data that is involved with services. and mechanisms for access or response. Since SOA permits service providers and consumers to interact. related constraints and policies. At its core. 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. 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).

interaction is the act of actually using a capability via the service. Typically mediated by the exchange of messages. surrounds whereby client actually view binding multiple a a RIA composed data when their this The model single may a by from sources concept of “Mashups” provide persisting in multiple domains across many tiers. Architects building Rich Internet Applications (RIAs). There are many facets of interaction. an interaction proceeds through a series of information exchanges and invoked actions. .3 Decomposing the Interaction Model Whereas visibility introduces the possibilities for matching needs to capabilities (and vice versa). 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.16 Chapter 3 3. are faced with special considerations designing systems from perspective.

The behavior model is decomposable into the action model and the process model.2.4 A Reference Architecture for Service Oriented Architecture[1] A reference architecture is a more concrete artifact used by architects. The sequence of messages flowing into and out of the service is captured in the action model while the service’s processing of those signals is captured in the processing model. in a Request-Response behavior model. Reference architectures declare details that would be in all instances of a certain class. The data models are strongly linked to the behavior models. the corresponding data model would have two components – the input (service Request) data model and the output (service Response) data model. much like an abstract . The data model is present in all service instances. Unlike the reference model. 3. For example.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. The processing model is potentially confusing as some aspects of it may remain invisible to external entities and its inner working known only to the service provider. the interaction model can be further decomposed into a data model and behavior model. the service is still deemed to have a data model. Data models may be further specialized to match the behavior model if it is other than “Request-Response”. it can introduce additional details and concepts to provide a more complete picture for those who may implement a particular class. Even if the value is “null”.

The relationships are depicted in Figure 3. and other types of binary relationship details.3. Architects can use these artifacts in conjunction with others to compose their own SOA. The reference model and the reference architecture are intended to be part of a set of guiding artifacts that are used with patterns. Each subsequent architecture designed from the reference architecture would be specialized for a specific set of requirements. then a reference model would have infrastructure (between the two concrete entities) and it would not longer be a model.18 Chapter 3 constructor class in programming. reference models do not have service providers and consumers. Reference architectures often introduce concepts such as cardinality. If they did. Fig 3. Accordingly. structure.3: The Architectural frame work for SOA (courtesy of OASIS) . infrastructure.

• an email endpoint. Regardless of its ultimate end state.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. The service container is responsible for handling the service invocation request for its entire lifecycle. While reference architectures can form the basis of classes of solutions. Services may also be invoked by local consumers including environments like J2EE and language specific interfaces (for example . Architects and developers also need to bind their own SOA to concrete standards technologies and protocols at some point. • a watched folder being polled for content. and requirements that define the actual problems being addressed. For example. these specialized architectures will enable solution patterns to solve particular problems. motivation.Plain Old Java Objects or POJO’s). the service container may also delegate responsibilities for certain . until either it reaches a successful conclusion or failed end state. Concrete architectures may be developed based upon a combination of reference architectures. Each service invocation is often handed to a new instance of a service container. Architecture is not done in isolation. These are typically part of the requirements process. a developer might opt for the • XML Remote Procedure Call (XML-RPC). and additional requirements. concrete architectures will define specific solution approaches. architectural patterns. including those imposed by technology environments. when building a highly efficient client side Mashup application. and • other RESTviii style endpoints including plain old HTTP and HTTP/S. it must account for the goals.

clients must have far more robust communications services than a decade ago. any communication standards. 3. security.4: Client application architecture(courtesy of OASIS) As depicted in Figure 2.5 Client Tier While much attention has been focused on the server side aspects of SOA. and authentication. the repository can persist while allowing access to privileged individuals. archiving. the registry-repository provides a single view of all services and related artifacts. protocols and technologies . 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 registry-repository is often used. To facilitate orchestration and aggregation of services into processes and composite applications. In fact. The repository provides a persistence mechanism for artifacts during the runtime of processes and workflows. During the process design phase.20 Chapter 3 aspects of the service’s runtime to other services for common tasks. If multiple system actors use and interact with a form. These tasks typically include logging functions.4. among others. Fig 3. A highly visible example of this is the ability of most modern browsers to subscribe to RSS feeds.

Service Oriented Architecture 21 (such as SOAPix. In distributed computing architectures. or XML-RPC) have to be implemented on both sides to facilitate proper communications. another time to run the script. 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. The main controller of each client application must be capable of launching various runtime environments. and a concurrent iteration to collect garbage and free up memory as it becomes possible to reallocate. The security models used by different clients also vary somewhat. This is typically done via launching one or more virtual machines that can interpret scripting languages or consume bytecode as in Adobe Flash. identity (knowing who and what) is a major problem that requires a complex architecture to address. . Additionally. The architecture for these virtual machines varies greatly depending upon the language used. Each client side application must be architected in accordance with the acceptable level of risk based on the user requirements. 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. The usual tenets are to prevent unauthorized and undetected manipulation of local resources. ActionScript Messaging Format. 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. Client side communications buses also need to monitor the state of communications including potentially both synchronous and asynchronous exchange patterns. Most modern clients have some form of data persistence and state management.

As depicted in Figure 2. how an event gets noticed or captured. state misalignment would likely result if two services had differing states for even a fraction of a second. what constitutes an event. the services themselves should not know (or care) what they are being used for.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. and more. errors might be thrown when this is detected or worse. architecture must take note of several common architectural models over all tiers of modern SOAs. developers would have to rely on using a series of synchronous calls to services rather than forking a process into asynchronous calls. If you are deploying services to be part of an automated process management system. what constitutes a change in state. As a result. the core axioms of service oriented architecture should be observed. First and foremost.5. Services that are designed otherwise are architecturally inelegant for a number of reasons. Services themselves should be treated as subservient to the higher level system or systems that use them. 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 . if services were required to know the state of the overall process. In such instances. Architects need to employ common models for determining what constitutes an object. First. services should remain agnostic to what they are used for.

The correct terminology should be service aggregation.5: Service within overall architecture (courtesy of OASIS) Second. Having dependencies on knowing the internal working of the services functionality is another anti-pattern of SOA and should also be avoided. if composition is defined as per Unified Modeling Language (UML) 2. 3. In composition relationships. 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. This results in a clean decoupling of components. Another core architectural convention is to keep the service consumers agnostic to how the services are delivering their functionality. each service used would have to be notified and rolled back to a previous state. Aggregation is a “uses a” type of relationship. The differences are quite subtle but nevertheless important to grasp. another architecturally elegant feature of modern service oriented systems. Composition is depicted as a “has a” relationship and the whole is composed of the parts. the life cycles of parts are tied to the lifecycle of the whole and .Service Oriented Architecture 23 Fig 3.0x. if the overall process stalled or failed for some reason.7 Service composition The act of building an application out of multiple services. is likewise an anti-pattern of SOA.

When the changes are made. 3. the parts exist independent of the whole and can go on living after the entity that uses them no longer exists.7.7. Fig 3. the parts no longer exist either. the service consumer is notified of these . distributed systems and bear these definitions in mind.6: SOA Request-Response pattern(courtesy of Adobe) 3. This terminology is common within both OOPSLAxi and UML. In aggregation. The request results in an optional response.24 Chapter 3 when the whole no longer exists.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. Regardless. the term “service composition” has been misused widely within the computer industry and will likely prevail as a norm. as shown in Figure 3.6. Architects and developers should pay close attention to the types of binary relationships between components in loosely coupled.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 service’s details to the registry to which the consumer has subscribed.

7. in some cases.7: SOA Request-Response pattern with a service registry(courtesy of Adobe) 3. the externally visible pattern remains the same. one or more clients register subscriptions with a service to receive messages based on some criteria. shown in Figure 3. Fig 3. A subscription may. also register another service endpoint to receive notifications.Service Oriented Architecture 25 changes and can configure its service client to talk to the service. . This is represented conceptually in Figure 3.7. Regardless of the criteria.3 Subscribe-Push A third pattern for interaction is called Subscribe-Push.8. In this pattern. 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. Subscriptions may remain in effect over long periods before being canceled or revoked. For example.

8: SOA Subscribe-Push pattern(courtesy of Adobe) Note that this pattern can be triggered by a multitude of events. shop floor automation. or a number of other actions that are not listed in the example above. a timeout action. providing up-to-the-second views of critical data. and more.26 Chapter 3 Fig 3. 3. Data push can be further specialized into broadcast. multicast. This highly scalable capability can push data to thousands of concurrent users.8 Data push Some 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). live resource monitoring. . unicast. In figure 3. and several other specializations of the basic pattern. such as stock trader applications. an auditable event is triggering a message being sent to a subscribed client. Each of these represents a specialization of the Subscribe-Push pattern. The trigger could be a service consumer’s action.8. This can be done via intuitive or inference methods to ensure data is provided as required.

The mobile service field became divided into content service and added value functional service. business developers and the mobile service concept developers. greeting cards and background pictures into the mobile phone. value adding services to consumers and enterprise users has challenged the technology developers. Offering highly usable. The main function of content service is to deliver media contents such as ringing tones.Chapter 4 MOBILE SERVICE ORIENTED ARCHITECTURE Mobile services hold a promise of utilizing the phone also for other purposes than voice and SMS communication. Such services were originally built on top of mobile messaging . Turning the promise into reality has been proven to be more complex than what was anticipated in the dawn of digital mobile communication.

screen sizes. 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. . 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. and location specific information back to the server-side. 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. Necessarily. It means that a mobile service consists of a client-side component and a server-side Component. run-time platforms. features and usability of those features in the client-side component depend strongly on the capabilities of the client device. 4.1 Problem Statement Different brands. To provide the best user experience. 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. 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.28 Chapter 4 technology such as SMS and achieved continuously growing success in consumer segment. network and many other factors all contribute to the fact that there is a large variety of mobile devices on the market.

The device layer frame work takes care of all the device restrictions and portability problems. The third approach is installing a device layer framework on the mobile which provides a platform independent interface to the browser. 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. A user installable application has access to all phone resources and can integrate with the native UI with no restrictions. Browser based services are evolving rapidly as the capability of the terminal is growing. So the user can use all the capabilities provided by the browser apart from what is offered by device layer frame work.Service Oriented Architecture Mobile service oriented architectures need to address the following goals 29 -Number of devices. it has become feasible to closely emulate the user experience of a PC with fast Internet access.Native features. The more devices it supports. Native features add value to the phone and therefore to the services provided on that phone. The recent devices included HTML browser that are capable of displaying dynamic HTML pages with interactive scripts. The service must have a quick time to market.Time to market. The service must be provided on a wide variety of mobile devices. The restriction of this approach is the availability of an open source browser. Native features relevant to the service should be preferably be used. A challenge in this approach is to ensure the compatibility of the phone software platform and installed applications. Another approach to offer highly usable mobile services applications is to open the phone software platform for user installable native applications. the larger the market is. Native features include both software and hardware features. . . . The service must make full use of native features.

.30 Chapter 4 The browser can explore the device layer features either as pluggable component or adding as a new JavaScript object.

The emergence of “de facto” browser functionality and technologies like browser side scripting has improved the user acceptance of these services significantly. Nowadays. As developing browser based services for the pc in the nineties: But rapid advances can be observed in mobile browsers. The screen size requires different approaches to efficiently present Information and allow user to work with the on screen information effectively. it’s not always possible to apply the user interface patterns of the pc world to the mobile world. Despite this. developing browser based services for mobile clients are facing similar problems in many ways. .Chapter 5 CLIENT-SERVER WITH MOBILE THIN CLIENT & BROWSER The browser based approach has been very successful in the Internet and PC world.

Usability.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. Deployability. 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. Typically. Portability. Scalability. The new HTTP/HTML capable device generations offer the same PC features with the added advantage of mobility factor. The interaction between the device layer framework and browser can be facilitated through browser plug in component or through a new Asynchronous JavaScript object. Any registration and authentication functions can be taken care inside the browser session. The scalability in capacity of browser based architectures can be controlled by device layer framework and by the traditional design solution of the . Usability of an individual browser based service can be reasonably good for suitable applications. Even so. applications where the interaction between user and application is based on a forums paradigm fit well to the browser client architecture. The client side portability obstacles can be restricted within the JavaScript object. A phone equipped with the device layer framework installed and a browser that is compatible with the service can start using services immediately. A limitation is that an open source browser is required for modification. 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. Integration to the local phone resources can be restricted through the device layer framework. the architect of a browser based mobile service is forced to select between many alternative technology stacks that are largely incompatible with each other. It includes normal deployment and configuration of the device layer framework and server side components.

Client-Server With Mobile Thin Client & Browser 33 server side. 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. This involves two main areas: the scalability of access to the service and the scalability of the device layer framework.



36 Chapter 6 Mobile Browser SOAJSObject Shared library SOAInt Shared memory Application Request Queue Application Response Queue SOA Object Service Manager Context Manager Device Manager Call Service Web Service RIL Interface Call Interface Weps MSOA Transport TAPI Http Stack Fig 6. 6. When implemented.1: Porting Specific MSOA Implementation Architecture The architecture composed mainly three components in addition to a shared memory.1 Mobile Browser: A JavaScript object is added into the existing browser domain. the browser will support a new SOAJavaScript object and can be instantiated using .

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. The packet will contain the SOAobjectId and is capable of holding any number of arguments.Implementation Architecture 37 the ‘new’ operator. Each ‘SOAJavaScript’ object will try to load this library. The notification to the Daemon is implemented using a semaphore.The ‘SOAJavaScript Object’ registers a call back with the ‘Proxy JavaScript Object’ through ‘IJavaScript’ interface . the access mechanism is chosen. 6. The library exports factory methods to create a proxy JavaScript object which is liable for creating a new service object in the Daemon. On the very first loading. if it’s not already loaded and obtain a handle to factory method. Depending on the command type. a call back function is invoked.2 Shared Library: The shared library act as the bridge for inter-process communication between the browser and the device layer Daemon. It also exports a set of methods to register the browser application with the Device Layer daemon. The ‘Proxy JavaScript‘object translates each request from the ‘SOAJavaScript’ object into a general packet format and transfers to the device layer SOA object. The invocation of this method will return an ‘SOAInterface’ interface which refers to the ‘Proxy JavaScript object ‘.On a push from the device layer daemon. The shared library provides a thread which is always waiting for an asynchronous response from the . instantiated by the shared library . The browser will create the SOAJavaScript object which in turn try to load the shared library and will call the exported factory methods. 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. it will map the shared memory to it.

3 Device Layer Daemon: The area inside dashed lines represents the Device Layer Daemon The Service Daemon will be loaded on device boot up. it maps the shared memory in to its work space. This implementation restricts one write at a time through the both the 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. On loading. one ‘SOAobject’ is created in the Daemon. the next write operation can only be done after the first written data has been read by the intendant. Corresponding to each ‘SOAJavaScript’ object in the browser. . 6. the ProxyMailBox’ will invoke the call back function.38 Chapter 6 Daemon. one is shared among all applications and other is allocated for each process which interacts with the device layer daemon.4 Shared Memory: Here. The service daemon implements the Device layer functionalities. we use two types of shared memories. 6. The ‘Process Registration‘memory is shared among all applications through which each process registers with the daemon. On an asynchronous response from the Daemon. The memory allocated for each process consists of two segments: Request Memory and Response Memory.

1 Existing Implementation At Present. The availability of an open . a Windows Mobile Implementation of Device layer frame work exists. It has to take care of the device specific properties such as limited GUI features.Chapter 7 IMPLEMENTATION DETAILS INCLUDING PORTING 7. In the Windows Mobile Implementation. a native client application can only be the end user for SOA framework. Since it’s a Herculean task to provide the capabilities of a browser in a native application. The lack of an open source browser in windows is one of the major obstacles for providing a browser based implementation.

location services. directory services etc.1. To alleviate the security vulnerability threat and to extend multiple process interaction in an independent way. depends on protocol stack implementation such as connectivity. the SOA Interface to the outside world is exported through a shared library (It’s a . When the memory-mapped files are used for inter-process communication. web services.so in Linux). call services.Some of these services are device specific i. In WM implementation.e. an intruder who is aware of the public name can tap the secured enterprise data. The sharing of name raises the security vulnerability. The MSOA provides a set of services such as present services. 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). Since the services are loosely-coupled.40 Chapter 7 source browser in Linux is one of the attractive features. independent to each other and independent to instance count. an inter-process communication has also been brought into picture. In both implementations. Sine two different applications can’t use an . The application uses the MSOA framework. the name has to be shared among the applications. The porting work can be divided into two sets: 1 Purely OS Specific (Windows V/s Linux) 2 Device Specific 7. Linux implementation provides preprocess shared memory to applications so that one process doesn’t want to get queued due to other application’s slow performance. threading primitives are brought into the picture. has to attach the library into its own address space. memory mapped files are used as shared memory.dll in windows and . HTTP etc but others are be device independent. The existing Windows Mobile Implementation uses the IOCTL and Windows Event mechanism for communication and synchronization.1 Purely OS Specific (Windows V/s Linux) Since the picture is clear from the implementation architecture.

a semaphore based protocol implementation will be the right choice to implement communication protocol. Named event objects are provided for synchronization between processes. Shared memory in Linux is chosen as the candidate for IPC due to the fact that it’s the fastest IPC mechanism available in Linux. But it still has some of the vulnerability that data can be distorted but chances are less due to dynamic name fixing. Every application which wants to use the MSOA. Both synchronized and asynchronized communication should be there to support MSOA functionality. An unnamed POSIX semaphore can be used between threads of the same process. but in Linux. Request memory Id and semaphore set for synchronization. IPC (shared memory). The rest includes threading primitives. timeout value can be specified for Windows semaphore objects. Mutexes. This is not provided for Linux . has to register with the framework through the registration memory. Request Memory and Response Memory are provided in such a way that no other process can tap another process’s confidential data. Since the name is chosen dynamically at run time and restriction in access permission both ensures that an intruder can’t tap the information.it needs to be handled in the application logic only. It’s a kind of hand-shaking in which the application and the device layer framework reaches on agreement of Response memory Id. synchronization. When used in one of the wait functions. Considering the portability factor into other platforms. This is used to achieve the functionality of a Windows named semaphore. It can also be initiated from both ends. The following points should be considered during migration: Windows provides named and un-named event objects. both the pthreads and . The Read/Write permissions of the Registration Memory. System V semaphore can be used between threads of different process. and daemons. we too use the same but restrict it in a way as it’s only used for a process registration.Implementation Details Including Porting 41 IPC mechanism with out a shared name. The windows specific code uses Events.

manual and auto-reset. Linux provides only auto-reset event features In Windows. Based on the application logic. connectivity status and imei number. To achieve functionality of named event objects in Linux. pthreads does not provide an initial state. this can be selected as a choice for implementing the functionality on Linux during porting. pthreads. System V semaphore or signals can be used. Telephone API based services and some context specific information such as cellId.2 Device Specific The MSOA makes use of some device specific functionalities such as HTTP based services. but when the count is set to 1 they provide similar functionality to the Windows event object. event objects initial state is set to signaled. 7. In Linux. • Windows provides two types of event objects . but POSIX semaphores provide an initial state. conditional variables provide event-based synchronization between threads. They don't provide timeout in the wait functions. CellId and imei number etc. • • It is also important to note that: • POSIX semaphores are count semaphores. POSIX semaphores are preferred when the timeout is not the factor in the porting. In Windows Mobile.42 Chapter 7 POSIX provides synchronization between threads. When used along with the Mutex. POSIX semaphores and System V semaphores are asynchronous but pthreads conditional variables are not asynchronous. Windows event objects are asynchronous.1. In Linux. but they are synchronous. the Radio Interface Layer provides the API’s for connectivity status. The RIL .

Access to data (news. a WinINet function provides internet connectivity API’s using this. TAPI facilitates include Connecting directly to a telephone network. device manager is using the RIL interface for context updating in Windows Mobile Implementation. Automatic phone dialing. new base station is registered etc. In the linux port. information services). faxes. The Mobilinux port of Motorola provides a TAPI library in which both synchronous/ asynchronous reply and asynchronous notifications are supported. Voice mail. We have to start internet connection and then uses ‘HttpOpenRequest’ to open an http connection. disconnected . Caller identification. Most of the context specific API’s used in RIL are asynchronous . In case of HTTP/HTTPS services. In the Linux port. Control of a remote computer. Transmission of data (files. The Microsoft Windows Telephony API (TAPI) allows applications to support telephone communication. electronic mail). 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.etc. asynchronous mechanism is used for reducing the number of threads. The synchronous v/s asynchronous responses to queries are taken in to account in the Linux implementation. Collaborative computing over telephone lines . As in the case of RIL interface provided. one another call interface is provided. The Mobilinux port of Motorola provides a Weps API which offers both synchronous and asynchronous access to ‘http/https’ services. the windows. which hides the internal implementation and provides functionalities which relevant to the MSOA adding the advantage that the same can also . The context manager. The WinINet only provides synchronous API for http ssrvices.Implementation Details Including Porting 43 interface provides asynchronous replies to queries and provides notification call backs on events such GPRS connected. the TAPI in Mobi Linux port provides both call service and RIL services. Conference calling.

Apart from various set and get methods. Whenever there is a response from the device layer daemon. The class diagram is shown in fig. The call back function is implemented as a DOMEvevnt..1 1 1 1. the call back function will get executed.. .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.2 Mobile Browser Implementation DllHandler 1 <<Friend>> 1 <<Abstract>> n <<Interface>> 1 1 SOAJavaScript Proto Func MailBox Listener KJS_Window Listener SOAJavaScript ConstructorImp 1 1 1 ISOA 1 SOAJavaScript 1. The JavaScript programmer can assign his own JavaScript function as a call back function.44 Chapter 7 be treated as pluggable unit where interface remains same and implementation differ for various platforms.1 JSEvent Listener 1 DOMObject Document n ObjectImp <<Abstract>> 1 JSAbstractEvent Listener DocumentImpl MSOAEvent MSOAEven t Impl Event n 1 EventImpl Fig 7. The JavaScript Object act as the interface to MSOA frame work. it provides an ‘onResponse’ attribute.. 7.

7.3 Communication b/w Shared Library and Device Layer <<Browser 1>> SOAJavaScript Object 1 SOAJavaScript Object 2 <<Browser 2>> SOAJavaScri pt Object 3 SOAJavaScript Object 4 Dll Handler Dll Handler <<Shared library>> SOA interf SOAI nterf <<Shared library>> Req ues t me m1 Res pon se me m1 Process Reg mem Req ues t me m2 Res pon se me m2 <<Device layer Daemon>> Reg Listening Thread Communication Thread SOA1 SOA2 SOA3 SOA4 Fig.2 Mobile SOA Communication Architecture .Implementation Details Including Porting 45 7.

It write backs the ID of request memory to the shared library’s response memory so that it can only read that information. The shared library creates its own response memory with it’s having the read permission and others have write permission. 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 browser will in turn try to register it with the device layer daemon if it is not already registered. The device layer in turn creates request memory that can be read only form device layer.46 Chapter 7 Whenever a new SOAJavaScript Object is created.4 . The corresponding responses are packed at daemon side and conveyed trough response memory. It also creates the semaphore set for synchronization and writes this ID’s into registration memory that can be read only form device layer. The asynchronous and synchronous communication protocol in terms of semaphore is depicted in fig 6.

3: Communication protocol in terms of semaphores .Implementation Details Including Porting 47 Proxy Synch T Proxy Async T 1: Wait 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 2: wait 3: write 4: signal 5: 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 19: 20: Wait 21: write 22: Signal 23: Wait 24: Read 25: Signal 26: Signal Fig 7.

... Semaphore) 11: wait f or registration response 12: read registration request.notif y Response 49: proxy JSobject.popFront 40: write sendMessage request 41: read request 42: SOAobject. Client Request Writing Thread Client requ.popFront 45: write Response 46: read Response 47: insert response 48: proxy JSobject...sendMessage 38: insert request 39: Q.. 21: write registration response ID(request mem) 22: Read Registration resp ID( Req mem) 23: Map Request Memory 24: wait on Response Memory 25: create Queue 26: create Thread 27: create thread 28: wait on this Q 29: create SOAJav aScript Object 30: write create SOAJav aScript request SOA object 31: read request 32: create SOAobject proxy jav a script object 34: read response 35: create client mailbox 36: return soaInterf ace 37: proxy object.deleteInstance 50: write deleteInstance request 51: read request 52: delete SOAobject 53: delete this 54: terminateLibrary 55: writr unregister process request 56: read request 57: unregister this process 58: close request memory 59: f ree Response Q 60: close thread 61: f ree Q 62: f ree semaphore set 63: f ree response memory 64: f ree Thread 65: f ree Thread 66: close thread 67: unload library Fig 7.insertRequest 33: write soaobject creation status 43: insert Response 44: Q.so 4: Wait f or new process registration 5: Load Library 6: initLibrary 7: Map registration memory Semaphore set 8: create Response Memory 9: create semaphore set 10: write process registration request ID(Resp mem. Proc Registration Listening Thread 2: create Thread 3: do Daemon initilization Browser Shared Library . DL response Writing Thread Response memory 15: create request memory 16: create Q 17: create Thread 18: wait f or Requests 19: create Thread 20: wait on Response Q Client Respo.48 Chapter 7 Process Reg istration memory 1: create process registration memory Dev ice La. ID(resp mem..4 Overall Communication [Interaction Diagram] .semaphore) 13: map Response Memory 14: map Semaphores Request Memory DL response Queue DL request Listen..

Call Interface and Weps) the device specific part is ported. Using the new adapter interfaces (RIL Interface.5: Porting Class Diagram Context Manager . the corresponding API’s in windows and Linux are mapped. using Macro definition.4 Porting Implementation As discussed in porting section. That code logic which can’t be simply mapped is rewritten with the help of compiler directives. MSOTransport Provider 1 1 n n CallInterface n 1 RILInterface n 1 n 1 CallSvc device Manager Fig 7.Implementation Details Including Porting 49 7.


1 Testing Strategy Software testing is the process used to assess the quality of computer software. but is not limited to. 1. The browser 2 Shared Library 3 Device Layer Daemon Since the Shared Library and Device Layer Daemon do not have any terminal. In MSOA. This includes. the following components have to be tested independently. Once the browser test is over it can be used for testing both shared library and daemon. Instead of communicating with library the browser will loop back responses to send Message after sleeping for some time. The browser is only having the terminal interface. the process of executing a program or application with the intent of finding software bugs. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test .Chapter 8 TESTING 8 . The test input to the browser is java scripts. The MSOA services are defined in the Atom Syndication Format. with respect to the context in which it is intended to operate. The browser can be tested by providing a loop back kind of hard coded stuff. . their results can only be viewed from there logs.

e. . Service Manager Shared Library SOA Object Mobile Browser Input <Java Script> SOAJS Object Context manager Call servic Web servic Fig 8. the communication protocol can be verified.52 Chapter 8 Mobile Browser Input <Java Script> SOAJS Object Shared Library SOA Object Service Manager Context manager Call servic Web servic Fig 8. (with out invoking methods).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. By setting the device layer SOA object as a stub i.1: Browser Testing The shared library and daemon can be tested together because it’s a communication protocol contains lot of inter-process communication.

The logs will contain time stamp and message unique Id’s and SOA Object ID’s wherever will be relevant.1 SOAJavaScript object JavaScript Interface .2.Testing 53 Mobile Browser Input <Java Script> SOAJS Object Shared Library SOA Object Service Manager Context manager Call servic Web servic Fig 8. 8.2 Test Documentation 8.3: Service Manager Testing Once the service manager is verified each actual service can be invoked and can be verified. Service Manager Shared Library SOA Object Mobile Browser Input <Java Script> SOAJS Object Context manager Call servic Web servic Fig 8.4: Testing Individual Services Verification can be done checking the responses and also verifying three logs.

getContentLength(msgID) if(length>0) . } 8. in DOMString paramValue).messageId == msgID) { length = mbox. int getStatus(in long msgId).54 Chapter 8 Interface SOAJavaScript { //event handler attribute EventListener onresponse. // get methods out Array getMessage(in long msgid). void setParameter(in DOMString paramName. void deleteMessage(in long msgid). int getContentLength(in long msgid). in DOMString paramName). DOMString getMessageAsText( in long msgid). // set methods void setData(in Array data). Document getMessageAsXML(in long msgId). void setMethod(in DOMString method).2 Presence Service Input Script <head> <script type="text/javascript"> var mbox var msgID var presuri function handleResponse(event) { if(event. DOMString getParameter(in long msgid.2. void setContentType(in DOMString ctype). void setContentLength(in int len). DOMString getContentType(in long msgid). long sendMessage(in DOMString msg).

XMLHttpMailBox) { mbox = new SOAJavaScript("usr". //send a presence request msgID=mbox.getContentAsText(msgID) if(msg == "ONLINE") alert(presuri+"is Online") else alert(presuri+"is Offline") } } } } function validate(thisform) { if(window.getContentType(msgID) if(type=="text/plain") { msg= mbox.setContentType(”text/plain”) mbox.setContentLength(0) presuri = Tpresenceuri.onresponse=handleResponse() mbox.value.Testing 55 { type= mbox.sendMessage(“pres: <"+presuri+">”) } else { alert(" Your Browser does not support SOAJavaScript Object") } ."pwd") mbox.

"> </form> </center> </body> </html> 8.3 OUTPUT Screen Shots .56 Chapter 8 } </script> </head> <body> <center> <form name="myform"> <br><br><br><br> Presence URI : <input type="text" name="Tpresenceuri" value=""> <br><br> <input type="button" value="Submit" onclick="presence(myform).

4 Status 8.3.1 Work Remaining The coding of Device Layer Daemon is partial.1 Work Completed The 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.Testing 57 8. .3.

Service Manager Testing and Individual Services testing are remaining 8. The Communication Testing. so it’s pending.4 Testing Status The browser testing is successful .58 Chapter 8 The debugging of shared library can only be done along with daemon.

Understood the importance of programming to an Interface than to an Object. security. portability.Chapter 9 LEARNING FROM IMPLEMENTATION 1. 3. Understood the need for following development life cycles. modifiability. Learned the things to be taken into account while programming with multithreaded programs to avoid chaos. 4. integrability and testability in large scale system design. interoperability. 8. availability. Studied how real time operating systems are incorporated in mobile devices. Identified the roles of various quality attributes like performance. Identified the real truth. 2. Identified the vast scope of SOA in mobile devices. 6. Identified the usage of various design patterns in programming. academic pass out is not the end of the road but actual journey starts from there! . 7. 5.


A large portion of operations currently performed by desktop applications can be performed by mobile applications just as well. make the Framework a viable solution that merits further development and support.CONCLUSION The 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. allowing ubiquitous data access and enabling the advent of a new generation of mobile business.It is compatible with all the latest industry standards and makes migrating existing business systems to mobile devices as a feasible task. . We have implemented a Mobile Application Framework that supports services defined in atom syndication format . The world of technology is clearly moving towards wireless solutions and our mobile framework greatly contributes to this trend. The browser based implementation doesn't require intensive coding at the client side because the JavaScript acts as the client language.


Appendix A Browser Architecture The web browser is perhaps the most widely used software application in history. Comparing the architecture of older systems with the reference architecture can provide insight into evolutionary trends occurring in the domain. Each resource on the web is identified by a unique Uniform Resource Identifier (URI) (Berners-Lee et al. It has evolved significantly over the past fifteen years. web browsers run on diverse types of hardware. 2005). Resources can take many different forms. Reference architecture for web browsers can help implementers to understand trade-offs when designing new systems. Web browsers are used to conduct billions of dollars of Internet enabled commerce each year. including .. The web browser domain The World Wide Web (WWW) is a universal information space operating on top of the Internet. today. from cell phones and tablet PCs to desktop computers. and can assist maintainers in understanding legacy code.

2006) allow authors to add layout and style information to web pages without complicating the original structural markup. sound clips. Documents are typically written using HyperText Markup Language (HTML) (Berners-Lee and Connolly.64 Appendix A documents. 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. now standardized as ECMAScript (—.. 1996). 1999). 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. web browsers typically provide the user with other useful features. are used to embed these types of content in web pages. In addition to retrieving and displaying documents.. and the corresponding displayed page is the result of evaluating the JavaScript code and applying it to the static HTML constructs. 1995. Cascading Style Sheets (CSS) (Bos et al. and interpreting mouse actions. a stateless and anonymous means of information exchange. Plug-in. Although HTML itself is a relatively simple language for encoding web pages. images. such as Macromedia Flash animations and Java applets. small extensions that are loaded by the browser. most browsers keep track of recently visited web pages and provide a mechanism for “bookmarking” pages of interest. They may also store . Raggett et al. Examples of JavaScript applications include changing element focus. 1999). Scripting code is embedded within HTML documents. there are some types of content that the web browser cannot display directly. Other technologies may be used to improve the visual appearance and user experience.. JavaScript. altering page and image loading behavior. Finally. is a host environment for performing client-side computations. or video clips. For example. or implicitly by following embedded hyperlinks.

Browser Architecture 65 commonly entered form values as well as usernames and passwords. the WWW was first described in a proposal written by Tim Berners-Lee in 1990 at the European Nuclear Research Center (CERN) (Berners-Lee. which was graphical and also served as an HTML editor. By 1991.Browser evolution( courtesy of ICSM’05 Proceedings) .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. Around the same time. and motor impairments. hearing loss. Finally. 2. he had written the first web browser.1. browsers often provide accessibility features to accommodate users with disabilities such as blindness and low vision. 1999). researchers at the University of Kansas had independently Fig a.

there can be differences as to how web pages look and behave. Internet Explorer’s closed source engine has also seen reuse: Maxthon. the National Center for Supercomputing Applications (NCSA) released a graphical web browser called Mosaic. Berners-Lee founded the World Wide Web Consortium (W3C) to guide the evolution of the web and promote interoperability among web technologies. In the same year. Netscape. Avant. igniting a period of intense competition with Netscape known as the “browser wars. they adapted it to support the web in 1993.” Microsoft eventually came to dominate the market.66 Appendix A begun work on a text-only hypertext browser called Lynx. Although each browser engine typically produces a similar result. and chat clients. news. several Mozilla variations have appeared. eliminating Mozilla’s integrated mail. left to co-found his own company. Marc Andreesen. and Apple’s modifications have in turn been reused by other browsers. Galeon is a browser for the GNOME desktop environment that integrates with other GNOME applications and technologies. and NetCaptor each provide additional features to IE such as tabbed browsing and ad-blocking. Netscape 8. Firefox is a standalone browser with a streamlined user interface. Figure 1 shows a timeline of the various releases of several prominent web browsers. Microsoft released Internet Explorer (IE). Safari. Since 1998. based on code licensed from Spyglass. In 1995. The open source Konqueror browser has also been reused: Apple has integrated its core subsystems into its OS X web browser. and Netscape released its browser as open source under the name Mozilla in 1998. NCSA founded an offshoot company called Spyglass to commercialize its technologies and Mosaic’s primary developer. In 1994. . reusing the browser core but offering alternative design decisions for user-level features. which allowed users to view images directly interspersed with text. As the commercial potential of the web began to grow.

Browser Architecture 67 based on Firefox. smart download handling. It provides hooks for viewing various aspects of the browsing session such as current page load progress and JavaScript alerts. It may implement a cache of recently retrieved resources. 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. and resolves MIME media types for files. visual page-load progress. (3) The Rendering Engine subsystem produces a visual representation for a given URI. 2004) documents.. It also allows the querying and manipulation of Rendering Engine settings. preferences. and reload. . as well as embedded content such as images. It is capable of displaying HTML and Extensible Markup Language (XML) (Bray et al. (4) The Networking subsystem implements file transfer protocols such as HTTP and FTP. It translates between different character sets. This subsystem also includes the HTML parser. and printing. It calculates the exact page layout and may use “reflow” algorithms to incrementally adjust the position of elements on the page. allows the user to switch between IE-based rendering and Mozillabased rendering on the fly. It provides features such as toolbars. (2) The Browser Engine subsystem is an embeddable component that provides a highlevel interface to the Rendering Engine. It loads a given URI and supports primitive browsing actions such as forward. It may be integrated with the desktop environment to provide browser session management or communication with other desktop applications. back. The reference architecture is shown in Figure A-2. optionally styled with CSS.

Certain Java. or cache. (6) The XML Parser subsystem parses XML documents into a Document Object Model (DOM) tree.68 Appendix A Fig a-2 Reference Architecture Browser( courtesy of ICSM’05 Proceedings) (5) The JavaScript Interpreter evaluates JavaScript (also known as ECMAScript) code. or it may be low-level data such as cookies. almost all browser implementations leverage an existing XML Parser rather than creating their own from scratch. .Script functionality. This is one of the most reusable subsystems in the architecture. This may be high-level data such as bookmarks or toolbar settings. and a set of fonts. In fact. (8) The Data Persistence subsystem stores various data associated with the browsing session on disk. such as the opening of pop-up windows. may be disabled by the Browser Engine or Rendering Engine for security purposes. a set of user interface widgets. (7) The Display Backend subsystem provides drawing and windowing primitives. which may be embedded in web pages. It may be tied closely with the operating system. JavaScript is an object-oriented scripting language developed by Netscape. security certificates.

the most well known being JavaScript (Netscape) and JScript (Microsoft). The development of this Standard started in November 1996. The first edition of this ECMA Standard was adopted by the ECMA General Assembly of June 1997.0. and approved as international standard ISO/IEC 16262. It has appeared in all subsequent browsers from Netscape and in all browsers from Microsoft starting with Internet Explorer 3.0 browser. in April 1998. The ECMA General Assembly of June 1998 approved the second edition of ECMA-262 to . That ECMA Standard was submitted to ISO/IEC JTC 1 for adoption under the fast-track procedure. The language was invented by Brendan Eich at Netscape and first appeared in that company’s Navigator 2.Appendix B ECMA SCRIPT Brief History This ECMA[2] Standard is based on several originating technologies.

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. better string handling. The technical committee is working on significant enhancements. new control statements. and tighter coordination with other standards bodies such as groups within the World Wide Web Consortium and the Wireless Application Protocol Forum. A scripting language is intended for use by both professional and . the existing system is said to provide a host environment of objects and facilities. which completes the capabilities of the scripting language. and automate the facilities of an existing system. customize. In this way. formatting for numeric output and minor changes in anticipation of forthcoming internationalization facilities and future language growth. ECMAScript is an object-oriented programming language for performing computations and manipulating computational objects within a host environment. try/catch exception handling. including mechanisms for scripts to be created and used across the Internet. ECMAScript as defined here is not intended to be computationally self-sufficient. and the scripting language is a mechanism for exposing that functionality to program control. useful functionality is already available through a user interface. 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. there are no provisions in this specification for input of external data or output of computed results. A scripting language is a programming language that is used to manipulate. The current document defines the third edition of the Standard and includes powerful regular expressions.70 Appendix B keep it fully aligned with ISO/IEC 16262. Instead. Changes between the first and the second edition are editorial in nature. Work on the language is not complete. indeed. In such systems. tighter definition of errors.

cookies. when the Read-Only attribute for a property is set to true. and mouse actions. the host environment provides a means to attach scripting code to events such as change of focus. completing the ECMAScript execution environment. and an ECMAScript program is a cluster of communicating objects. Further. any attempt by executed ECMAScript code to change the . To accommodate non-professional programmers. and input/output. The scripting code is reactive to user interaction and there is no need for a main program. menus. An ECMAScript object is an unordered collection of properties each with zero or more attributes that determine how each property can be used— for example. This overview is not part of the standard proper. unloading. objects that represent windows. By using browser-side and server-side scripting together. Each Web browser and server that supports ECMAScript supplies its own host environment. selection. some aspects of the language may be somewhat less strict. form submission. clients. Scripting code appears within the HTML and the displayed page is a combination of user interface elements and fixed and computed text and images. Web Scripting A web browser provides an ECMAScript host environment for client-side computation including. text areas.ECMA Script 71 nonprofessional programmers. ECMAScript is object-based: basic language and host facilities are provided by objects. dialog boxes. and files. frames. and mechanisms to lock and share data. for instance. Language Overview The following is an informal overview of ECMAScript—not all parts of the language are described. it is possible to distribute computation between the client and server while providing a customized user interface for a Web-based application. history. anchors. page and image loading. A web server provides a different host environment for server-side computation including objects representing requests. error and abort. pop-ups.

binary bitwise operators. A . multiplicative operators. ECMAScript syntax intentionally resembles Java syntax. the Math object. as well as the pro-active user interface and the alignment with the SOA strategy prevalent in business applications. the RegExp object and the Error objects Error. A primitive value is a member of one of the following built-in types: Undefined. relational operators. a variable is not required to have its type declared nor are types associated with properties. Null. Boolean. binary logical operators. the Array object. strictly speaking. ECMAScript defines a collection of built-in objects that round out the definition of ECMAScript entities. For example. assignment operators. and String. additive operators. and the comma operator. TypeError and URIError. RangeError. the Number object. primitive values. an object is a member of the remaining built-in type Object. the Boolean object. Properties are containers that hold other objects. ECMAScript syntax is relaxed to enable it to serve as an easy-touse scripting language. make the Framework a viable solution that merits further development and support. EvalError.72 Appendix B value of the property has no effect. functions or methods. the String object. ECMAScript operators include various unary operations. The innovative techniques employed by the Mobile framework. Number. or methods. ReferenceError. equality operators. and defined functions are not required to have their declarations appear textually before calls to them. the Date object. SyntaxError. The enterprise solution vendors have yet to fully address the mobile enterprise applications market for cell phones connected to Enterprise Web Services. the Function object. bitwise shift operators. and a method is a function associated with an object via a property. These built-in objects include the Global object. ECMAScript also defines a set of built-in operators that may not be. the Object object.

The Mobile Application Framework presented in this paper allows to overcome the main limitations imposed by the mobile environment: occasional connectivity and limited memory. pro-actively preload relevant information from the server and allow for the application to function in a disconnected mode. store and query data.ECMA Script 73 large portion of operations currently performed by desktop applications can be performed by mobile applications just as well. allowing ubiquitous data access and enabling the advent of a new generation of mobile business. the Framework uses a compressed RDF format to efficiently exchange. This approach doesn't require intensive Java coding and significantly reduces application development and maintenance cost. Main advantage of our design is using the knowledge of the business object structure and data access statistics to store only the data required by the user. The world of technology is clearly moving towards wireless solutions and our mobile framework greatly contributes to this trend. In addition. . The methodology described in this paper provides a structured approach for the migration of the existing desktop applications to mobile devices by pruning unused parts and using compressed RDF files. It is compatible with all the latest industry standards and makes migrating existing business systems to mobile devices a feasible task. perform local querying on the indexed data.


rfc 4287 [5] Microsoft Developer Network (MSDN). March 2003 [6] Advanced Linux Programming by Mark Mitchell.URL: [3]. [10] C++−dlopen−mini−HOWTO http://www.published by New Riders Publishing ISBN 0-7357-1043-0 [7] Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma.isotton. Special Edition. The Atom Syndication Format. of CodeSourcery LLC. and John Vlissides ISBN 0-201-63442-2 [8] IETF on-line IPR repository [9] STR2000 Bjarne Stroustrup The C++ Programming Language. ISBN 0−201−70073−5. Standard ECMA–262: ECMAScript language specification. Jeffrey Oldham. MSXML Interfaces [4]. Consuming Web Services with the Microsoft .NET Compact Framework. Ralph Johnson.com/howtos/C++−dlopen−mini−HOWTO/. Richard Helm.Addison−Wesley. .References [1] Service Oriented Architecture(SOA) and Specialized Messaging Patterns [2] December 1999. and Alex Samuel.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->