Infod-OpenSystem

From Aicip
Jump to: navigation, search

This page is to help people use the current implementation of the INFOD model. The description provided in this page is under the assumption that the user has some understanding of the INFOD system.

The current implementation of the system is as per the INFOD version 1 specification[1].

The open implementation would allow people to create entries and subscriptions, and receive notification messages from the INFOD registry using a simple client interface. This page details on a step-by-step procedure towards using the INFOD system with the help of a simple first responder use case.

The figure below describes the INFOD server and client setup.

INFOD.jpg

Users can access the INFOD system through a simple web interface ( stage 2 in the figure). A user would be able to register vocabularies, create entries, vocabulary instances and subscription. The registry then matches entities and notifies individual users of the matched results. The response messages is shown as raw XML message in the web interface. The user can create new entries or subscriptions, and receive new notification messages based on the changes made to the registry. The client can also query for information in the registry using the MetaDataQuery functionality. Examples of vocabularies, constraints and subscriptions are provided, also the user is free to build/test custom applications using this utility.

For the user to integrate custom applications to work with the INFOD registry, the stage 3 utility on the client side. The user can upload jar files, which would send notification messages from the registry to applications running on the users local machine. Instructions on creating the jar file can be found in the last section of this document. It is advised that the user applications use SOAP requests/response to communicate with the client utility.

The implementation of the system can be accessed at the following URL (Best viewed in Mozilla Firefox, also works on Internet Explorer)

http://penguin.ece.utk.edu:8080/INFOD/login.html

http://sntestbed3.ornl.gov:8080/INFOD/login.html (for ORNL internal use only)

The following are the steps towards building a community in the INFOD system.

Use Scenario Descripiton

The figure below shows a simple first responder use case.

Usecase.jpg

The E911 center receives information on an incident and acts based on the incident information. The E911 center would decide on what resources to dispatch based on the incident description. The E911 center is the publisher of information, based on event information received it sends notification messages to the various consumers. The first responders are the consumers in this use case who receive message from the E911 center on how to respond to the incident. The E911 center and the medical services also act as subscriber's creating subscriptions, which detail on the constraints/policies to be enforced when an event occurs.

The use case presented here is a simplified version of reality, this use case is just to demonstrate the functioning of INFOD. More detailed information and extensions to this use case can be found at http://panda.ece.utk.edu/wiki/First_Responder_Use_Case

Step 0 - Create User ID for login

This is not a part of the INFOD spec, this is just a utility for users to create an account and maintain a record of record of resources created in the registry. The client utility logs all the notification message for the user when not active, and the user receives it when he logs into the account.

The figure below shows the user interface. The user first creates an account by registering and can login using the account immediately.

Step0.jpg


Step 1 - Register Vocabularies

INFOD requires property vocabularies and data vocabularies.

Property vocabulary is used to describe and characterize entities within the INFOD registry. In this use case, the property vocabulary is used to describe the emergency services/first responders. Information such as the location, availability(general/current status), capability, capacity(eg: Hospital capacity) are information that can be described through the property vocabulary.

The data vocabulary describes the semantics of the data/information delivered by a publisher and/or datasource. This vocabulary forms the basis of describing the event of interest at the publisher/datasource, which is the data constraint defined in the subscription. In the current use case, the data vocabulary is used to describe the event(incident) in terms of the location, event type, severity, certainty, and response action.

The vocabularies are specified as XSD files.

Property Vocabulary

Data Vocabulary

Step 2 - Create Entries

The next step is in creating publishers, consumers, subscribers and data sources. The creation of an entry involves information such as WS address, name, description, property constraint, and a boolean notification parameter. Name and description tags are for user comprehension. The property constraint describes an entities interest on which other entity to be matched with. The property constraint is described in terms of the registered property vocabulary semantics. The notify input is either TRUE or FALSE, this indicates the user's interest to receive notification messages from the INFOD registry. A value of TRUE, implies the user is interested in notification messages. A Web Service(WS) address is required at the time of creation of an instance for receiving notification messages, this input is inserted into the entry information by the client web interface. The client web maintains a list of distinct web service address associated with every user, assigned in Step 0 when a login in created.

Examples of property constraints.

Publishers/Datasource property constraint (Publishers/datasources could define constraints on consumers and subscribers)

   A publisher looking for consumers in a specific city. 
       for $con in fn:collection("$$infodconsumer") 
          where $con//LocationCity="xxx"

   A publisher looking for subscribers belonging to a particular organization. 
       for $sub in fn:collection("$$infodsubscribers") 
          where $sub//OrganizationName="xxx"

When a publisher defines the property constraint, it would be matched with only consumers satisfying the constraint. Also, by defining a constraint against a subscriber, only subscriptions created by that subscriber would be applicable to the publisher.

