The SemSorGrid4Env architecture aims to support the rapid development of applications over heterogeneous data sources: including both sensor networks and traditional databases. Significant value is derived by the use of semantic techniques for service discovery and data integration.
The SemSorGrid4Env architecture comprises of a set of Web services. The backbone of the architecture is provided by services offering WS-* interfaces. These are supplemented with RESTful resource-oriented interfaces provided by the high-level API. The SemSorGrid4Env services can be categorised into three tiers based on the functionality that they provide (depicted in the diagram to the right):
- Application Tier: Consists of services that provide domain-specific support to applications and bridge the gap between the service-oriented and resource-oriented paradigms;
- Middleware Tier: Consists of services that provide extra value through the use of semantic techniques, e.g. service discovery and data integration;
- Data Tier: Consists of services that provide access to data, which can be published either through a stream (e.g. from a sensor network) or through data stores (e.g. from a database). Example services include SNEE-WS and CCO-WS.
The key implications of the SemsorGrid4Env architecture are:
Any service may directly call any other service regardless of which tier they appear in.
Pre-existing, typically external, services may be called by any service, even directly if the means to carry out the interaction are known to the caller.
Data tier services provide a wrapper to concrete data resources. That is, the data tier services virtualise
data sources using a connectivity bridge
with specific drivers that ensure interoperability (e.g. most DBMS products offer JDBC drivers) or else resort to services that act as wrappers and are grounded by one or more connectivity bridges (e.g. a WS-DAI implementation wraps many kinds of concrete DBMS products)
The semantic middleware provides additional value to services in application and data tiers. Broadly speaking, for the latter, it allows them to be federated using semantic integration
and query rewriting; for the former, it allows them to find services on the basis of semantic descriptions
of these services.
Combines service-oriented and resource-oriented aspects.
Full details of the architecture can be found in Deliverable D1.3v1. For further information, please contact