A Generic Framework for Rapid Application Development of Mobile Web Services with Dynamic Workflow Management PDF

Title A Generic Framework for Rapid Application Development of Mobile Web Services with Dynamic Workflow Management
Author Adel Ben Mnaouer
Pages 8
File Size 631.9 KB
File Type PDF
Total Downloads 729
Total Views 956

Summary

A Generic Framework for Rapid Application Development of Mobile Web Services with Dynamic Workflow Management Adel Ben Mnaouer Anand Shekhar Zhao Yi Liang Nanyang Technological University School of Computer Engineering Singapore Email: [email protected] Abstract services. Many road maps suggest...


Description

Accelerat ing t he world's research.

A Generic Framework for Rapid Application Development of Mobile Web Services with Dynamic Workflow Management Adel Ben Mnaouer

Related papers

Download a PDF Pack of t he best relat ed papers 

On t he role of services in ent erprise applicat ion int egrat ion Kost as Kont ogiannis OWL-WS: A Workflow Ont ology for Dynamic Grid Service Composit ion Mike Surridge, Ludovico Giammarino, Nikolaos Mat skanis, Barbara Cant alupo WS-Net : A Pet ri-net Based Specificat ion Model for Web Services Amar Dsilva

A Generic Framework for Rapid Application Development of Mobile Web Services with Dynamic Workflow Management Adel Ben Mnaouer

Anand Shekhar

Zhao Yi Liang

Nanyang Technological University School of Computer Engineering Singapore Email: [email protected]

Abstract This paper proposes a rapid application development framework for creating mobile web services supported by a dynamic workflow engine that displays an interface depending on a specified workflow. The model leverages on existing reference architectures, and open source standards, to create an interoperable, flexible and easy to implement development framework for creating mobile web services. Our model is generic in nature to allow the development of web services for a diverse range of scenarios. The dynamic workflow engine, residing on the client allows for easy updates on the server, and again caters to a diverse set of applications on the client side. The rapid application development model for mobile web services proposed in this paper has been applied to a field service solution workflow and details on the implementation at both the client and the server are provided.

1. Introduction The tremendous growth of the Internet and mobile telecommunications networks over the past decade has ushered a new era in information management and enterprise productivity. Yet even as these systems have arisen in near parallel, they have remained largely distinct. One reason for the gap between these two dynamic phenomena is that disparate technology standards, protocols, platforms, and business models have made it challenging to integrate Internet services with mobile applications. Web Services [1] have provided an effective solution towards bridging this gap with standardization and simplicity as well as interoperability with a range of mobile devices, a hitherto key issue. Mobile Web services [2] are set to be the next engine of growth in the computing world.

services. Many road maps suggest the adoption of web services. [3][4][5]. However, there is no ready-made Rapid Application Development (RAD) and Deployment framework, specifically for mobile access to web services. Web services are also constantly updated, and deployment of new software to mobile device is resource consuming. A need exists for a ready-made generic application development framework that could be reused for various mobile workflow applications without significant effort. A dynamic workflow engine [6][7][8] on the mobile client device, together with a framework of core services [9] could therefore accelerate the adoption of web services in the mobile world kick starting tremendous growth in enterprise mobile application software.

1.2. Objectives This paper proposes a generic model for easy development and deployment of mobile web services. The model is based on existing industry standards such as WSFL [10], XML [11], SOAP [12] and UDDI [13] riding on an http connection. It is a service-oriented architecture and each service is built as a component that can be used in combination or by itself. The framework is enhanced with a generic dynamic workflow management engine. This dynamically provides user interfaces as well as interacts with web services within the framework based on the specified workflow in the WSFL document and the specific applications. The model will be a one-stop easy development solution for a large variety of mobile applications cutting development time drastically.

2. Web services and Tools The architecture we propose makes use of a few web services standards and tools that have already been developed. This section serves as a brief introduction to the standards and tools needed for building the framework.

1.1. Motivation Mobile Web services can enhance enterprise productivity and mobile access to web services and provides greater availability of resources to the mobile user. A broad spectrum of wireless devices across the mobile landscape can access computing resources via web

2.1. What are Web Services? A Web service [4] is a software system identified by a URI (Uniform Resource Identifier, which is a short string that identify resources in the web: documents,

1 Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-2225-4/04 $ 20.00 IEEE

images, downloadable files, services, electronic mailboxes, and other resources) whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML-based messages conveyed by Internet protocols. To make the concept of the web services easy to understand, a Web service is a software application, accessible on the Web through an URL, that is accessed by clients using XML-based protocols, such as Simple Object Access Protocol (SOAP) that is sent over the HTTP protocol. Clients access a Web service application through its interfaces and bindings, which are defined using XML artifacts, such as a Web Service Definition Language (WSDL) file.

