Conceptual Design

The IIP is proposed to bridge the communications between devices (i.e. information providers) and services (i.e. information consumers), acting as a service broker between the two entities. Information distribution task is delegated to the broker, so that information providers only need to send newly collected information once to the service broker. The service broker provides convergence for information gathering from various different devices that the patients encounter, as shown in Figure 3.2(b). RESTful Web service interfaces are proposed to be used facing both information providers and information consumers as they are widely used by cloud-based services, and adhere to SOA principles.

Information is shared through “information channels” that are managed inter-nally by the IIP. Information channels belong to information providers, and each in-formation channel contains a piece of inin-formation that can have several parameters.

Information providers can publish new information to information channels that belong to them, and information consumers can subscribe to information channels containing information that they are interested to utilise. Information consumers will get notifications from the IIP whenever there is new information available in the information channels that they are subscribed to, following the standard pub-lish/subscribe messaging pattern. An information provider can have many tion channels, but an information channel can only be associated with one informa-tion provider (i.e. the owner). An informainforma-tion channel is attached to exactly one device, and a device can have many information channels. A device can only be as-sociated with one information provider (i.e. the owner), but an information provider can have multiple devices. An information channel can be accessed/subscribed by many information consumers, and reciprocally, an information consumer can ac-cess/subscribe to many information channels. These relationships are shown in Figure 3.3.

In general, the IIP provides resources that are divided into two categories with two main base URIs, namely https://root/provider/ for information providers (service providers from a SOA perspective), and https://root/consumer/ for information consumers (service consumers from a SOA standpoint), where the root part of the URI refers to the domain of a specific IIP deployment. Following the

1 *

Figure 3.3: Relationships between information provider, device, information chan-nel, and information consumer

REST approach, HTTP methods (i.e. POST, GET, PUT, DELETE) are utilised for exposing the services, where GET is used for nullipotent services, PUT and DELETE for idempotent services, and POST for non-idempotent services. Figure 3.4 shows the main functionalities ot the IIP.

Information Integration Platform - authorise information channel access (user) - deauthorise information channel access (user) - list pending information channel access request - list information channel catalog

- request access (information)

- list pending information channel access request

Base URL: https://root/provider/

Base URL: https://root/consumer/

Figure 3.4: Main functionalities of the IIP

The main functionalities of the IIP with their REST resources for information providers are described as follows.

1. Registration. The IIP provides a resource with URI https://root/

provider/registration/information/for information providers to reg-ister/add an information channel. This resource accepts HTTP POST request with Content-Type application/x-www-form-urlencoded and three pre-defined parameters, namely deviceId, name, and description. The deviceId parameter is a pointer to an existing device in the IIP that belongs to the in-formation provider who sends the HTTP request. If this parameter is not specified in the request body, or specified but no such device exists in the IIP, or the device exists but belongs to other information provider, then a new device will be registered automatically. The name and description parame-ters are optional. The IIP will generate infoId as the identifier of the newly

Proposed Solutions 37

registered information channel, creationDate, and lastUpdateDate for times-tamping. In addition, the IIP will also associate the information provider’s credentials with ownerUsername parameter, and adds it to allowedUsers pa-rameter for access control. If other papa-rameter names (apart from the men-tioned ones) are included in the request body, they are treated as information parameters to store actual values of the registered information channel. For example, a location information can have two parameters, namely latitude and longitude. An XML representation of the registered information channel will be returned in the response body upon successful processing of a request to this resource.

The IIP also provides a resource for information providers to register a de-vice which can contain different information channels that belong to the same information provider, accessible through URI https://root/provider/

registration/device/. This resource accepts HTTP POST with Content-Type application/x-www-form-urlencoded, and two predefined optional parameters, namely name and description. The IIP will generate deviceId as the identifier of the registered device alongside creationDate and lastupdate-Date for timestamping. An XML representation of the registered device will be returned in the HTTP response body.

2. Listing. The IIP provides a resource for information providers to retrieve all information channels that they have registered (i.e. belong to them) via HTTP GET request to URI https://root/provider/registration/

information/ and a resource to retrieve a specific information chan-nel using its infoId via HTTP GET to URI https://root/provider/

registration/information/{infoId}/. For retrieving all devices that belong to an information provider, the IIP provides a resource with URI https://root/provider/registration/device/ that is accessible via HTTP GET request. A specific device can be retrieved using its deviceId at URI https://root/provider/registration/device/{deviceId}/

through HTTP GET request. All resources in this category will return the representation of information channels and devices in XML format.

3. Updating. Two resources are provided by the IIP for updating a registered information channel and a device with URIs https://root/provider/

registration/information/{infoId}/and https://root/provider/

registration/device/{deviceId}/, respectively. Both resources ac-cept HTTP PUT request with Content-Type

application/x-www-form-urlencoded, and require infoId and deviceId, respectively, as identifiers for updating. Accepted parameters are similar to the registration process for both information channel and device, and the lastupdateDate parameter will be updated automatically by the IIP. An XML representation of the updated in-formation channel or device will be returned in the HTTP response body.

