7.2.7 Brokered Access class
7.2.7.1 Introduction
The Brokered Access class allows clients to place an order for an identified registered resource, for use when that resource is a data product that is not directly accessible to
clients. This class has an optional association from the Catalogue Service class, in which case this interface is implemented by the Catalogue Service implementation.
Not all resources can be accessed directly. Brokered access provides for accessing resources that are controlled. Controlled resources might include those for which one or
more of the following applies:
a A fee is charged b Have security limitations
c Require additional processing d Are not available electronically
NOTE This class is included partially for backwards compatibility. This class may be deprecated in the future
to instead use a general framework for ordering more than catalogued data sets.
7.2.7.2 “order” operation
The single “order” operation is more completely specified in Table 42. Figure 16 provides a UML model of the “order” operation that shows the complete BrokeredAccess
class with the OrderRequest and OrderResponse classes. The operation request includes the attributes listed and defined in Table 43. The normal operation response includes the
attributes listed and defined in Table 44.
Table 42 — Definition of “order” operation
Definition Allows clients to order a specified product or resource, and negotiate order price and other
factors with ordering service
Receives Identifiers of desired product or resource of this order , user billing information and type of
order
Returns Order modifications, order estimates, order status
Exceptions Missing Parameter Value, Invalid Parameter Value, ResourceNotFound, InvalidUserID
Pre-conditions
User registered with order service, resource identifiers known
Post-conditions Response returned to requesting client
56
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
Figure 16 — “order” operation UML static model Table 43 — UML attributes in “order” operation request
Name Definition
Data type and value Optionality
productID Unique identifier for specific
resource being ordered, taken from catalogue metadata
Character String type, not empty One Mandatory
orderType Type of order request
OrderType CodeList, with allowed values of:
orderEstimate, orderQuoteAndSubmit,
orderMonitor, and orderCancel One Mandatory
orderID Unique identifier for an order
Character String type, not empty One Mandatory
orderInformation Specification of current order as provided by the client
OrderSpecification data type, see Annex C
One Mandatory userInformation Needed
requester identification, for billing and delivery
UserInformation data type, see Annex C
One Mandatory
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
57
Table 44 — UML attributes in “order” operation normal response
Name Definition
Data type and value Optionality
productID Unique identifier for specific
resource being ordered Character String type, not empty
Values from catalogue metadata One Mandatory
orderType Type of order request
OrderType CodeList, with allowed values of:
orderEstimate, orderQuoteAndSubmit,
orderMonitor, and orderCancel
One Mandatory
orderID Unique identifier for this order
Character String type, not empty Value assigned by client
One Mandatory orderStatus
Current status of the order CodeList data type
a
One Mandatory resourceEstimate Estimate
of the resources needed to
process andor deliver the requested resource. Examples of
these resources are time until delivery and cost.
Character String type, not empty Values TBD
One Mandatory
orderInformation Specification of current order, as
provided by client or modified by server during resource estimation
OrderSpecification data type, see Annex C
One Mandatory
a Possible orderStatus values are orderBeingEstimated, orderEstimated, orderBeingQuoted, orderBeingProcessed, orderCompleted,
orderNotValid, and orderCancelled.
7.3 Protocol, interface and operation specializations
The catalogue service specification includes recognized Protocol Bindings, formerly known as Implementation Profiles. Clause 11 defines the rules by which an Application
Profile as a dependent specification can be written. Protocol Bindings shall implement the features present in the General Model, described in Clause 7 following the optionality
expressed there. Protocol Bindings interpret the general model in the referenced implementation environment. These artifacts are discussed in detail in Subclause 7.2 and
the Protocol Binding clauses of this document.
7.4 Dynamic model
7.4.1 Introduction
The Catalogue Interface defines a stateful session a stateless interface will be added in future versions of this Implementation Specification. This subclause defines the states of
the session and the allowed transitions between the states. All other state transitions are disallowed and are consider errors if exhibited by a server.
A physical server may support more than one session. Each of the sessions is independent when viewed from the interface defined by this specification.
In the state models below, a transition is typically triggered by a request. Following the messaging model introduced earlier, a Request is paired with a Response. Generally, a
58
Copyright © 2007 Open Geospatial Consortium, Inc. All Rights Reserved.
Kategori