[ieee 2006 ieee international conference on e-business engineering (icebe'06) - shanghai, china...

An Aspect-oriented Approach to Developing a Teleworking Grid

Dr. Mark AndersonLiverpool Hope University

[email protected]

Laeeq AhmedLiverpool Hope University

[email protected]

Abstract

The field of teleworking is one which can be closely linked to the development of virtual environments. The aim of these environments is to create widely distributed applications to support the communication and collaboration of workers in a Virtual Office or Virtual Community. To that extent, there appears to be much in common with the field of Grid Computing which itself aims to support distributed resources and users in Virtual Organisations through a service-oriented architecture. In this paper we explore the similarities between these fields and the potential offered by Grid Computing. We also examine some of the potential limitations in the way that Grid services are currently developed, and propose an alternative strategy making use of Aspect Oriented Programming (AOP) to enable the creation of fully dynamic services to support the needs of an agile user base.

1. Introduction

The notion of teleworking, which is the concept of being employed either full- or part-time, and working away from a base site, has been around for well over a decade. The common model is for employees to work in virtual offices, forming virtual communities, and collaborating through distributed toolsets. Some research in the field concentrates on the evaluation of the success of teleworking [1], or case studies of the practice being employed [2][3]. Other research considers the support of teleworking through the development of software or middleware solutions on a distributed system [4][5].

Whilst the development of distributed systems has evolved rapidly over recent years [6], there remain limitations related to individual nodes in a system. These relate to the hardware being used such as the processors and hard disks [7]. Following recent work in the field which explores the use of Web Services to

support teleworking [8], a potential solution to these limitations for teleworking appears to lie in Grid Computing.

2. Teleworking and Grid Computing

The field of Grid Computing has been evolving over the past decade or so, having been derived from the notion of electricity grids; that is, on-demand facilities that are distributed and adaptable to the user needs. Two key areas in which Grid Computing can be closely aligned with concepts derived for teleworking are

1. The dynamic nature of a Grid means that services and resources can be added or removed as required. This aligns well with the agile and dynamic nature of a teleworking environment.

2. The notion of Virtual Organisations which relate physically disparate resources and users together. This will involve issues of trust, authorization and authentication to be successfully implemented. The relationship with teleworking lies in the concept of forming a community that will logically join geographically separated resources.

The technology currently employed to implement grid-based solutions is now mature. Open Grid Services Architecture (OGSA) uses a common representation for storage and computational resources, networks, programs, and so on [9]. All are treated as services—network-enabled entities providing facilities through the exchange of messages [10]. Grid toolkits based on OGSA, such as Globus [11], are closely aligning themselves with emerging web service standards. In particular, this features the embodiment of the Web Services Resources Framework [11][12]. As such, these toolkits offer an ideal opportunity in which to develop teleworking tools using Grid architecture, an architecture which is a stable framework to support a service-oriented architecture.

IEEE International Conference on e-Business Engineering (ICEBE'06)0-7695-2645-4/06 $20.00 © 2006

Indeed, a proposed architecture for using a Service-oriented Architecture (SOA) based on Web Services to support teleworking has identified a number of categories where teleworking could be facilitated [8]. The natural extension from the use of Web Services to Grid Services ensures that perceived benefits can be retained with the added features available in Grid Services to further augment a virtual teleworking environment. A good example is the consideration of a Virtual Organisation as a policy domain overlay [13] which can offer interoperability between security mechanisms at geographically diverse sites through outsourcing of policies for coordinated resource sharing.

3. Developing Grid Applications

The development cycle for a Grid service using Globus is a five stage process [14]:

1. Define the service interface2. Implement the service in Java3. Create the service deployment descriptor4. Generate a grid archive file for the service5. Deploy the service into a container

The implementation of the service is typically coded in Java, an object-oriented and platform independent programming language [15]. Therefore, a service should be designed using Object Oriented (OO) methodologies. Whilst the issues around OO Programming have been well documented [16], there remain inherent problems with OO methodologies which may be present in the design and implementation of Grid services.

4. Object-oriented to Aspect-oriented Programming

When a problem is solved using OO models, the work performed to solve the problem isn’t easily reused across objects due to confinements in OO models to a particular problem domain. Furthermore, there may be requirements that extend over all the objects within a domain which require code to be developed for solving that problem repeatedly for each object affected [17]. Whilst it appears that OOP has the characteristic of modularization, it is good at modularising core concerns but not all that good when it comes to modularising the crosscutting concerns.

For example, consider a company employing teleworking services which develops and deals with a

set of products. In the design of the services to support teleworking within the company there are two distinct hierarchies supporting the development and the sales of the product (see Figure 1).

Development Retail

Research Design Sales Customer Support

Figure 1: Service hierarchy

The services could be management services to track project progress, or to identify sales issues. OOP would require inheritance to be used to enable sub-classes to inherit behaviours or properties from their parent class. However, the system analysts/developers would need to know all these concerns in advance of the system design [18]. In real world scenarios many of these concerns might not be known, possibly until quite late in the development process.

It is important to note here that there are behaviours added that have no relation with the original object’s domain. The design operation has nothing to do with how communication takes place, how operations are protected using security mechanisms or how workflow of the service tasks is managed. The case is similar for each service, regardless of the hierarchy in which that service exists. So communication, security and other behaviours are the concerns that are independent of the object problem domain and this independence makes these concerns crosscutting.

Aspect Oriented Programming (AOP) is used to solve these problems by separating the crosscutting business concerns from the original problem domain [18]. OOP solves common concerns by capturing common features on top of a class hierarchy. Conversely, AOP attempts to modularise common features in a software layer that spreads across classes regardless of domain, thus increasing modularity of the software. Using AOP, programmers can dynamically change a static OO model and create a system that can grow to meet any new requirements that arise.


Figure 2: Proposed architecture for AOGP

The aspects can be kept in a single location rather than code being spread across an OO model. In this way, AOP can address normal OO complexities resulting in a more modularised architecture for the resultant code.

5. An Aspect-oriented Grid Approach

Applying AOP to the design and implementation of Grid Services for teleworking can bring great benefits to the development of services to support communities of remote users. These benefits can be seen as being

Simplification. - only components specific to a service will need to be analysed and implemented.Reusability. - modularity is increased through the use of aspects which can be woven in where required.Extensibility. - services can easily be modified or extended by changing the aspects. All services using that aspect will adopt the modification.

To make use of these benefits, a new architecture has been designed to support the implementation of Aspect Oriented Grid Programming (AOGP) (Figure 2). The grid resource allocation process is adapted to enable the modification of services by the discovery and weaving of aspects into a service if a match for a client’s requirement cannot be found. The notion of incorporating AOP into Grid application development promotes the concept of agile Grid applications, allowing Grid services to adapt to the client demands.

AOGP forms a core of the GATEway project (Grid-enabled Agile Teleworking Environment). The goal is to create a framework for an adaptive environment to

support teleworking through the adoption of emergent technologies, such as Grid Computing and Aspect-oriented Programming. A prototype has been created using statically woven cross-cutting concerns within a Grid Service to investigate the potential of AOGP. The goal of this phase of the project was to explore the impact and issues of AOGP with regards to developing Grid Services. This phase has now completed and first results indicate that the identified benefits noted above will prove achievable using this technique. Most notably, the simplification of code by extracting those components which are cross-service should enable a rapid development process for a flexible, and extensible, model.

Future stages of our work will concentrate on two key areas of development. The first will explore the concept of dynamically weaving cross-cutting concerns at both the service and the client side of a Grid application. The second will focus on the identification of those components that we should, and can, consider as aspects within the framework.

6. Conclusion

Over the past decade, the field of teleworking has changed considerably. A move to support teleworking adopting Service Oriented Architectures, such as Web Services, can simplify the development of such systems and leverage existing standards, such as security mechanisms. However, there remain challenges to overcome technical limitations of existing platforms. A solution to these limitations is promised in the emergence of Grid Computing as an architecture on which service-based applications can be developed.

Grid Client

Crosscutting Concerns

Matchmaker

Aspect Discovery

Weaving service

Resource Allocation

1.Service Request

2.Near match

4.Found aspects

3.Find

5.Weave

Required Service

Interaction

Find Match


A means of simplifying the lengthy development cycle for the implementation of Grid services has been presented using AOP. The development of AOGP has been based on clearly defined benefits demonstrating that an alignment in the fundamental properties of both technologies suggests a fusion would offer benefits to the development of Grid-based applications. We are in need of a programming methodology that can work well in the type of dynamic environment Grid computing offers. AOP provides dynamic weaving which could support this kind of architecture.

A major property of AOP is that it separates the system-level requirements from other code. The modularity of a system design is increased when compared to a more conventional OOP methodology. In increasing modularity, a cleaner structure for programming Grid-based applications has been identified, simplifying development and maintenance. Furthermore, we have seen through experiments that AOGP is possible, successful and workable.

7. References

[1] Clark, S.D. and Olfman, L. (2000) Testing the simplified decision model of telework: a quasi-experimental study. In Proceedings of the 2000 ACM SIGCPR conference on Computer Personnel Research, pp:102-110.

[2] Grantham, C.E. (1996) Working in a Virtual Place: a case study of distributed work. In Proceedings of the 1996 ACM SIGCPR/SIGMIS conference on Computer Personnel Research, pp: 68-84. [3] Schmidt, B.L. (2000) Issues in teamwork: You can go home again: successful telecommuting for the technical communicator. In Proceedings of IEEE professional communication society international professional communication conference and Proceedings of the 18th annual ACM international conference on Computer documentation: technology & teamwork, pp:25-37.

[4] Dangelmaier, W., Kress, S., Wenski, R. (1997) Telework under the co-ordination of a distributed workflow management system. In Proceedings of the international ACM SIGGROUP conference on Supporting group work: the integration challenge, p128-137.

[5] Sugawara, K., Yu, Y., Ragsdale, B., Hara, H. and KinoShita, T. (2003) Posters: Design of an agent-based middleware for job matchmaking in teleworking community. In Proceedings of the Second International Joint Conference on Autonomous Agents and Multiagent Systems, pp:1128-1129. [6] Coulouris, G., Dollimore, J. and Kindberg, T. (2005) Distributed Systems: Concepts and Design. New York. Addison-Wesley.

[7] Abbas, A. (2004), Grid Computing: A Practical Guide to Technology and Applications. Hingham, MA. Charles River Media.

[8] Braun, I. and Schill, A. (2002) Building a Universal Teleworking Environment Using Web Services. Available at http://www.rn.inf.tu-dresden.de/scripts_lsrn/veroeffent_print/IKS2002.pdf. Accessed on 25/07/05.

[9] Joseph, J. and Fellenstein, C. (2004) Grid Computing. IBM Press On Demand Series. Upper Saddle River, NJ. Prentice Hall Publishers, Inc.

[10] Foster, I., Kesselman, C., Nick, J. M., Tuecke. S, (2002). Grid services for distributed systems integration. Available at http://www.globus.org/alliance/publications/papers/ieee-cs-2.pdf. Accessed on 05/06/05.

[11] Globus Alliance. (2005) Globus Toolkit 4.0.1 Stable Release Notes. Available at http://www.globus.org/toolkit/releasenotes/4.0.1/. Accessed on 22/03/06. [12] Sotomayor, B. and Childers, L. (2006) Globus 4 Toolkit: Programming Java Services. Morgan Kaufmann. San Francisco, CA. [13] Siebenlist, F., Nagaratnam, N., Welch, V. and Neuman, C. Security for Virtual Organisations: Federating Trust and Policy Domains. In The Grid 2: Blueprint for a New Computing Infrastructure. Foster I. and Kesselman, C. (eds). Morgan Kaufmann. Amsterdam. Ch21:353-387 (2004)

[14] Sotomayor, B., (2005) .The Globus Toolkit 4 Programmer's Tutorial. Available at http://www.casa-sotomayor.net/gt4-tutorial/multiplehtml/index.html. Accessed on 22/03/06.

[15] Flanagan, D. (1999) Java in a Netshell (3rd Edition). O’Reilly. Sebastapol, CA.

[16] Scholtz, J., Chidamber, S., Glass, R., Goerner, A., Rosson, M.B., Stark, M. and Vessey, I., (1993) Object oriented Programming: The promise and the reality. Journal of Systems Software, 23, pp:199-204

[17] Kiselev, I. (2002) Aspect-oriented Programming with AspectJ. SAMS Publishers, Inc.

[18] Laddad, R., (2003) AspectJ In Action: Practical Aspect-oriented Programming. Manning Publications Co. Greenwich, CT.


[ieee 2006 ieee international conference on e-business engineering (icebe'06) - shanghai, china...

Documents