Service-Oriented File Sharing

Transcription

1 Service-Oriented File Sharing Michael Sobolewski, Sekhar Soorianarayanan, Ravi-Kiran Malladi-Venkata SORCER Laboratory, Texas Tech University, USA Abstract The major objective of the Service Oriented Computing Environment (SORCER) [1] is to form dynamic federations of network services that provide engineering data, applications and tools on a grid [23-28]. To meet the requirements of these service providers in terms of data sharing and managing in the form of data files, the FileStore Service (FSS) was developed as a core service in SORCER. The value of FileStore service is enhanced when both web based user agents and service providers can readily share the content in a seamless fashion. This framework fits the SORCER philosophy of grid interactive service-oriented programming [2], where users create distributed programs using exclusively interactive user agents. The Document Manager user agent is a web-based GUI, which allows authorized users to securely access the FileStore service in the same way as users use their local file system. This paper is structured as follows: first, a brief overview of SORCER is given and then, FSS is described. Next, we discuss how data is passed across multiple services and how providers dealing with parts of data can filter out information from large files using the filter framework. We also discuss how these files are used by different services and managed by web based user agents. Finally we discuss an actual use case of this service in the FIPER project [1] for B2B Fuel Nozzle and Combustor service between GE Global Research Center and Parker Hannifin and also some proposed extensions to the existing system. Key Words Distributed file systems, service-oriented computing, grid computing, concurrent engineering, Jini network technolgy 1. Introduction GE has teamed with Engineous Software, BF Goodrich, Parker Hannifin, Ohio Aerospace Institute, Ohio University, and Stanford University in a four-year effort to develop the Federated Intelligent Product Environment (FIPER) [1-7] under the sponsorship of the National Institute for Standards and Technology (NIST). FIPER strives to drastically reduce design cycle time, and timeto-market by intelligently automating elements of the design process in a linked, associative environment, thereby providing true concurrency between design and manufacturing. This will enable distributed design of robust and optimized products within an advanced, integrated web-based environment. Service-Oriented Computing Environment (SORCER) is built on the success story of FIPER as a next generation grid computing system. SORCER applies object-oriented techniques directly to the network. Its software architecture houses a pool of peer objects called service providers. Since service providers serve each other as well user agents in a uniform way, this type of computing is called service-to-service (S2S) computing where all providers are service peers. The SORCER architecture is simultaneously web-centric, service-centric and networkcentric. The web-centricity enables transparent web-based access to the globally distributed data and the pool of services. The individual services can act within this framework, both in the role of providing services (provider mode) and requesting services (requestor mode). When requesting aggregated services, the SORCER middleware also brokers the requests, delegating them to the appropriate registered component s services. In this paper, we discuss Service-Oriented File Sharing, a novel approach to share data across multiple providers and to manage and access these data using SORCER middleware services. The web based user agent adds to the idea of interactive programming, where the user through web interfaces can manage data files and folders. The same data can be accessed and updated by different service providers and authorized users can monitor data processing activities executed by the service providers involved. Like any other services in the environment, the FileStore Service (FSS) is also a peer which implements a common top-level interface called Servicer. FSS supports filtering out information from remote files, thus reducing the amount of data transfers between providers. The rest of the paper is structured as follows: Section 2 describes the main components of the SORCER middleware and their interfaces, Section 3 describes a web based user agent and the architecture of the Document Manager that is utilized by FSS, Section 4 discusses the FileStore Service and the Filter Service. In section 5 we discuss a use case scenario of B2B Fuel Nozzle and Combustor design between GE GRC and