2.2. The need for Web services Web services are important to business because they enable systems in different companies to interact with each other, more easily than before. With businesses needing closer cooperation between suppliers and customers, engaging in more joint ventures and shortterm marketing alliances, pursuing opportunities in new lines of business, and facing the prospect of more mergers and acquisitions, companies need the capability to link up their systems quickly with other companies. Thus Web services give companies the capability to do more business electronically, with more potential business partners, in more and different ways than before, and at reasonable cost. Because Web services are written according to standards, all parties work from the same basic design. Companies then add value and business advantage to the basic design to meet the needs of their customers. For example, a company can offer its suppliers the capability to view inventory levels of products the suppliers provide so they can replenish the stocks without the customer cutting separate purchase orders. Web services provide the basic messaging and service-description functions for this kind of electronic relationship, but the suppliers could build on these basic features to provide better services to the customer. And companies can extend these capabilities to other trading partners, since they are built on standards. Also, because Web services are built on standards, they make it possible for many systems developers to enter the market, which increases competition and brings down costs. The competition among vendors also encourages more innovation in the products and services offered to business customers. In addition, basing systems on standards helps prevent being locked-in to a specific vendor or type of computer or software.

2.3. Standards The following is a brief description of the various standards used in the creation of the architecture. kXML. kXML 2 is a small XML pull parser suitable for all Java platforms including the Java 2 Micro Edition (CLDC/MIDP/CDC), specially designed for constrained environments such as the Mobile Information Device Profile (MIDP) devices [15]. It is designed for MIDP and no porting is necessary. It is stable and relatively mature. It works as a pull parser, which means our application can process and display information as it is parsed, as it is being downloaded from the server. kSOAP. kSOAP is a SOAP API suitable for the Java 2 Microedition, based on kXML. Because of its small footprint, it may be suitable for building SOAP-enabled Java Applets as well [16]. kSOAP begins with a class called SoapObject. This is a highly generic class that allows a wireless application to build SOAP calls. A synchronous SOAP RPC session consists of the following steps: ‰ The client composes a SOAP request message with invocation parameters. ‰ The client sends the SOAP request to a Web services server through a standard messaging protocol such as HTTP. ‰ The server invokes the requested service with the parameters extracted from the request SOAP message. ‰ The server composes the return values into a response SOAP message and sends them back. In case of HTTP invocation, the same HTTP connection can be used. ‰ The client receives the response message and then parses the return values into Java data objects for further processing [17]. WSDL. Web Services Description Language (WSDL) is an XML-based language for describing Web services and how to access them. WSDL is a document written in XML, which describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes [18]. WSFL. The Web Services Flow Language (WSFL) is an XML language for the description of Web Services compositions, which contains two types of compositions: ‰ ‰

The appropriate usage pattern of a collection of Web Services: description of a business process The interaction pattern of a collection of Web Services description of the overall partner interactions

2 Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-2225-4/04 $ 20.00 IEEE

In the first case, a composition is created by describing how to use the functionality provided by the collection of composed Web Services. This is also known as flow composition of Web Services. WSFL models these compositions as specifications of the execution sequence of the functionality provided by the composed Web Services. Execution orders are specified by defining the flow of control and data between Web Services. In the second case, no specification of an execution sequence is provided. Instead, the composition provides a description of how the composed Web Services interact with each other. The interactions are modeled as links between endpoints of the Web Services’ interfaces. Each link corresponds to the interaction of one Web Service with an operation of another Web Service’s interface [10].

for the Web service calls from the WSDL files maintained at the server. The key point is that most data reside at the server, and hence any updates to the Web services by the service provider need only be reflected in an updated WSFL file. Any changes to the workflow of the application itself can be made by simply composing a new WSFL file, which the mobile application can then download. The dynamic workflow engine will then execute as per the new workflow specified. This provides for great flexibility and ease of development for various scenarios.

3. Proposed Model The proposed model provides for the creation of a set of web services that are generic in nature interacting with a dynamic workflow engine that resides on the mobile client. The dynamic workflow engine uses the WSFL file to call various generic web services to execute a certain specific workflow. The engine itself follows a workflow based on a WSFL file it downloads from the server. The WSFL file is updated frequently by copying the new file from the server.

3.1. Design Considerations The key issues while considering the design framework includes: a. Security – Web service security standards are used. Along with a PKI [19]. b. Connection model - always connected/data residing primarily on the server. c. Ease of development for various kinds of applications. d. Interoperability of solution with various platforms and mobile devices. e. Service orientation - each service should be used individually, and in combination like building blocks [20]. The model will address these issues in turn.

3.2. Model Description The key feature of the model is the dynamic workflow engine based on the update in the WSFL document. The following sequence diagram illustrates the working of the workflow update feature. First, the dynamic workflow engine retrieves the appropriate workflow document (WSFL file) from the server. The connection is made on a simple http connection. It then parses the WSFL file to determine the sequence of execution of Web services and the parameters required from the WSDL file of the respective Web services. It then retrieves the required information