Similarly, a consumer can define constraint against publishers and subscribers.

   A consumer looking for a particular publisher who belongs to particular organizational sub unit and is located in a specific county.
       for $pub in fn:collection("$$infodpublishers") 
          where $pub//OrganizationSubUnit="xxx"
                and $pub//LocationCounty="xxx"    

Also, the subscriber can define property constraints selecting specific publishers and consumers.

Step 3 - Create Property Vocabulary Instances

Having created publishers, subscribers, consumers, and data sources, we need to associate every entry with a property vocabulary instance. The property vocabulary instance describes or characterizes an entity. To create a property vocabulary instance, the user references the entry's and the property vocabulary it would be associated with. With this information, on clicking create we should be able to see a form to describe the entity information in the semantics of the vocabulary.

Step 4 - Create Subscriptions

Subscriptions reference a subscriber, therefore to create a subscription you need to have created a subscriber. The subscriber takes in three constraints: property constraint, data constraint and dynamic consumer constraint. The property constraint is similar to ones defined while creating an entry. A subscription property constraint can define constraints binding publishers, consumers and even subscribers. If the property constraint of a subscription is NULL then, all publisher's and consumer's in the registry would be matched unless limited by their individual property constraints.

The data constraints, define the event of interest at the publisher and the message to be delivered by publisher to the consumer. The data constraint is described in the semantics of the data vocabulary. The dynamic consumer constrained is used identify a set of consumers from the static set of consumers identified by the INFOD registry. The property constraint is the only constraint evaluated by the INFOD registry, the data constraint and the dynamic consumer constraint are evaluated by the publisher.

An example subscription.

  PropertyConstraint
   for $con in fn:collection("$$infodconsumer") 
         where $con//OrganizationSubUnit="PolicePatrolCar"
   for $pub in fn:collection("$$infodpublisher") 
         where $pub//OrganizationUnit="E911"
  Data Constraint
    declare namespace $data = www.ggf.org/INFOD/datavocabulary/627F6E295515080AE0405BA0952C0D32
    let $msg1 :=  for $firstresponders in fn:collection("$$infodconsumer") 
	                where $data:AlertStatus = ‘Actual’  and $data:EventCategory = ‘CBRNE’ and $data:EventSeverity > ‘Moderate’
                       return {$data,  $data:Instruction = ’Evacuate people in the region’ }
    let $msg2 :=  for $firstresponders in fn:collection("$$infodconsumer") 
	                where $data:capAlertStatus = ‘Actual’ and $data:EventCategory = ‘Fire’ and $data:EventSeverity > ‘Moderate’
                       return { $data:Substance, $data:Volume, $data:EventCategory }
  Dynamic Consumer Constraint
    for $firstresponders in fn:collection("$$infodconsumer") 
              where $firstresponders//OrganizationSubUnitName=”HAZMAT”
 	return msg1
   for $firstresponders
        where firstresponders//OrganizationSubUnitName=”FireService”
              and shortestdistance($firstresponders)
 	return msg2

Notification Messages

Having created the resources in the registry, the user should receive notification messages from the registry. The publisher would receive notification messages on the subscription and the consumers mapped to it, along with the data constraint and the dynamic consumer constraint defined by the subscription. The consumer would be notified of the list of publishers with the URI of the subscription binding them. The subscriber receives a notification message on the list of publishers and consumers bound by the subscription. User would receive notification messages only if they have opted 'TRUE' for notification while creating the entry.

Step 5 - Replace/Drop Subscriptions

The following steps 5, 6 and 7 are for understanding the INFOD system response with respect to the change in metadata information in the repository. The user can replace a subscription's property constraint and can observe the changes to the association between publishers and consumers, and the notification message received.

To replace a resource, the user needs to reference it by the URI generated by the registry when the resource was created.

To drop a resource, the user needs to reference the resource URI and select an execution mode for dropping the entity.

   The three execution modes
       "IF UNUSED" - meaning the resource if not being referenced by any entity then the resource can be dropped, else not.
       "DISABLE NEW" - maintain existing references, but does not all new references and deletes when the resource is not referenced.
       "CASCADE" - the resource is deleted and all the resources/associations mapped to this resource is also deleted.

Step 6 - Replace/Drop Entries

Similar to the above step, the user can create new entry's, replace the property constraints in an entity's entry or drop an entry and observe the changes in INFOD mapping through the new notification messages. The replace and drop operation policy is the same as mentioned in the above step.

Step 7 - Add/Drop Vocabulary Instances

The current implementation does not allow replacing replacing property vocabulary instance, this feature would be added on in the next version. To change the properties of an entity, we need to drop and create a new property vocabulary instance. However, an entry can be associated to multiple property vocabulary instances.


Back to InfoD Main Page