2 Parker-Hannifin where services collaborate across firewalls using this framework. In section 6, we discuss some extensions on how this framework can be used for 2. Service Oriented Computing Environment 2.1 Context Model A SORCER context model [5] is the basic element of SORCER data structures and is based on the percept calculus knowledge representation scheme [30]. It forms the essential structure of the data being processed. A context model in the SORCER system is represented as a tree-like structure of context nodes. A data node is where the actual data resides. The context denotes an application domain namespace, and a context model is its context with data nodes as leaf nodes appended to its context paths. A context path is a name for a data in its leaf node. The leaf node might contain any object and in particular an object that represents a file, for example a URL. A special container object called ServiceNode acts as a wrapper that holds a reference to a remote document object. 2.2 Services In SORCER any service is identified by the interface it implements. All services implement the common interface called Servicer, other than service specific interfaces. Hence all providers are peers, which can communicate with one another via the Servicer interface. A service provider takes a context as argument of service request and selects data nodes on which it has to provide service. Then, the provider returns an output context that contains the result of provided service. The data, which a provider generates, can be in the form of a file, which is stored in a remote location. An object called DocumentDescriptor represents the remote references to files in the FileStore. These DocumentDescriptors reside inside ServiceNodes in the context, which acts as a linkage for the remote document references. Any provider or user agent can remotely access these documents programmatically or through GUI in a seamless way using FSS. Certain parts of the document can be filtered out with the help of Filter associated with its ServiceNode. 2.3 Interactive Service Oriented Programming Conventional programs are still based on writing hundreds of lines of codes. In SORCER, once providers are deployed, jobs (service-oriented programs) can be built using interactive tools. Thus we can create programs in which each task is like a line of code, which is actually a distributed activity in the network. The web based user agent for service-oriented file sharing is another SORCER tool, which allows the user to view and maintain files and folders in an interactive way in remote locations. Thus, integrating the two tools adds a new dimension to the philosophy of interactive service-oriented programming. collaboration among multiple replicated file store services in a P2P environment. Now, users can upload files and attach the files to a particular ServiceNode in the context and let any provider execute the task. The provider can now programmatically access the shared data in these files and can choose to update that information using FSS. 3. Document Manager Generic Application (GApp) Document Manager (DM) is an enterprise wide Document Management system that allows managing all types of documents across distributed enterprise. The initial GApp toolkit was developed at GE Global Research Center and multiple web-based applications have been developed for multiple GE business components. DM allows finding the shared information effectively, enabling better collaboration, and reducing duplication of effort. To manage the life cycle, DM manages multiple versions of all kinds of documents from authoring through review, approval, notification, distribution and archiving. DM uses Access Control List (ACL), Access Class and Export Control schemes for finer grade security control of all documents. For secure transfer of files, SSL can also be enabled for the file upload/download. Every user logged into the DM system is treated as a principal and certain default permissions apply to the user based on the user s role in the system. These permissions are controlled by rule-based access control properties, which can be changed dynamically in the system. Over the default permissions of the user in the system, more access can be granted or denied using ACLs. An ACL can be attached to any object (folder or document) in the system and accordingly the ACL object guards the object in the system. The DM client and server are presented in more details in the following sections. 3.1 DM User Agent The web based DM user agent is a zero installation client, and it aids the end users for interactive document management. End users can access DM through a web applet-based user interface, which allows restricted users to securely use the FileStore service in the same way as a user uses his local file system. The Document Manager is built over the GApp framework and all GUI componets are built using Model- View-Controller (MVC) paradigm [29]. Hence the view of the system can be customized with the shared model, which is the synonym for shared data. Fig. 1 captures the DM user agent. In Fig. 2 the UML class diagram of the client GUI is presented. All the business logic, on the client as well as the server side, is implemented using the command design pattern [19].

3 College of Engineering, and Dean of the Graduate School. at Texas Tech University. 3.2 Server Side Server maintains its own pool of database connections and resources. Its worker thread is spawned for each client interaction. The workers are pooled for efficiency. Also the connection objects are pooled and are used by the ProtocolStatement in each command. The commands encapsulate the business logic for specific functionality. The command factory for a command request returns right commands to be executed (see Fig 3). The application server s ACL manager (AsAclManager) maintains the access control for the objects. Access control can be decided based on an ACL for individual objects or policy based access control, which is more scalable (see Fig. 4). FSS exposes the GApp DM as a service in the network, providing framework for uploading, downloading, filtering etc. Figure 1. The DM web-based user agent. Figure 3. Server-side command dispatching. Figure 2. The GApp MVC Paradigm and client command dispatching The web agent allows for multiple users to create a folder hierarchy with ability to lock/unlock, freeze/unfreeze, update and move any folder. Based on these operations, the meta-information associated with any documents is changed. It also adds additional security features like marking any folder as export controlled, providing access class and providing access control list. The same security features are available to the documents inside a folder. Documents can be created under any folder just as a user creates in his local file system. These documents are version controlled and each document can have multiple versions associated with it. Every document is associated with a current version. Users can associate any version of the document to the current version. DM has been used to mange all documents by the search committees at Computer Department Department, search for Dean of Figure 4. The GApp Command execution framework. 4. FileStore Service The FileStore service is like any other service in the SORCER environment. FileStore services can be replicated in SORCER to form true peers that can join the community dynamically. With such a framework in place,

