Service Orientated Architecture
The NERC DataGrid concept is built around scalability and a service orientated architecture. We’ve gone very much for the minimum central control of anything, and very much a bunch of services that are not all integral to getting things done. As you might expect, the more of the NDG services one deploys, the less you have to do yourself, but we hope that we are imposing the minimum on the user of the system (and data). In fact, I think at the minimum, we are imposing only:
- the use of a browser to find data (if they don’t already know where it is).
- the user to login somewhere which is “ndg-enabled”. In practice this requires the user to have their own digital certificate and/or their ndg “login-supplier” to generate a proxy on their behalf.
From then on, the user will be able to deploy as much or as little of the infrastructure we are going to build as they want.
I’m prompted to write these things, because I found this via Savas. In it, Steve Maine, discusses four tenets of service orientated architecture design (from Benjamin Mitchell I think), my summary is:
- Build in explicit boundaries between services (with, by definition, explicit interfaces)
- Autonomous Services avoid hidden implicit assumptions about interactions.
- Policy based Negotiation between services and clients
- Share schema and contract, not type (avoid the baggage of explit type, allow the things on either end to implement them how they like).
I think NDG has been designed in a way that is conformant with these ideas, which are not dependant on any sort of specific web service technology, which is a good thing, because web service technologies are shifting sands from an implementation point of view.
Having been conformant with these ideas, we do put minimal constraints on the users of the system, and that should make it more useful as a data provider toolkit, which was our aim.