4. Deletion. The IIP provides a resource for deleting a specific infor-mation channel using its infoId with URI https://root/provider/

registration/information/{infoId}/, and another resource for delet-ing a specific device usdelet-ing its deviceId with URI https://root/provider/

registration/device/{deviceId}/. Both resources accept HTTP DELETE request for deletion, and 200 OK will be returned as response with XML content confirming that the deletion process has been successful. Dele-tion of an informaDele-tion channel will automatically delete all subscripDele-tions to that particular information channel, while deletion of a device will result in automatic deletion of all information channels (including all subscriptions to them) attached to the device.

5. Publication. The IIP provides a resource for information providers to pub-lish new information to their registered information channels via HTTP POST request to URI https://root/provider/publication/{infoId}/. This resource accepts Content-Type application/x-www-form-urlencoded, and the parameters in the request body can be a subset of information pa-rameters of an information channel (i.e. partial information update). All sub-scribers to the information channel will get notification from the IIP via HTTP POST request with XML representation of the newly published information in its body. The same XML representation is returned to the publisher in the HTTP response body.

Information consumers can receive information that they are interested to use either via a pull mode, where they send requests to specific information channels in the IIP, or by a push mode, where they subscribe to selected information channels, and get notifications from the IIP whenever new information is published by infor-mation providers to the inforinfor-mation channels they have subscribed to. The main functionalities of the IIP with their REST resources for information consumers are described as follows.

1. Subscription. The IIP provides a resource for information consumers to sub-scribe to a specific information channel that they have access to. This resource

Proposed Solutions 39

accepts HTTP POST request with Content-Type application/x-www-form-urlencoded to URI https://root/consumer/subscription/.

The request body can contain four predefined parameters, namely infoId, no-tificationUrl, name, and description. The infoId parameter is mandatory as it points to the information channel that the information consumer is interested to subscribe to. The notificationUrl parameter is also compulsory as it acts as the endpoint where the notifications should be sent to. The name and descrip-tion parameters are opdescrip-tional. An XML representadescrip-tion of the subscripdescrip-tion will be returned in the HTTP response body. The infoId parameter can be replaced by deviceId if the information consumer wants to subscribe to all information channels that are attached to a specific device.

2. Listing. The IIP provides a resource for information consumers to retrieve the latest information from all information chan-nels that they have access to via HTTP GET request to URI https://root/consumer/listing/information/. This mechanism corresponds to the pull mode of information retrieval. Information consumers can also retrieve the latest information from a specific in-formation channel using its infoId via HTTP GET request to URI https://root/consumer/listing/information/{infoId}/. A time-range information retrieval is also possible to be applied to this resource by using a query string with parameters fromTime and to-Time. For example, if an information consumer wants to retrieve all information from a specific information channel between 23rd and 30th of October 2013, it can send an HTTP GET request to URI https:

//root/consumer/listing/information/{infoId}?fromTime=2013-09-23T00:00:00&toTime=2013-09-30T23:59:00. The parameters’

values, which are the actual information being passed through information channels, will be returned in the HTTP response by the IIP in XML format.

In addition, the IIP provides a resource for information consumers to list all of their subscriptions via HTTP GET request to URI https://root/

consumer/subscription/. An information consumer can list a specific subscription using its subscriptionId at URI https://root/consumer/

subscription/{subscriptionId}/ and list all subscriptions to a spe-cific information channel using its infoId at URI https://root/consumer/

subscription/{infoId}/. The IIP will return a list of subscriptions in XML format in the HTTP response body.

3. Updating. A resource for updating a subscription to an information channel is provided by the IIP for information consumers via HTTP PUT request to URI https://root/consumer/subscription/{subscriptionId}/ with Content-Type application/x-www-form-urlencoded. subscriptionId is mandatory to be included in the URI as the identifier of a specific subscrip-tion, and accepted parameters are similar to the subscription process, namely infoId, notificationUrl, name, and description. Partial parameters update is possible (i.e. only a subset of the accepted parameters are included in the re-quest body), and the lastupdateDate parameter will be updated automatically by the IIP with the most current time. An XML representation of the updated subscription will be returned by the IIP in the HTTP response body.

4. Deletion. The IIP provides a resource for information consumers to delete/remove their subscriptions to information channels either by us-ing subscriptionId as the identifier at URI https://root/consumer/

subscription/{subscriptionId}/, by using infoId as the identifier at URI https://root/consumer/subscription/{infoId}/, or by using deviceId as the identifier at URI https://root/consumer/subscription/

{deviceId}/. The resource accepts HTTP DELETE request, and 200 OK will be returned in the response with XML content confirming that the dele-tion process has been successful.

5. Notification. There is no specific REST resource for notification of newly published information to an information channel provided by the IIP. In-stead, information consumers should provide endpoints (indicated by noti-ficationUrl parameter in a subscription) for handling notifications sent by the IIP.