4 now the whole network looks like a heterogeneous shared file-system. Files may be located in multiple locations but may be logically grouped together under the same name space, which forms a kind of virtual folder. 4.1 Design A DocumentDescriptor concept is similar to a file descriptor, but in our case contains attributes of a document. The DocumentDescriptor object encapsulates an input and an output stream objects that should be bound to remote input and output streaming servers spawned by FSS for each request of file upload or download respectively. FSS is designed as a Jini [10-14] service and implements RemoteFileStore interface described as follows: } catch (Exception e) { e.printstacktrace (); public interface RemoteFileStore { } DocumentDescriptor getinputdescriptor (Documentdescriptor); } DocumentDescriptor getoutputdescriptor (Documentdescriptor); In order to upload a document, the user agent sets information in a DocumentDescriptor like the folder name, name of document etc. Once the handle to the document is prepared and returned (see Fig. 5 and 6), to upload the file the user agent does the following: documentdescriptor = remotefileserver.getinputdescriptor(documentdescriptor); try { ((OutputStreamProxy) documentdescriptor.out).upload (clientfile) } catch (Exception e) { e.printstacktrace(); } By calling getinputdescriptor on the FSS, the FSS service returns the updated document descriptor and starts the RemoteOutputStreamServer (see Fig. 5 and 6). The RemoteOutputStreamServer is embedded inside the OutputStreamProxy, which is embedded inside the DocumentDescriptor and passed back to the client. Now the client can call upload via the OutputStreamProxy, which is embedded inside the DocumentDescriptor. Similarly for downloading a document, the user agent does the following. documentdescriptor= remotefileserver.getinputdescriptor(documentdescriptor); try { ((InputStreamAdapter)documentDescriptor.in).download (outputfile); The above code snippets explain how the documents can be programmatically uploaded or downloaded via the FSS Service. FSS is built on the top of the GApp Document Manager. This DM layer manages all the metainformation and security aspects of the documents. The architecture of this layer is briefly described in Section Filter Service Figure 7. Service context data filtering. Figure 5. The FSS streaming class diagram. Figure 6. The FSS Document Descriptor. Along with a DocumentDescriptor, the ServiceNode may conain an additional object called a Filter. Filters are used to filter out some specific information referenced by a ServiceNode object. The information can be from the database, document etc. Each ServiceNode can have own Filter. The UML diagram of the design for context data filtering is illustrated in Fig. 7. For documents, FileFilters have been developed. Each FileFilters contains a FilterReaderWriter to handle remote reading and writing of data in files via the FSS Service. FSS also provides additional service called a FilterService. This service helps in remote setting and getting specific data as described altogether by a DocumentDescriptor and a Filter. Thus, the client can selectively read and write to files in remote locations. Collaborative users can also use this technique for real time editing of files.

5 6. B2B Scenario with File Store No mechanism for guarding the files based on access control list specified by users at both ends. In this section we discuss the use case scenario of B2B Fuel Nozzle and Combustor design across enterprise GE GRC (NY) and Parker Hannifin (OH). We later discuss how the File Store service helps resolve many of the issues of sharing data across different business organizations guarded by firewalls. In the interactive design of combustor, one of the important aspects of the analysis is a fuel nozzle validation when the combustor geometry has been updated. Parker-Hannifin specializes in nozzle design and validation services and the GE GRC combustor service requires these services to be accessed for complete validation of the updated combustor geometry. The layout of the solution for this B2B interaction is shown in Fig. 8. File Store service helps in resolving the issues mentioned above. Clients at both ends can now upload their files via the File Store Service located in their own respective Virtual Organization. Services in both ends can access data stored on the other side via Document Descriptors communicating with the FileStore Service sitting in the other end. Not only the FileStore can be used to share information across services; they can also be used for smart filtering of data using the Filter Service provided by all FileStore Services. Thus we can avoid transfer of large chunks of data across firewalls. The ASACLManager, (see Fig. 4) takes care of guarding individual business objects (including documents), based on the Access Control rules set by the user or individual services, whoever is responsible for creating the document. All validation of requests is done by FSS based on credentials passed from the other end on whose behalf the current service is being executed. 7. Collaboration with Document Manager Consider a global manufacturing company, where engineers from several countries are at work on a new product. In each country, there could be multiple local organizations each independent of each other. To improve the flow of information among these widely distributed team members, it is very important to have a decentralized document management system with replicas of the documents and meta-information in various locations and these documents must be accessible by the client without having any information about the location and other details of the document. Also, it must be noted that the clients must also be able to share documents for large-scale collaboration inside the VO [27]. Figure 8. GE/Parker B2B conceptual architecture. The GRC Perimeter Network or GRC DMZ consists of the standard GRC HTTP proxy server, screening security router(s) and the FIPER sfiper-crd.crd.ge.com DMZ host used as a SSL FIPER Extraportal (FIPER application proxy server). Currently the FIPER DMZ host allows incoming connections from selected Parker hosts and only outgoing connection to fiperdev.crd.ge.com. Thus services can communicate with each other with the help of Extraportals in both ends. Though services can communicate with each other, the following things were missing for this B2B interaction. No data management between the two services at both ends. Security is at compromise if there is no validation on the access of data by specified users from the other side. Keeping in mind the above mentioned requirement, we propose a scalable distributed version of the FileStore Service. In this scheme, any peer can share files in the network. All meta-information about the documents which a peer decides to share, are maintained by a special set of peers called FileStore Peers (FSP). These set of peers form a virtual group called FileStore peer group (FSPG). A FSPG is responsible to store the metainformation of any document published by a client. For data replication of the meta-information and scaling this framework to large number of peers inside a VO, any peer can join and leave a FSPG. Other than managing metainformation, a FSPG actively collaborates for the dynamic discovery of location of any document represented by a DocumentDescriptor and initiate the binding between the requestor who s requesting for the file and the provider who provides the file. Typical sharing and downloading of files inside a VO, in such a framework is shown in Figure 9.

6 7 5 Virtual group of FSP Figure 9. File Store peers 1 2 Provider Peers FileStore Peers 1) FS Peer joins the FS Peer Group 2) For sharing file, Provider peers (includes FS Peer) can store file and request FS Peer to store Meta information. 3) Request for a file based on DocumentDescriptor 4) Peers resolves the location of the requested file 5) Binding initiated 6) Reference of the location peer returned 7) File downloaded via stream For collaboration among multiple VO s we face altogether a different set of challenges. One of the major issues is the presence of firewall. We need to create the same virtual group of FSP s which would be able to effectively discover location of files across firewalls and NAT thus building a lager virtual group of FSP. Also the framework should support binding between two peers for download or upload of files across VO s. The solution to the above problem lies in the effective use of Firewall/NAT friendly protocols like HTTP or HTTPS for searching and downloading document across VO s. Thus every VO will contain a special peer called the Router FSP. These set of router peers collaborate among each other the same way as the FSP s collaborate inside a subnet for storing and searching of different documents. The only difference is that the router peers use http protocol to bridge the VO s. Once the location of any document being searched is resolved between the requestor and provider, the document descriptor is returned to the requestor. This document descriptor contains the input stream proxy, which uses http protocol to download files from clients across VO. The different components in the proposed framework are described in figure 10. The solution to the problem that peers inside firewall can communicate to clients outside, but not vice versa, lies in our choice of technology described next. Provider Peers FileStore Peers Router Peers Virtual FS Peer Group 2 1, 5 Figure 10. File Store peers across VO 3 Subnet Request for a file based on DocumentDescriptor 2,3. FS Peers resolves the location of the requested file 4. Binding initiated 5. Reference of the location peer returned 6. File Downloaded via stream Our choice of technology for managing the peers inside the VO is Jini [11-19] as it is more object oriented, and service based than other P2P solutions. FSP joining the FSPG can easily be discovered by other FSP s inside the VO and they can actively collaborate among each other. But for the collaboration of peers across firewalls, we use JXTA technology [22, 23, and 29]. Using this technology, router peers joining the VO can discover among themselves using the Peer Discovery Protocol defined by JXTA. Once these peers discover themselves, they can actively collaborate among themselves by passing messages across each other. JXTA aids in peer communication from both inside to outside and outside to inside of firewalls by the following trick. A peer inside a firewall uses a router peer either located outside the firewall or visible outside the firewall to traverse the firewall. Peers attempting to contact a peer behind a firewall connect to the router peer, and the peer behind the firewall periodically connects to a router peer. When the internal peer connects to the router, any incoming messages get pushed down to the peer in the HTTP response. Also JXTA uses pipes which abstract the transport layer for end to end communication between different peers in the network. Hence we can make use of this abstraction to aid the communication via the output stream proxy of the document descriptor for download and upload of files across peers in different networks. Conclusions The presented zero configuration to file sharing is a novel service-oriented approach to share data among different file service peers. The introduction of Document Descriptors and Filters aids in maintaining remote references to files distributed across multiple FSS in the network. Thus FSS can be used across heterogeneous file systems located across different virtual organizations. The DM user agent fits the SORCER philosophy of grid interactive service-oriented programming and helps the user in interactive service oriented programming. The access control mechanisms in FSS helps clients to define fine grain permissions for any objects in the system. An experimental version of presented approach was successfully deployed at GE Aircraft Engines and Parker Hannifin. The further extensions of the presented approach, including collaboration of replicated FSS, by integrating JXTA and JINI technology and providing new caching mechanisms for faster access of files and data mining based on meta-information are being investigated in the SORCER Laboratory, Texas Tech University [10]. References [1] Sobolewski,. Federated P2P Services in CE Environments, Advances in Concurrent Engineering, A.A. Balkema Publishers, 2002, ISBN , pp , keynote paper (2002).

