Resource lifecycle is an important core concept in the OOINet architecture, expanding on the concept that all system resources are represented and described in a uniform way (see Resource Registry). Resource lifecycle provides a generic expression of maturity and availability to the user and clean transitions between. Resource lifecycle adds substantial value to systems that model complex collaboration processes between users of many roles. Resource lifecycle state change is protected by system policy and requires defined integrity conditions to be true (e.g. an instrument must have a model associated before it can be declared developed). Resource lifecycle state changes can be traced through events and can be audited. They provide a core mechanism of policy enforcement in the system and for resource traceability.
The figure below shows the lifecycle states that OOINet resources registered in the Resource Registry can be in. It also shows the transitions between the lifecycle states. Note that the concept of resource lifecycle is applied differently for different resource types. Only a small subset of OOINet resources, mostly these with user ownership and sharing, are enabled with full lifecycle control. Resource lifecycle decomposes into 2 dimensions: maturity and availability.
- Maturity indicates how far a resource is along the process of being fully integrated and accessible by other users
- Availability indicates the degree of exposure to resource consumers
Maturity state follows the lifecycle workflow depicted below. Some states may be optional or unused for certain resource types to simplify dealing with the resource. The initial state for resources may vary if a simplified resource workflow is applied for certain resource types. Transitions between states typically occur towards a more mature state (right-down direction), but backward arrows indicate where state digressions are possible, for instance when a deployed device is taken back for disassembly and refurbishment.
Figure 1. Resource Maturity Lifecycle (OV-6)
Availability states follow the availability workflow depicted below. Some states may be unused for certain resource types to simplify dealing with the resource. The initial state for resources may vary if a simplified resource workflow is applied for certain resource types:
Figure 2. Resource Availability Lifecycle (OV-6)
Both maturity and availability together form a resource's lifecycle state. Transitioning the lifecycle is only permissible for one of maturity and availability workflows at the same time. Composite state may occur in places in the implementation denoted as MATURITY_VISIBILITY, e.g. DEPLOYED_AVAILABLE. The meaning is to parse this into the 2 component states. The RETIRED state only ever occurs as RETIRED_PRIVATE.
Lifecycle states exist to abstract common workflows that resource roles, such as provider, consumer, operator and infrastructure perform interactively to work with resources. The lifecycle states represent the abstracted distinct states a resource is currently in. Resource lifecycle, system policy and resource governance are closely interrelated.
Changing the lifecycle state of one resource is requested by one of the above participant roles, to be performed by the system. Changing the resource lifecycle state is an instantaneous action. In order for this change to perform, certain preconditions need to be fulfilled:
- The actor's role needs to have sufficient authorization. Otherwise the change request will be denied as "Unauthorized". Typically the further along the maturity states you go, the higher the permission level of the acting role (e.g. only an Observatory Operator can set an instrument device to DEPLOYED)
- A number of resource preconditions need to be fulfilled, depending on the targeted lifecycle state. These preconditions are highly resource type specific. For instance the model of an instrument must be associated before the maturity state can change to PLANNED. A test report may need to exist attached to the resource before the lifecycle state can advance to DEVELOPED.
- Certain invariants that come with a lifecycle must remain true after the lifecycle state change. For instance, a resource that has been made AVAILABLE and subsequently been acquired
The tables below define the common maturity and availability lifecycle states. Synonyms and explanations for states are given to illustrate their use. Because lifecycle states are common across resource types, the User Interface may choose to represent them under different names to end users.
|DRAFT||The object describing a resource has been newly created by the provider and may still be incomplete or inconsistent, with respect to system criteria. Provider works on achieving completeness and consistency.||This is the initial state for resource types with full lifecycle.|
|PLANNED||The resource is described by this object consistently. The resource itself is not present but is planned to be in the future.|
|DEVELOPED||PRESENT||The resource described by this object is present, the provider's resource test suite has passed and the provider has asserted this state.|| This state may be renamed to TBD.
|INTEGRATED||READY||The provider's and the system's integration test suites have passed in a system or assembly environment and an authorized integrator has asserted this state.||This state may be renamed to READY.|
|DEPLOYED||ACTIVE||The resource described by this object is operational in its target environment. The system operator has asserted this state.||This is the anticipated target maturity state for normal operations. This is the initial state for resource types with simplified lifecycle. This state may be renamed to ACTIVE.|
|RETIRED||The resource is deactivated, not available as an active resource, and present only for historic reference.|
|DELETED||The resource is hidden from the operational system and ready for purge by a system operator. It can be recovered in exceptional cases.||In this state the resource is "gone" from the operational system and not visible in any queries.|
|PRIVATE||Only the resource's owner and system/facility superusers can use it.||This is the initial state for resource types with full lifecycle|
|DISCOVERABLE||The resource can be discovered by prospective consumers but cannot be acquired and used at this time.|
|AVAILABLE||The resource can be discovered by prospective consumers and can be used after successful acquisition.||This is the initial state for resource types with simplified lifecycle|
Every resource has also a visibility attribute that determines who can find a resource. There is no state model behind visibility.
See CIAD COI OV Resource Registry for details.
|Resource Type||State Model||Comments|
|FULL, see Figure 1|
|FULL, see Figure 1|
|ExternalDatasetAgent||FULL, see Figure 1|
|Deployment||Initial state is (PLANNED, AVAILABLE). DRAFT, DEVELOPED are unused||Non physical and therefore simplified|
|DataProduct||Initial state is (PLANNED, AVAILABLE). DRAFT, DEVELOPED, INTEGRATED are unused||Non physical and therefore simplified|
|All Other|| CORE. Initial state is (DEPLOYED, AVAILABLE). DRAFT, PLANNED, DEVELOPED, INTEGRATED are unused. The only available transition is "retire"
||A more comprehensive lifecycle state model may be applied as needed after initial R2 release.|
For physical devices, such as instruments and platforms, a typical flow of resource lifecycle states is depicted below:
Figure 3. Typical device resource lifecycle flow
See CIAD SA OV Observatory Management for an example of resource lifecycle (maturity) state to observatory resources and the coordination of lifecycle state across related (associated) resources.
|The resource lifecycle activities listed below have not been implemented in Release 2 in a generic way but have informed the state model described above. They will be implemented with Release 3. Release 2 is true to their intent, however, only for a subset of resource types.|
The activities listed below influence resource lifecycle state.
- Lifecycle States
- Lifecycle State Details
- ION R2 Resource States by Resource Type
- Lifecycle Activities
- Detailed Activities Description
- The Develop Activity
- The Register Activity
- The Document Activity
- The Commission Activity
- The Activate Activity
- The Announce Activity
- The Discover Activity
- The Acquire Activity
- The Associate Activity
- The Govern Activity
- The Manage Activity
- The Use Activity
- The Release Activity
- The Deactivate Activity
- The Decommission Activity
- Implications of Policy/Governance Framework over Resource Lifecycle
The following activity diagrams show the activities involving the logical entities for Policy and Governance followed by a description of the activities included as transitions in Figure 1a and 1b. In each activity diagram, the names on the left are the Actors abstracted into roles.
The sequence of actions within the diagrams follows the arrows, and is largely from left to right. Each diagram begins at the initial node, represented by a large dot, and finishes at a final node, an encircled large dot. Rectangles represent the actions needed to perform each activity, while diamonds represent decisions. A diamond may be preceded by an action node to indicate the action needed to perform the reasoning for the decision. The actions to perform each activity (boxes) are usually presented within a row, or 'swim lane'. The swim lanes represent actor responsibilities: when an action (box) is within a swim lane, the actor named on the left side of that swim lane has some responsibility for the action.
To enable sound composition of the activities, we distinguish between two main modes of termination of an activity. A final node shown with a solid (and green) circle indicates successful termination, whereas a final node shown with a dashed (and red) circles indicates failure. When activities are composed, the normal flow of control results in the successful termination of the composed activities. Following common programming language practice, we conceptually treat failures as exceptions. An activity can include decision nodes that "throw" an exception; an activity may handle or "catch" an exception thrown by one of its component activities, and by default, an activity forwards any exception thrown by its component activities up to the activities of which it itself is a component.
The responsibilities in these diagrams are not rigorously allocated. Any action that changes a resource is expected to Document the change. However, Document is treated as cross-cutting in the sense of Aspect-Oriented Programming. Thus, Document is not shown explicitly, but a suitable implementation of Document can be assumed to apply concurrently to any desired activity.
As mentioned above, the activity diagrams collected here are meant to inform the design of the OOI CI; in particular, the CI sub-projects are expected to take these diagrams as the starting point for the designs devised to implement the corresponding activities. This will lead to further refinement and additions to this document throughout the duration of the OOI CI development project, and possibly beyond.
All activities from Figure 2 are analyzed from the perspective of the COI use case "is the actor allowed to do the activity the actor attempts" or "must the actor perform some activity" or "may the actor perform some activity." To be allowed in this context means to be authenticated and to be authorized to do a particular activity. This use case is a generic one applying to all activities. Further analyses of the activities can bring additional COI use cases specific to a particular activity. For example, to be allowed to do an activity in a chain of activities, the previous activities have to be accomplished.
Any resource requires some action to come into existence. Broadly considered, the action can be called development. The figure below shows the Develop activity. The initiator of the activity is considered the Visionary, who conceives of the resource and takes responsibility for bringing it into existence. (These roles, of conception and instantiation, could be separated of course.) The Engineer represents any collaborator who helps create the resource; often this is a specialist who understands the tools necessary to build the resource, but it could also include operators, potential users, and other team members.
Together the Visionary and Engineer create the requirements for the resource, incorporating interface and policy requirements from the Operator of the resource. In our case, the resource Operator role is typically delegated by the OOI project to some organization or entity. Possibly influenced by an Administrator (who oversees budgets, responsibilities, and so on), the Visionary and Engineer decide how to proceed on the project. Funding may come from either the Operator (possibly a different OOI representative), an Administrative presence, or be obtained in some other way.
Given funding, the developers (Providers) design, implement, and test their resource. For some resources, the test action may be skipped. In a well-organized system, the Operator will have a test harness available, against which all resources can be tested to verify appropriate interactions with the system. Using such a test harness and their own testing processes, the developers determine whether the resource is ready for deployment. If it is not, they must return to the Design/Implement step, but if it is ready, they have completed this activity.
Figure 2: Develop Activity (OV-5)
Note that the Develop activity does not include the steps to make the resource an active part of the OOI system (Commission and Activate); these steps require more active involvement with the Operator to confirm the performance of the system. The step to Register a new resource is shown separately and is usually performed in conjunction with Develop. Specific examples of the Develop activity include developing an instrument, developing a laboratory (a virtual space where collaborators can share information and run applications), or developing a software application like a model or catalog.
The flavor of testing may be different in each of these cases, but all have interactions with the OOI system (defined by the Operator) and all are similar in their progression through the activity. The Provider (Visionary, Engineer) specifies OOI Interface and Policy Requirements to Operator. The Operator presents Interface and Policy Requirements.
A resource may be registered (Figure 3) any time after it has been developed. The entity that registers the resource is typically the resource provider, but it is possible for that activity to be delegated; we call the actor that registers the resource the Registrant.
Figure 3. Register Activity (OV-5)
The first step of the registration process is for the Registrant to characterize the resource. The characterization is submitted as a part of the registration. To be accepted, the characterization must include the information required by OOI's registration interface. When the registration information is submitted to the Registrar, that component must certify that the information meets the minimum criteria. If the criteria are not met, an error is returned.
Given satisfactory information, the infrastructure will save the registration in the catalog (a specific case of an Association Catalog) and perform the necessary actions to make it routinely accessible by Catalog users. If certain conditions apply, the registration may also be replicated to one or more external catalogs that will undertake their own Register action.
Under any circumstances, the registration information will be distributed as a published output of the catalog, so that interested parties may be automatically notified of the addition to the catalog. A common resource to be registered will be data, whether they are presented as constantly updated streams or individual data products. The Publish mechanism will allow users to see new data of interest to them.
Other important registered resources are data sources, including instruments and software processes. Once a data source (or any other OOI resource) is registered, its description can be made available to anything that relates to it, making a rich web of associations accessible in appropriate contexts. In fact, the rich web of associations can be applied to any kind of OOI resource, including people, organizations, system processes, virtual collaboration environments, and research information.
The process of registering goes as follows:
- Registrar certifies the submitted Resource registration or raises an error
- Registrar requests that the Resource registration be saved in the Registration catalog
- Registrar checks policy to decide whether the resource needs to be advertised to an external catalog
- Registrar Catalog Publishes the Resource Registration
Documenting a piece of information is very much like registering information; many of the same actions must take place. This activity is used throughout the system to keep track of the various events that take place. The comprehensive list of events can then be used as yet another resource in the system, and associated with other events or data that have been collected:
- Infrastructure certifies the received documentation request or raises a certification error
- Infrastructure saves the information to catalog
- Infrastructure publishes the information
When an information source submits something for documentation, the infrastructure must perform the basic tests done for any input, making sure that the provided information follows the defined interface. If this proves to not be possible, an error is logged. Once valid information has been accepted, the information is represented in the catalog of associations maintained by the infrastructure, and presented to interested parties.
The use of Document within this activity is effectively a recursive reference to the most basic version of the activity. When the Associations Catalog documents a piece of information, it simply stores it in its database in the appropriate form. Document is the simplest type of association made by the system, and generally refers to capturing a fact or piece of information. In many cases it is equivalent to logging of errors, status, and other information performed by any other software system. On OOI, Document also provides a means to store routine transactions of the OOI system, like deployments, status messages, and reports.
Figure 4: Document Activity (OV-5)
Commissioning includes the steps necessary to confirm that a resource is ready to use for the first time in the OOI system. It does not include the final steps involved in using a resource, which may have to be repeated each time the resource is used. Commission is expected to be performed only once for a resource during its lifecycle, unless the resource has been marked unfit for use (decommissioned) and then refurbished or otherwise made fit again. The Commission activity, therefore, provides final confirmation of fitness from the standpoint of the observing systems.
The commission activity starts of with a check on the registration status of the resource. If the resource has not been registered then it is carried out here. Once registered, an OOI Test Facility may inspect the resource and/or connect it (and any corresponding physical entity) to a test OOI network, to confirm that the resource complies with all of the interface requirements. Some of these requirements may be physical, while many others will be centered on the cyber-infrastructure. The latter includes interface protocols (networking and application), responsiveness to standard OOI interactions and consistency of the resource outputs with the metadata description provided during the Register activity. For many Ethernet-centric resources, the connection may be made at the Provider's site directly to an Ethernet network. For other physical entities, an appropriate OOI test harness may be shipped to the Provider's location. Like most OOI facilities, OOI Test Facilities can be located throughout the country, as well as on mobile platforms.
Once certified as OOI-compliant, the resource (and any corresponding physical entity) may need to be deployed. Most physical entities on the OOI system will incorporate their cyber-representation, either within the physical chassis, or in an attached adapter. An associated resource deployment may also need to be coordinated. As part of deployment, the Deployment Engineer will verify that the deployed system is interfacing with the OOI system as designed, and then notify the resource provider that the system is ready for validation. After the provider Validates that the system is working as intended, OOI can assert that the resource has been commissioned.
Three examples - software, an instrument or AUV, and a virtual laboratory -demonstrate the Commission activity. First, given a software application that will publish data through OOI's cyber infrastructure, an automated test harness could receive data from the software, validate it against the registered metadata, and issue a certificate of compliance. The software can be deployed using a web-based tool, and again automated systems detect that it is interfacing correctly to OOI. Finally, the software developer checks a box indicating correct operation to complete the commissioning process.
An instrument or AUV may require testing with a particular physical harness, and possibly a visual inspection before deployment, but its virtual presence might be tested against OOI requirements in much the same way (possibly with more sophisticated tests for the AUV). On the other hand, the instrument or AUV's physical deployment must be conducted at sea by a Deployment Engineer, and possibly coordinated with operational staff in a control room.
Finally, a virtual laboratory is created using OOI tools and processes - with interfacing possibilities beyond the boundaries of the OOI. The registration, certification, deployment, and verification steps will be supported by the CI implementation; the Validate step lets the originator of the laboratory confirm that it appears to be working normally. The assertion that the laboratory has been commissioned is then but a single logic statement. In each of these cases, the resource has been warranted for use, but has not been enabled on the OOI system. This occurs during the Activate activity.
Figure 5: Commission Activity (OV-5)
Activate (Figure 6) enables the resource for use within OOI. It is a routine operation associated with the resource becoming available for use, and then possibly unavailable at other times. Activation of a resource might be requested by any OOI actor; some resources can become active upon request, while others require manual intervention (e.g., for physical deployment), and others can only become active under certain conditions. Hence activation request is first checked for proper authorization and such policies.
During enabling the resource is checked out and made ready to operate. Other entities are now in a position to use the resource, assuming they have the necessary authorizations:
- Operator receives a request to activate which is checked for proper authorization policy
- Operator enables the resource
Figure 6: Activate Activity (OV-5)
Returning to our earlier examples, software applications may use activate in different models. Some software will be active and available at all times (either because it is running all the time, or because it is started instantly when needed), while other software may only be active when it is actually executing, or when an appropriate condition is met. For example, instant messaging, chat, or telephony software may be running, but not make the node available for interaction until the status is set to "Available."
Similarly, instruments may be turned off and on, in which case Activate/Deactivate could be useful activities, or they may be turned on and left on for their entire operational life, which implies activation only once. Most AUVs are activated for each mission/deployment and deactivated when the mission ends. A mixed mode of deployment may occur, with an instrument deployed multiple times, and turned on and off during each deployment; the proper application of Activate will have to be determined appropriately for the given scenario.
Finally, a virtual laboratory is essentially activated as soon as the principal user (the "Provider" in these diagrams) acknowledges the functionality of the laboratory. Given user expectations for response times and usability, computational entities can and should be configured to become active as quickly as possible once the necessary conditions are met. Whether the resource is active or not, most people will not know of its existence until the knowledge of its availability is promoted. This occurs as a result of the Announce activity (which does not depend on the results of Activate).
The process of announcing that a resource is available for operations is similar to the process of registering the resource in the first place (see Figure 7). The principal difference is that the resource has already been defined, and so the announcement amounts to a message with the properly formatted resource identification, together with the indication that this resource is now operationally available.
Figure 7: Announce Activity (OV-5)
While the process is similar to Register, and is not very complex (and so is not reviewed here), the outcome is typically very different:
- Infrastructure certifies the submitted Announcement or raises an error
- Infrastructure saves the Announcement in Association catalog
- Infrastructure decides to advertise the Resource Registration in External Catalog
- Infrastructure Publishes the Announcement
For almost all OOI resources, the compelling stage of the resource's lifecycle is when the resource is available for use. Until then, the resource is not routinely discoverable or usable. Once the resource is announced, it becomes visible to all the potential users, including other processes, and forms part of the resource fabric of OOI. Since resources include data sources, services, and all of the data streams and data products of OOI, the announcement of availability is a critical milestone for the resource within the OOI.
As with registration, the announcement process may include a provision to advertise the announcement, meaning to notify external entities of the announcement. Whether or not this occurs, the announcement is published to OOI subscribers, making it widely known to interested parties in the OOI community. Announce, and the companion activity Discover, are particularly interesting to consider for the range of resources.
The resources most typically announced in existing systems are Informational-Data-Representations, in particular observations, measurements, and models. Reports and Documentation are also potentially of interest to all OOI users. For example, scientific papers relating to a particular data set would be of great interest to the provider of that data set. Definitions (software, schema, profiles, and so on) are less broadly announced in practice today (with the exception of technical definitions, such as Web service interface specifications using the Web Service Definition Language - WSDL), but are important to a certain class of users.
The associations established by the Announce activity include not just routinely collected metadata about data sets, but also user commentary and automated evaluations. Users of data sets will find it quite valuable to monitor announcements of associations about data sets of interest to see if anyone else has commented upon or cited them. Here again, the structural associations information (such as how the associations are stored or transported over a connection) may be only of interest to a more technical subset of users.
Functional resources have two major categories that are very compelling in this context: Environmental resources and certain Structural resources. The value in monitoring announcements of new platforms, nodes, or instruments is obvious, especially to the degree the announcements include key properties such as the variables measured by the entity. Also interesting will be the ability to monitor an environmental resource such as an acoustic range, so as to reserve it for monitoring or for experimentation (e.g., emitting an acoustic signal in this range within a given time window). By representing these physical entities as OOI resources, the CI can perform many functions-planning and scheduling, observing, logging, and so on - that relate the physical entity to other OOI data sets and data relationships.
Although the resources listed in the Appendix are not comprehensive, there is an obvious range of applications for Announcing their availability for use, and in other ways making them a working part of the OOI CyberInfrastructure that can be accessed by all of the users of the system. Of course, to make use of the available resources, OOI users will require robust discovery mechanisms.
Discovery has two modes, intentional and accidental the former is aided by effective structural aids to searching and browsing; the latter is aided by organization of information resources that make discoveries of interest likely (for example, by creating "you may also be interested in" links in the viewed environment, as online stores frequently do).
Discovery can be directed by a human searcher, by a computational searcher, acting on behalf of a human searcher, or by an event-driven sequence of processing that provides information to a user who has registered an interest. The last scenario, which can be called Discovery by Subscription, is not outlined explicitly in this diagram. The capability derives from the services described elsewhere in the Conceptual Architecture. The Discovery by Subscription scenario can be viewed as either an intentional search, set up by the user in advance, but with a long timeline for the action "Format Query, Receive Results, Present Results"; or as a serendipitous event, in which information of interest just appears to the user (e.g., in email).
The complexity of the Discover activity derives from its attempt to capture complex approaches to the problem of finding something. In general, there are two parts to finding something: choosing whether to navigate (typically via the web) or search (entering strings into a search engine of some sort), and choosing the tool or tools that will yield the best result. As an example, search engines usually combine both approaches, first allowing a crude search specification, then allowing the user to navigate from many choices.
A portal or tool may, in its user interface, present multiple options for discovery. These may leverage interfaces provided by OOI or other catalogs, each of which may have its own interface, and some of which may present that interface automatically as a computer-friendly description of the available services. The selected User Interface must present the necessary capabilities to the Searcher, and then execute the chosen function and return the results.
Whether the approach is browsing (navigating web sites) or searching with a query, the Searcher will evaluate the results, and may iterate on the process in a number of different ways until acceptable results are returned.
Just as the preceding section described implications given a wide variety of resource types (see Appendix), discovery leverages the same variety while providing common approaches. All of the different resource types used in OOI can be maintained in a single repository and found using a single catalog, thereby leveraging the investment in those components. Different user interfaces can be built that present only resources of particular types, allowing the same level of customization which is possible with a more restricted catalog.
The process from the point of view of the COI is the following:
- Registrar certifies the received Discovery request or rises and certification error
- Registrar requests Discovery by Associations catalog
- In case of error, the Registrar requests publishing of the risen certification error by System Error Logger
- System Error Logger requests documentation of the risen certification error by Associations catalog
- Associations Catalog documents the result of submitted Discovery or risen certification error
- Associations Catalog publishes the result of submitted Discovery
Having found a resource that is interesting, an OOI member may want to use it. The OOI infrastructure must mediate all uses of resources, making sure that any conflicts are resolved and only authorized actors are allowed to perform a given function on a given resource.
The first step in utilizing a resource is acquiring permission to use it. To do so, there are three key criteria that must be met: the Requester must be authorized to use the resource, the usage must not create a conflict for that resource and any terms of usage must be met. The cyberinfrastructure must act as an honest broker, negotiating an agreement between a resource provider (which may be the OOI itself, or an individual with an asset) and the resource requester. The acquisition is successfully completed when the requester has obtained access to the resource, and performed the associated action(s) called for in the acquisition agreement.
The meaning of Acquire will differ significantly for different resource types. In the case of data streams and data sets, acquiring the data means getting permission to use them. Sometimes the data may already be accessible, and the Acquire activity is a formality that connects the requester to the data provider. If the resource is an instrument, Acquire means that the requester wants to use the instrument, which implies making changes to it to achieve an end. If the requester only wants to use data from the instrument, subscribing to its data stream is sufficient (Figure 8).
Figure 8 Acquire Activity (OV-5)
Obviously, many resources (one example being instruments) can only be acquired by one requester at a time, and so mediating requests will be an important part of OOI's management responsibilities. Diverse resources have the same characteristic: only one benthic rover can occupy a particular small patch of seafloor, and only one software instance can own the right to produce a particular data stream at a given time.
The Acquire activity includes the Negotiate and Fulfill Agreement activities (Figure 9 and Figure 10). The Negotiate activity can be described abstractly as an exchange of offers and counter-offers between participants. A participant may initiate an offer. It may reject an incoming offer, in which case the negotiation fails. It may accept an incoming offer, in which case the negotiation succeeds. Or, it may counter, in which case the negotiation goes on.
Figure 9. Negotiate Activity (OV-5)
Figure 10. Fulfill Activity (OV-5)
In abstract terms, there are two ways to fulfill an agreement. Each party may carry out the terms of the (presumably negotiated) agreement. If each party accepts the performance of the other, the agreement is considered fulfilled (successfully). If either party rejects the other's performance, the fulfill activity fails.
Another way in which fulfill may proceed involves the use of a trusted third party as an escrow agency (Figure 11). There are many ways to conceptualize escrow interactions. We describe one that is perfectly symmetric. Each party submits its results to the escrow agency. The escrow agency in turn forwards each result to the other party for evaluation. If both parties accept the results, the escrow agency declares success and completes the business transaction. If one or more of the parties reject the results provided by the other, the escrow agency declares failure and rolls back or unwinds the business transaction.
Figure 11. Escrow Activity (OV-5)
Other resources can be shared or allocated to many requesters. Any number of participants may belong to a laboratory once permission is received from the laboratory 'provider.' Bandwidth for transmitting commands to a deployed system may be shared among multiple users, although the total bandwidth used must not exceed the amount available. Defining the policies and procedures for resource acquisition will be an important part of the creation of the cyberinfrastructure.
The Associate activity is very similar in appearance to Register and Announce, but it is in fact a superset of those activities, and is key to operation of the OOI system. This activity performs the operation of relating two resources or characterizing a resource. The significance of this activity is deferred to the end of this Activity description; for now we describe the process of making an association.
Assuming the necessary resource(s) and descriptive information are in hand, the entity describing the association (the 'Definer') must formulate the relationship appropriately for the infrastructure. The Definer submits this formulation, which is accepted in the same way a registration or other announcement is made. If the service that receives such submissions deems the association correctly expressed, it is entered into the Associations Catalog (of which the Registrations Catalog is but one view), and the same progression occurs as for a registration or announcement.
The significance of this activity for OOI and its resources is more apparent when one considers the fact that data, and many other resource types, becomes enriched over time by information that relates to it. Over the course of a resource's life, many references are made to it. In fact there are many types of associations that can be made to resources, as seen in the following table that illustrates just a few. The combination of all of the associations in OOI makes up an Association Fabric that consists of all of the relationship assertions defined in OOI. The OOI capabilities will be driven in large part by the infrastructure's ability to organize and derive value from the associations in the Association Fabric.
|process||cites use of||observation|
|user||is a member of||facility|
|service||is governed by||policy|
Figure 12: Associate Activity (OV-5)
The process of Association proceeds as follows:
- Association Service certifies the submitted Association or rises an error
- Association Service requests documentation of the Association in Association catalog
- Association Catalog requires the Resource Association in External Catalog
- Association Catalog Publishes the Association
Figure 38: Observation Lifecycle Associations (OV-5)
The Govern activity diagram in Figure 39 incorporates two linked activities. One of these is from the perspective of the Governor and the other from the perspective of the governed, termed here the Consumer.
The Governor sets policies, and presents them in a form that the Infrastructure can work with. The Consumer seeks to take an action that is constrained by those same policies. The Governor determines whether the Consumer has the rights to take the appropriate action by granting general or specific access rights and allocations to the Consumer.
These actions have set up the necessary conditions for the Infrastructure to actually enforce the policies. This enforcement occurs at each stage of activity involving various actions taken by the infrastructure. Governance continues until the Consumer is no longer taking actions which are governed. In theory, governance applies to all resource types, although in many case a default policy may be the only one that needs to be enforced.
An advantage of applying governance as an ongoing activity, enforced by configurable rules, is that changes to policy should not require changes to the infrastructure. This assumes that the rules are computable, or able to be enabled by the computer. In this sense, the Govern activity is an example of further cross-cutting activities, such as failure management, logging and encryption/decryption:
- Infrastructure enforces the received Policies, rights and Allocations
- Infrastructure audits the Enforcement of received Policies, rights and Allocations
Figure 13: Govern Activity (OV-5)
Just as governance continues throughout the period that a resource is available, management of the resource must also take place. The Manage activity consolidates the various functions associated with resource management (Figure 40).
Figure 14: Manage Activity (OV-5)
Unlike most of the diagrams, this one flows from top to bottom. Actions are placed in the swim lane(s) that have the most responsibility for them, but can occur in any order and combination. The actions are grouped according to their nature, but no flow is implied by this grouping.
A few of the actions in this diagram are fairly hardware-specific, in particular Refurbish and Clean. However, the same capabilities can be applied to most of the different resources, whether they are science observation-oriented or part of the infrastructure itself.
Figure 15 shows the Use activity in which an actor finally utilizes a resource. Using a resource can consist of commanding it, getting information from it, or both.
Since the agreements were already fulfilled in the acquire activity the user proceeds to directly inject commands to the resource he/she intends to use. The provider however checks for permission and other pre requisites. Depending on the agreement made when the user first acquired the resource, the Provider should go ahead and execute commands. Results are returned to user who can process the information and proceed to fulfill (see Fig 10.c for details of fulfill agreement) any incurred charges per agreement. User then checks to see if he/she is done and accordingly resumes the use or proceeds to release.
Resources on which command may be executed include many instruments, data sources, facilities with their components, and many components of the infrastructure itself.
Data are generated by most resources, and will probably be the most commonly used type of resource (aside from metadata associations, which will be extremely numerous). Note that most of the OOI data will be made available as a product set for non-OOI users; this diagram does not address that resource use.
Many of the OOI service resources will simply provide observation data and other information, and most will be accessible to any OOI member. These will typically be shared resources that can be used by as many members as desired.
Figure 15: Use Activity (OV-5)
When a resource is no longer being used, the User is expected to release it. Optionally the provider may decide to take away the resource for some reason. The Release operation (Figure 16) serves several purposes: it makes consumable resources available to other requesters, it updates the list of users of the resource so that the system can determine who is currently using the resource (as when the system needs to Deactivate the resource) and it provides a record of the operational steps of the resource lifecycle.
Once the requester and provider have reached a fulfilled agreement any of them may proceed to remove the resource.. This role is comparable to that of the Title Company in a major property transaction.
Once the Negotiator confirms the Release transaction is successfully completed, the Infrastructure updates the list of users of the resource. In this way, a resource provider can learn who is currently making use of the provided resource, and the Provider or Infrastructure can notify all users of possible changes to the resource's status.
Timely execution of the Release activity is particular critical for resources with limited access, such as high-value controllable instruments in an observatory. Monitoring agents may be written to detect when high-value resources do not appear to be used even though the User has not released them. Upon detection of such a case, the monitoring agent could notify an operator, send a message to the User and Provider, or take unilateral action, depending on circumstances and configuration.
Figure 16: Release Activity (OV-5)
Deactivation makes a resource unavailable for use, although the resource may still be physically capable of performing a task. A deactivation may be requested by almost any entity (Figure 17).
Before deactivation takes place, it is the responsibility of the Operator of the system to determine whether deactivation is appropriate. In particular, this entails ensuring that resource users are minimally affected. This may just mean timely notification of the deactivation, or potentially postponement until user needs can be addressed. The Operator should also weigh the costs of deactivation (and likely future activation) when considering whether the deactivation should take place.
Once deactivation is the decided course of action, users are notified and use of the resource is disabled. If the resource corresponds to a physical entity, that entity can now be removed from the system (such as when an instrument is removed from a mooring) or from the operating environment (such as when a vehicle is brought back on to a ship).
Figure 17: Deactivate Activity (OV-5)
The Decommission activity (Figure 18) is the most complete removal of a resource from the system. This activity is performed when a resource is determined to be unusable in its current state, requiring significant modification or maintenance before it can (or should) be used again.
As a general rule, Decommissioning means the resource is unavailable for use, and is also not discoverable as a potentially usable resource. It is the closest activity to "Unregister"; while the registration information is still maintained, it is only made available via specialized searches.
The most common use of Decommission is to indicate that an instrument is no longer available for use on the system, as for example when it has been destroyed or damaged. However, it can also be useful to indicate a data set that has been found to be invalid, a facility that has been decertified for OOI operations, or a security certificate that may no longer be used.
Figure 18: Decommission Activity (OV-5)
The following table summarizes the effect of the policy/governance services on the resource lifecycle activities from the Behavior section. The Manage, Govern, Develop activities are not included because the policies involved have an abstract structure.
Terms used in this table and their meaning:
- self - the entity that owns the policy;
- other - additional entity (if exists) on which the policy may apply or which may interact with the policy owner
- cause - message from other or observation by self
- effect - authorize other; enable self; oblige self;
- capability - intended outcome.
| Register resource
Researcher wants to register a new data stream to make it available
|Registrar||Registrant||Reactive: Registrant makes a request||Authorize Other|| Write (Use) to Registration catalog (Resource )
| Advertise registration
Registrar decides whether the resource it has certified needs to be advertised as well
|Registrar||Registrant||Proactive||Oblige Self||Write (Use) to External Catalog(Resource)|
| Deployment Registration
A deployment engineer deploys an instrument so a request is sent to the registrar to certify and document this deployment
|Registrar||Information Provider||Reactive: Information Provider makes a request||Authorize Other||Write (Use) to Association catalog (Resource)|
| Certify resource
A researcher requests the operator to certify a virtual laboratory
|Operator||Provider||Reactive: Provider makes a request||Authorize Other, Oblige Self to Deploy and Verify?||Verify virtual lab|
| Validate deployment
A deployment engineer working for a test facility completes verification of deployment of a sensor that had been requested for commissioning
|Provider||Operator (Deployment Engineer)||Reactive: Provider observes that deployment engineer completes verification of a deployment||Enable Self||Validate virtual lab|
| Request Activation
A researcher requests the operator for software to be activated
|Operator||User||Reactive: User requests activation||Oblige Self||Operate|
Researcher wants to announce a new data stream that he has made available
|Registrar||Announcer||Reactive: A researchermakes a request to announce||Authorize Other||Write (Use) to Registration catalog|
| Advertise announcement externally
Registrar decides whether the announcement it has certified needs be advertised as well
|Registrar||Announcer||Proactive||Oblige Self||Write (Use) to Repository (External Catalog)|
| Submit query
A searcher submits a query to discover a resource
|Registrar||Searcher||Reactive: Searcher makes a request||Authorize Other||Use (Read) Repository (Some catalogs)|
Requester (Provider) negotiates terms of acquiring a data stream (resource) with Provider (requester).
|Negotiator||Negotiator||Reactive: Negotiator makes a request||Enable Self||Accept Reject Counter propose|
| Fulfill terms of acquisition
Researcher requests resource according to agreement
|Requester||Proactive: Researcher decides to request resource||Oblige Self||Fulfill acquisition agreement (Compensate Provider if resource is received)|
| Exercise access per acquisition terms
Researcher requests resource according to agreement
|Provider||Requester||Reactive: Researcher requests resource||Authorize Other||Access resource|
| Associate entity
Researcher wants to associate a new user with a laboratory that he has made available
|Registrar||Registrant||Reactive: Researcher makes a request to associate||Authorize Other||Write (Use) to Association catalog (Repository)|
| Advertise association
Registrar decides whether the association it has certified needs to be advertised as well
|Registrar||Registrant||Proactive||Oblige Self||Write (Use) to External Catalog (Resource)|
| Execute Commands
A researcher inject commands to an AUV, e.g., for navigation
|Provider||User||Reactive: User requests command execution||Oblige Self to carry out the command||Use (Command Execution)|
| Release resource
A researcher is finished using an AUV and informs the operator
|Operator||User||Reactive: User releases the resource||Enable Self||Operator decides whether to proceed with the process of Releasing AUV (resource) from user|
| Restrict access
Agreement of acquirement expires
|Operator||Proactive:||Enable Self||Operator decides to take back the resource by Releasing it from the user|
| Coordinate deactivation
Operator receives an answer from all stakeholders (users, providers, infrastructure) indicating the cost associated with deactivating a data stream (resource)
|Operator||User||Reactive: users notify the operator of their assessments||Enable Self||Operator decides whether to proceed with the process of deactivating resource|
| Coordinate decommission
Operator receives an answer from all stakeholders (users, providers, infrastructure) indicating the cost associated with decommissioning a data stream (resource)
|Operator||User||Reactive: users notify the operator of their assessments||Enable Self||Operator decides whether to proceed with the process of decommissioning resource|