Fig 1: Dynamic workflow architecture The dynamic workflow engine allows for multiple use case scenarios and a wide variety of applications by filling in respective fields in generic form templates for the user interface. For example, a particular form for viewing fields in a database is filled by the engine with the values from a server retrieved using a Web service. A sample application and possible scenarios of deployment will be discussed in later sections. The Web services implementation sits on the mobile application server. The web framework is depicted in Fig 2. Within this domain we can specify a set of Web services on the application server that will cater to the needs of almost all possible applications.

3 Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-2225-4/04 $ 20.00 IEEE

The Framework consists of a set of generic Web services that can be used over a variety of applications. The set of Web services consists of the set of services in the WSRA reference architecture [21] authored by SUN Microsystems and Infocomm Development Authority of Singapore as well as a few Web services developed specifically for mobile applications. The Framework will provide a base starting point for mobile web applications development. The framework consists of a compact set of services for rapid application development for various scenarios. This is adapted from the WSRA specification proposed by SUN, IDA and JSSL (Java Smart Services Lab). Our idea is to adapt this framework in particular to mobile applications and base the workflow updating on WSFL.

Fig 2: Web services framework These web services are dynamic and generic, and may be applied to a number of scenarios. The New Web Services proposed are as follows: a) Single Sign on (Login service) It consists in an aggregate web service that will ensure a single free passage sign on service to access all web services. Its features: it will allow the creation of accounts, login verification and user access management. It will allow administrator to define roles and access rights. It uses a Public Key Infrastructure (PKI) for password verification. b) Update Data source core service. This service allows writing to disparate data sources. Dynamic field specification using XML is also provided. c) Workflow Update. The service will allow downloading of WSFL file over secure connection to the client. The dynamic workflow engine then parses this file in order to drive the client side application. The main function of the update on the internet server is to interact with the workflow engine and provide it with the necessary information it needs. It is a key aspect in our model, and it allows dynamism. These web services are, in addition to the web services, included in the WSRA specification. An illustration of the working of these web services is given below. First, the user logs in, as managed by a single sign on web service. The user may then add records to a database,

delete records from a database, or modify records in a database. Respective web services take care of the respective tasks. There is a logging web service to record all events. The database could hold a variety of data and searches can be specified on the basis of any of the fields of the database. The genericity of the services ensures that any database with any table structure may be used.

3.3. Model Analysis The key factors of our model include: a. Security: The model provides basic security features as provided in the WSRA reference architecture [21]. We may also optionally include encryption of raw soap messages. b. Connection Model: The Architecture is independent of the connection model (always connected or otherwise). As the web services can be accessed by any connection model. c. Ease of development: This is where the strength of our model lies: it is in the ease with which different applications can be developed and deployed with minimal effort. The three generic tasks of viewing a database, updating a database, and deleting records independent of actual fields, and number of fields, makes it applicable to a wide variety of scenarios. d. As with the WSRA specification the proposed model is interoperable with a wide range of platforms and operating systems [21]. It is also compatible with a variety of micro devices as included in the MIDP specification [22]. e. Service orientation – individual web services are tailored to be independent of one another. f. Genericity: one of the key innovations of this model. Both at the workflow engine, and at the server, the model can cater to a variety of applications. The usage of generic schemas allows us to perform the read, write or update services on a variety of tables irrespective of the table structure. The single sign on service loads the appropriate data and authenticates the user. It matches the right application and defines the application environment in terms of the table name, database name, the fields, the services used, etc. But how does this generic schema work? The generic schema is defined for a variety of applications. Fields like col type, col name etc. are included in the insert table. All queries are implemented generically. The values in these can be variables. g. The model is also highly flexible. It can be used as a simplex version with only the core services described above, or it can be used in conjunction with the WSRA services specified in the WSRA specification. h. The dynamic workflow engine, not only caters to different workflows by determining the sequence of

4 Proceedings of the 2004 IEEE International Conference on Services Computing (SCC’04) 0-7695-2225-4/04 $ 20.00 IEEE

i. j.

web service calls, it also determines the different screen flows and defines the user interface dynamically on the mobile phone. The model can be applied irrespective of platforms and can work with a variety of memory constraints. The model is highly scalable, as the server can be replicated easily, completely masking this to the mobile clients. The model can cater to a variety of applications concurrently. For example a salesman may want to get some information on his client, and an engineer may need some technical information from the database. Both of these can be carried out concurrently, using the same web service.

4. Application Example: Field service We now look at applying our model to a sample workflow scenario: A Field Service Solution.

4.1. Problem description and solution Most companies need field service engineers to visit the customer site to provide services. Without wireless access to various Web services, the field service engineer may not be able to know the stock information of the parts and seek manager’s approval in time. The current scenario is showed in Fig 3.

Alert notification is sent to the manager for approval who wirelessly approves the purchase. What this does is automate the whole process and make it mobile. The FAQ can be dynamically updated and the manager can track the engineers and their job lists.

4.2. Use case for field service mobile solution The use case for field service mobile solution is depicted in Fig 4. ...


Similar Free PDFs