This action might not be possible to undo. Are you sure you want to continue?
WEBKIT PORT OF MOBILE SOA
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
DEPARTMENT OF COMPUTER SCIENCE COCHIN UNIVERSITY OF SCIENCE &TECHNOLOGY KOCHI –682022
DEPARTMENT OF COMPUTER SCIENCE COCHIN UNIVERSITYUNIVERSITY OF SCIENCE & TECHNOLOGY, KOCHI-682022
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.
188.8.131.52.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 184.108.40.206 Shared Library: 6.1 Purely OS Specific (Windows V/s Linux) 7.6 Architectural Conventions Spanning Multiple Tiers  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.
Brief History Web Scripting Language Overview 69 71 71 References 75 .
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.
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.
Chapter 3 SERVICE ORIENTED ARCHITECTURE
Service Oriented Architecture is an architectural paradigm and discipline that may be used to build infrastructures enabling those with needs (consumers) and those with capabilities (providers) to interact via services across disparate domains of technology and ownership. Services act as the core facilitator of electronic data interchanges yet require additional mechanisms in order to function. Several new trends in the computer industry rely upon SOA as the enabling foundation. These include the automation of Business Process Management (BPM), composite applications (applications that aggregate multiple services to function), and the multitude of new architecture and design patterns generally referred to as Web 2.0 The latter, Web 2.0, is not defined as a static architecture. Web 2.0 can be generally characterized as a common set of architecture and design patterns, which can be implemented in multiple contexts. The list of common patterns includes the Mashup, Collaboration-Participation, Software as a Service (SaaS), Semantic Tagging
(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
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 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 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.
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.
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.
Chapter 6 IMPLEMENTATION ARCHITECTURE .
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.
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.
"> </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.
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.
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.
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  Microsoft Developer Network (MSDN). March 2003  Advanced Linux Programming by Mark Mitchell.URL: .  C++−dlopen−mini−HOWTO http://www.published by New Riders Publishing ISBN 0-7357-1043-0  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  IETF on-line IPR repository  STR2000 Bjarne Stroustrup The C++ Programming Language. ISBN 0−201−70073−5. Standard ECMA–262: ECMAScript language specification. Jeffrey Oldham. MSXML Interfaces . Consuming Web Services with the Microsoft .NET Compact Framework. Ralph Johnson.com/howtos/C++−dlopen−mini−HOWTO/. Richard Helm.Addison−Wesley. .References  Service Oriented Architecture(SOA) and Specialized Messaging Patterns  December 1999. and Alex Samuel.
This action might not be possible to undo. Are you sure you want to continue?