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

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


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


1 Organization Profile 1.1.1 Overview: 1.1.1 An Introduction to Service Oriented Architecture 3.2 WebCore 2.2 Mobi Linux 5 5 6 6 6 8 8 Chapter 3 SERVICE ORIENTED ARCHITECTURE 3.1.4 A Reference Architecture for Service Oriented Architecture [1] [1] 11 11 12 13 16 17 .CONTENTS Acknowledgement Abstract INTRODUCTION 1.2 Project Overview vii vii 1 1 1 2 2 2 Chapter 2 BACKGROUND 2.3 Motorola India Research Labs (MIRL): 1.2 Motorola India Operations: 1.2 ECMA Script 2.3 Decomposing the Interaction Model A Reference Model for Service Oriented Architecture 3.1JavaScriptCore 2.1 Webkit Architecture 2.

7 Service composition 3.3.2 Device Specific 39 39 39 40 42 .1 Existing Implementation 7.2 Request-Response via Service Registry (or Directory) 3.1 Mobile Browser: Shared Memory: 31 31 35 35 36 37 38 38 Chapter 7 IMPLEMENTATION DETAILS INCLUDING PORTING 7.1 Request-Response 3.5 Client Tier 3.8 Data push Chapter 4 MOBILE SERVICE ORIENTED ARCHITECTURE 4.3 Subscribe-Push 3.1.6 Architectural Conventions Spanning Multiple Tiers [1] 20 22 23 24 24 25 26 3.3 Device Layer Daemon: 6.7.1 Problem Statement 27 27 28 Chapter 5 CLIENT-SERVER WITH MOBILE THIN CLIENT & BROWSER Chapter 6 IMPLEMENTATION ARCHITECTURE 6.1 Purely OS Specific (Windows V/s Linux) 7.2 Shared Library: 6.

2 Mobile Browser Implementation 7.1 Testing Strategy 8.1 Work Completed 8.3 OUTPUT Screen Shots 8.3 Communication b/w Shared Library and Device Layer 7.4 Porting Implementation 44 45 49 Chapter 8 TESTING 8 .3.1 SOAJavaScript object JavaScript Interface 8.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 .1 Work Remaining 8.2 Test Documentation 8.7.4 Status Presence Service Input Script 8.

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

2 SOA Interaction Model Figure 3.LIST OF FIGURES Figure 2.3 Mobile SOA Communication Architecture Communication Protocol Figure 7.5 Service within Overall Architecture Figure 3.5 Porting Class Diagram Figure 8.2 Browser Testing Communication Testing .7 SOA Request Response Pattern with service registry Figure 3.1 Porting specific implementation Architecture Figure 7.1 Figure 8.4 Client Operation Architecture Figure 3.2 Figure 3.2 Figure 7.1 Webkit JavaScript Object addition Figure 7.4 Overall Communication Figure 7.3 Architectural Frame Work SOA Figure 3.6 SOA Request Response Pattern Figure 3.1 Webkit Architecture Figure 2.8 SOA Subscriber-Push pattern Figure 6.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.

3 Service Manager Testing Figure 8. Browser evolution Figure a.1.4 Testing Individual services Figure a.Figure 8.2 Browser Architecture 53 53 65 68 .

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

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

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


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

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

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

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

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


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.

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

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

are faced with special considerations designing systems from perspective. 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. an interaction proceeds through a series of information exchanges and invoked actions. Architects building Rich Internet Applications (RIAs). 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. There are many facets of interaction.16 Chapter 3 3. . Typically mediated by the exchange of messages.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.

For example.2: a decomposition of the interaction Model (courtesy of OASIS Reference Model for SOA ) As depicted in Figure 3. it can introduce additional details and concepts to provide a more complete picture for those who may implement a particular class. much like an abstract . in a Request-Response behavior model. Data models may be further specialized to match the behavior model if it is other than “Request-Response”. the corresponding data model would have two components – the input (service Request) data model and the output (service Response) data model.4 A Reference Architecture for Service Oriented Architecture[1] A reference architecture is a more concrete artifact used by architects. the interaction model can be further decomposed into a data model and behavior model.2. 3. Reference architectures declare details that would be in all instances of a certain class.Service Oriented Architecture 17 Fig 3. Even if the value is “null”. 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. Unlike the reference model. the service is still deemed to have a data model. The data models are strongly linked to the behavior models. The behavior model is decomposable into the action model and the process model. The data model is present in all service instances. 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.

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

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

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

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

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

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

The service provider pushes changes regarding the service’s details to the registry to which the consumer has subscribed.6: SOA Request-Response pattern(courtesy of Adobe) 3. Regardless. distributed systems and bear these definitions in mind. In aggregation.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. as shown in Figure 3. When the changes are made. Fig 3. The request results in an optional response.6. 3. the service consumer is notified of these . This terminology is common within both OOPSLAxi and UML. 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.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 parts exist independent of the whole and can go on living after the entity that uses them no longer exists.7.7.24 Chapter 3 when the whole no longer exists. the parts no longer exist either.

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

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

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 . value adding services to consumers and enterprise users has challenged the technology developers. The main function of content service is to deliver media contents such as ringing tones. business developers and the mobile service concept developers. The mobile service field became divided into content service and added value functional service. 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. greeting cards and background pictures into the mobile phone.

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

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

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

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. . it’s not always possible to apply the user interface patterns of the pc world to the mobile world. The screen size requires different approaches to efficiently present Information and allow user to work with the on screen information effectively. Despite this. The emergence of “de facto” browser functionality and technologies like browser side scripting has improved the user acceptance of these services significantly. As developing browser based services for the pc in the nineties: But rapid advances can be observed in mobile browsers. Nowadays.

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

