DataGrid Architecture Models V0.2 Lee Momtahan 02/04/02

Transcription

1 DataGrid Architecture Models V0.2 Lee Momtahan 02/04/02

2 Introduction The purpose of this document is to communicate a clear view of the DataGrid Architecture amongst DataGrid Application and Middleware developers using Universal Modelling Language (UML). It is hoped that readers will familiarise themselves with the UML notation [R1],[R2] if necessary. Related Documents [R1] [R2] [R3] [R4] [R5] [R6] [R7] [R8] A UML Reference Card, UML 1.4 Specification, The DataGrid Architecture, DataGrid-12-D Architectural Design and Evaluation Criteria DataGrid-04-D Definition of Architecture, technical Plan and Evaluation Criteria for Scheduling, Resource Management, Security and Job description DataGrid-01-D Data Management (WP2) Architecture Report DataGrid-02-D _2 Information and Monitoring (WP3) Architecture Report DataGrid-03-D WP5 Mass Storage Management Architecture and Design, DataGrid-05-D Document Evolution Procedure T.B.D.

3 Package Diagrams For each of the layers in the DataGrid Architecture [D12.4] we give a Package Diagram 1. Each one shows the software components in that layer and their dependencies to DataGrid and significant non-datagrid components. 1 This term is somewhat non-standard and refers to a UML Class diagram which only shows packages.

4 Fabric Services Layer Fabric Services Fabric Monitoring Resource Management Installation Management Configuration Management Local Resource Mgt Sys 1 Local Resource Mgt Sys 2

5 Underlying Grid Services Layer Underlying Grid Services Replica Catalogue Sevice Index SQL Database Service Storage Element Computing Element Authorisation & Authentication Mass Storage System 1 Mass Storage System 2 Resource Management Confiugration Management Fabric Monitoring

6 Collective Services Layer Collective Services Replica Manager Resource Broker SE Info Provider CE Info Provider Job Submission Logging and Bookeeping Resource Discovery Schema Definitions Replica Catalogue Storage Element Computing Element Every package in Collective Services depends on Authorisation & Authentication Authentication & Authorisation

7 Grid Application Services Layer Grid Application Layer User Interface Resource Broker Logging and Bookeeping Service Authorisation and Authentication

8 Current Discussion Meaning of Package Dependency vs. Testing Dependency Although there are plenty of documents already explaining UML dependency e.g. [R2], we give a brief explanation in order to compare and contrast this with the notion of dependency used in testing which will help with the following discussion. In UML Package A depends on Package B if it possible to change B in some way that forces a change to A. We avoid defining testing dependency, but give examples to show that these relations can be different. Lets suppose Application A uses an ODBC interface to talk to an Oracle database and only speaks to the database through this interface. Lets suppose that Package B also uses an ODBC interface to talk to an Oracle database, but Package B also uses the proprietary Oracle interface. This could be shown as follows:

9 Application A Application B ODBC interface to Oracle Oracle Lets suppose we wanted to change Oracle to DB2. This does not force Application A to change. Application A could be isolated from this change by substituting the ODBC interface to Oracle with an ODBC interface to DB2. On the other hand Application B might need to change as it is relying on the specifics of the proprietary Oracle interface. In testing terms though we might have a bug in Application A which pertains to its usage of the database, and therefore we do want to say that Application A depends on Oracle.

10 In another example Package A creates a database table, Package B inserts rows into this table and Package C reads these rows. In UML we can say that B and C both depend on A (which defines the table schema), as we would if considering testing. But although in UML C does not depend on B it would not be possible to test C before having B available and working, and therefore C does depend on B for testing. Although the author has only an intuitive definition of testing dependency, it is highly desirable to relate the testing and UML definitions of dependency, in order that the diagrams presented in this document may be compared to the testing dependencies presented by WP6 in their test plans. We therefore hypothesise that if A depends on B in UML terms then A depends on B in testing terms (1). We also hypothesise that given a UML dependency relation and a testing dependency relation for which (1) holds, there exists some possible software system for which these UML and testing dependencies are correct. Areas of doubt D1.2, Fig1.1 says that the CE depends on the LB. But the LB is in a higher layer than the CE. Do we no longer have a layered architecture? D12.4, asserts the Service index depends on the SQL DB service but this is not shown in the recent test plan document. D4.2, 9.3 asserts that Fabric Monitoring and Fault Tolerance is dependent upon the Resource Manager but again the is not show in the recent test plan document. Everything, so please be forthcoming with your comments folks! What shall we include as significant non-datagrid software components? I ve just put the LRMS and MSS for now.