7 [2] Grid Interactive Service Oriented Programming, Michael Sobolewski, Texas Tech University, Raymond Kolonay, Air Force Research Laboratory, WPAFB, SORCER Technical Report, [3] Michael Lapinski and Michael Sobolewski, Managing Notifications in a Federated S2S Environment, International Journal of Concurrent Engineering: Research & Applications, December, [4] Sobolewski, FIPER: The Federated S2S Environment, JavaOne, Sun s 2002 Worldwide Java Developer Conference, San Francisco (2002), [5] ( sions/display-2420.en.jsp) [6] Zhao, Shuo, and Michael Sobolewski, 2001, Context Model Sharing in the FIPER Environment, Proc. of the 8th Int. Conference on Concurrent Engineering: Research and Applications, Anaheim, CA. [7] Michael Lapinski, and Michael Sobolewski, August 2001, Notification Manager in the FIPER Environment, Proc. of the 8th Int. Conference on Concurrent Engineering: Research and Applications, Anaheim, CA. [8] Peter J. Röhl, Raymond M. Kolonay, Rohinton K. Irani, Michael Sobolewski, Kevin Kao, A Federated Intelligent Product Environment, AIAA , 8th AIAA/USAF/NASA/ISSMO Symposium on Multidisciplinary Analysis and Optimization, Long Beach, CA, September 6-8, [9] Texas Tech University TechGrid Web site, [10] SORCER Web site, [11] Jini.org Web site, [12] Jini Architecture Specification. [online] 2000 [cited 2002 March 22]. Available at URL: [13] Edwards, W.K. (2000). Core Jini, 2nd ed., Prentice Hall, ISBN: [14] Oaks, S. & Wong, H. (2000). Jini in a Nutshell, O Reilly, ISBN: [15] Newmarch, J., A Programmers Guide to Jini Technology, Apress, Berkeley, California, ISBN: , [16] Freeman, E., Hopfer, S., & Arnold, K.(1999), JavaSpaces Principles, Patterns, and Practice, Addison-Wesley, ISBN: [17] Halter Steven L., JavaSpaces Example-by- Example, Prentice Hall; ISBN: [18] Davis Project. [19] Rio Web site, [20] Grand, M. (1999). Patterns in Java, Volume 1, Wiley, ISBN: [21] IBM Autonomic Computing Web site, [22] Sing Li, JXTA Peer-toPeer Computing with Java, Wrox Press Ltd., ISBN , [23] D. Brookshier, D, Govoni, N. Krishnan, JXTA: Java P2P Programming, SAMS, ISBN , [24] The Globus Project Web site, [25] The Physiology of the Grid: An Open Grid Services Architecture for Distributed Systems Integration. I. Foster, C. Kesselman, J. Nick, S. Tuecke, Open Grid Service Infrastructure WG, Global Grid Forum, June 22, (extended version of Grid Services for Distributed System Integration). [26] Grid Service Specification. S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman; Open Grid Service Infrastructure WG, Global Grid Forum, Draft 2, 7/17/2002. [27] Grid Services for Distributed System Integration. I. Foster, C. Kesselman, J. Nick, S. Tuecke. Computer, 35(6), [28] The Anatomy of the Grid: Enabling Scalable Virtual Organizations. I. Foster, C. Kesselman, S. Tuecke. International J. Supercomputer Applications, 15(3), Defines Grid computing and the associated research field, proposes a Grid architecture, and discusses the [29] JXTA website [30] Sobolewski, M., Knowledge-Based System Integration in a Concurrent Engineering Environment. J. Komorowski and Z.W. Ras (Eds.) Methodologies for Intelligent Systems, Lecture Notes in AI, No 689, Berlin: Springer-Verlag, pp , 1993.