Grid Computing Infrastructure Architecture Document

2.1 Architectural Representation

The architecture of the reference application is represented following the recommendations of Rational Unified Process (RUP). The UML specification of the system has been divided into the following five views.

2.1.1 Use Case Views

Describes the actors and use cases for the system, this view presents the needs of the user and is elaborated further at the design level to describe discrete flows and constraints in more detail. This domain vocabulary is independent of the implementation infrastructure.

We will develop our system taking the following considerations into account.

2.1.2 Domain Vocabulary Views

Describes the key abstractions that make up the domain of discourse. For example the notions of “Client” , “Server”, “Interface” or “Monitoring” are included in the “Grid Enabled Secure Linux Kernel” domain whereas “API's ”, “Resources”, “Number of process in execution ” or “Number of Distributions” are not (though may be included in a module implementation domain).

2.1.3 Service Views

Describes the high-level components that make up the dynamic aspects of the system. A fundamental constraint of this architecture is that it follows a Service-Oriented architectural style as opposed to a distributed object broker style for example.

2.1.4 Portal View

Describes the behavior of the portal infrastructure in aggregating information and presenting it to the user. Key mechanisms, such as information acquisition, query, aggregation, syndication etc. are described here. As far as the user is concerned this is the primary client interface into the Computational Grid information infrastructure.

2.1.5 Workflow Views

Describes potential Workflow structures, by including known and anticipated Workflow scenarios in the architecture we allow the implementers to make certain assumptions on network performance, distribution, system interaction and so forth.

Collectively, the above models form a complete UML specification of the system (the dashed arrows in the diagram below denote a dependency relationship from one model element to another).