One can start with a low capacity server solution and increase the capacity gradually as the service become more popular. The business scalability of browser based architecture is very good. This involves two main areas: the scalability of access to the service and the scalability of the device layer framework. .Client-Server With Mobile Thin Client & Browser 33 server side.



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.1 Mobile Browser: A JavaScript object is added into the existing browser domain.1: Porting Specific MSOA Implementation Architecture The architecture composed mainly three components in addition to a shared memory. the browser will support a new SOAJavaScript object and can be instantiated using . When implemented. 6.

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

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

In the Windows Mobile Implementation.Chapter 7 IMPLEMENTATION DETAILS INCLUDING PORTING 7. a Windows Mobile Implementation of Device layer frame work exists. a native client application can only be the end user for SOA framework. The availability of an open . The lack of an open source browser in windows is one of the major obstacles for providing a browser based implementation.1 Existing Implementation At Present. Since it’s 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.

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

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

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

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

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

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.Implementation Details Including Porting 45 7.2 Mobile SOA Communication Architecture .

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

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.3: Communication protocol in terms of semaphores .

.semaphore) 13: map Response Memory 14: map Semaphores Request Memory DL response Queue DL request Listen. 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.. 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. Proc Registration Listening Thread 2: create Thread 3: do Daemon initilization Browser Shared Library .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.. Client Request Writing Thread Client requ.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...popFront 40: write sendMessage request 41: read request 42: SOAobject. ID(resp mem. Semaphore) 11: wait f or registration response 12: read registration request.48 Chapter 7 Process Reg istration memory 1: create process registration memory Dev ice La..popFront 45: write Response 46: read Response 47: insert response 48: proxy JSobject.sendMessage 38: insert request 39: Q.4 Overall Communication [Interaction Diagram] .notif y Response 49: proxy JSobject..

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


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.1 Testing Strategy Software testing is the process used to assess the quality of computer software. with respect to the context in which it is intended to operate. Software testing is an empirical technical investigation conducted to provide stakeholders with information about the quality of the product or service under test . 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. The browser can be tested by providing a loop back kind of hard coded stuff. The browser is only having the terminal interface. the following components have to be tested independently. . This includes. In MSOA. the process of executing a program or application with the intent of finding software bugs. The MSOA services are defined in the Atom Syndication Format. their results can only be viewed from there logs. The test input to the browser is java scripts.Chapter 8 TESTING 8 .

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

Service Manager Shared Library SOA Object Mobile Browser Input <Java Script> SOAJS Object Context manager Call servic Web servic Fig 8.1 SOAJavaScript object JavaScript Interface . 8.Testing 53 Mobile Browser Input <Java Script> SOAJS Object Shared Library SOA Object Service Manager Context manager Call servic Web servic Fig 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.4: Testing Individual Services Verification can be done checking the responses and also verifying three logs.2. The logs will contain time stamp and message unique Id’s and SOA Object ID’s wherever will be relevant.

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

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

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)."> </form> </center> </body> </html> 8.3 OUTPUT Screen Shots .

4 Status 8.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.Testing 57 8.3. . Only the first level testing of browser is completed 8.3.

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

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


. 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. allowing ubiquitous data access and enabling the advent of a new generation of mobile business. 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. 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. The browser based implementation doesn't require intensive coding at the client side because the JavaScript acts as the client language.It is compatible with all the latest industry standards and makes migrating existing business systems to mobile devices as a feasible task.CONCLUSION The enterprise solution vendors have yet to fully address the mobile enterprise applications market for cell phones connected to Enterprise Web Services.


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

For example. A web browser is a program that retrieves documents from remote servers and displays them on screen. Examples of JavaScript applications include changing element focus.. either within the browser window itself or by passing the document to an external helper application. there are some types of content that the web browser cannot display directly. small extensions that are loaded by the browser. Finally. Scripting code is embedded within HTML documents.64 Appendix A documents. and interpreting mouse actions. Other technologies may be used to improve the visual appearance and user experience. Documents are typically written using HyperText Markup Language (HTML) (Berners-Lee and Connolly. JavaScript. In addition to retrieving and displaying documents.. 2006) allow authors to add layout and style information to web pages without complicating the original structural markup. which allows the author to embed hypertext links to other documents or to different places in the same document. now standardized as ECMAScript (—. It allows particular resources to be requested explicitly by URI. most browsers keep track of recently visited web pages and provide a mechanism for “bookmarking” pages of interest. Raggett et al. 1995. images. or implicitly by following embedded hyperlinks. sound clips. Although HTML itself is a relatively simple language for encoding web pages. 1996). are used to embed these types of content in web pages. Plug-in. altering page and image loading behavior. 1999). They may also store . and the corresponding displayed page is the result of evaluating the JavaScript code and applying it to the static HTML constructs. Data is typically transmitted via HyperText Transfer Protocol (HTTP) (Berners-Lee et al. a stateless and anonymous means of information exchange. such as Macromedia Flash animations and Java applets. web browsers typically provide the user with other useful features. Cascading Style Sheets (CSS) (Bos et al. is a host environment for performing client-side computations. 1999). or video clips..

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

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

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

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

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

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

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

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

allowing ubiquitous data access and enabling the advent of a new generation of mobile business. 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. The world of technology is clearly moving towards wireless solutions and our mobile framework greatly contributes to this trend. The Mobile Application Framework presented in this paper allows to overcome the main limitations imposed by the mobile environment: occasional connectivity and limited memory. perform local querying on the indexed data. In addition. It is compatible with all the latest industry standards and makes migrating existing business systems to mobile devices a feasible task. . 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. pro-actively preload relevant information from the server and allow for the application to function in a disconnected mode. the Framework uses a compressed RDF format to efficiently exchange. 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.


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

Sign up to vote on this title
UsefulNot useful