[
Lists Home |
Date Index |
Thread Index
]
I couldn't discern from your posting below if you were proposing that
such a protocol be created and were therefore soliciting feedback, or if
it is an existing protocol.
In any event, you might like to check out the work being done in the
OASIS WS-CAF (Web Services Composite Application Framework) TC [1], in
which 3 individual specifications are defined:
· Web Services Context (WS-CTX), which defines a basic context data
structure, generic context management service, and context lifecycle
management service [TARGET COMPLETION: APRIL 2004]
· Web Services Coordination Framework (WS-CF), which defines the
behavior of a coordinator with which Web services can register for
context augmentation and results propagation, and on top of which can be
plugged various transaction protocols [TARGET COMPLETION: AUGUST 2004]
· Web Services Transaction Management (WS-TXM), which defines three
protocols that can be plugged into the coordinator to drive various
transaction processing failure recovery scenarios, including a protocol
for use with business process flows that bridge disparate software
systems [TARGET COMPLETION: DECEMBER 2004]
Kind Regards,
Joe Chiusano
Booz | Allen | Hamilton
Strategy and Technology Consultants to the World
[1] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf
Seth Johnson wrote:
>
> Context Transfer Protocol (Uniform Context Transfer Protocol?)
>
> The context transfer protocol (CTP) is an end-to-end data transport
> protocol that supports manipulable distributed hypermedia and data
> processing on the basis of the concept of universal state transfer. It
> employs a set of abstract terms that designate the elements of a
> uniform structure for representing and transferring state, called the
> uniform context framework (UCF).
>
> In place of documents and files, CTP implements contexts, manipulable
> collections of resource elements which are referred to according to the
> UCF abstractions. All of the elements of a context are assigned key
> values which function as links to the servers at which the elements
> originate. Because all elements are links, multiple contexts may freely
> reuse the same elements.
>
> The elements of the UCF reflect a universal information architecture
> which supports all the fundamental operations one needs for managing
> information, including modeling, updating and maintenance,
> manipulation, querying, categorizing, distribution and dependency
> tracking. In this way, CTP implements the notion of an atomic
> application. Fundamental information processing functions for any
> application can be implemented simply by declaring a CTP context, or by
> declaring multiple contexts to be combined in a complex application.
> Any CTP front end interface that surfaces the full complement of CTP
> functionality can be used to browse and work with any information for
> any other application served by a CTP server.
>
> CTP is designed for scalability, providing a simple uniform interface
> through the use of a small set of verbs (GET, PUT, REMOVE and HOST) and
> the finite set of generic elements which make up the UCF. CTP servers
> attain the status of universal application servers in the sense that
> all fundamental information management functions are provided by means
> of this interface and the rest of the functions and architecture
> incorporated within the protocol.
>
> The information architecture underlying CTP affords a maximum degree of
> flexibility in data processing. Entity relationships for all
> applications are stored in a flat fact table form, allowing information
> to be accessed and worked with rapidly, flexibly and with implicit
> interoperability among all applications. In addition, by using the UCF
> abstractions as generic primitives, CTP makes possible a highly
> granular procedural approach to data processing that is unimpeded by
> the intricacies of entity-relationship models or the strictures of
> table- or record-level distribution and/or replication. Higher-level
> techniques for managing complexity, such as set-oriented and object-
> oriented data processing and programming, may be implemented on top of
> the CTP layer.
>
> Instead of working with information through the representation of
> diverse entities in separate physical tables, the CTP physical data
> model is a generalized and denormalized structure that directly
> represents relations as such. Relations implemented under CTP are
> called contexts. CTP uses the following generic abstractions to
> represent the elements of any context:
>
> Space
> Location
> Standpoint
> Use Type
> Use
> Link Type
> Link
> Use Attribute
> Link Attribute
> Use Attribute Value
> Link Attribute Value
> Use Category
> Link Category
> Use Category Value
> Link Category Value
> These elements make up the uniform context framework (UCF), a standard
> structure for representing and transferring state. CTP assigns unique
> key values to each element, made up of a URL (designating the location
> of a CTP server), a forward slash, and a key value unique to that
> server. For example: ctphome.org/18273645.
>
> A general context in CTP is comprised of a use type related to a link
> type. A particular context instance is designated by a particular use
> of the use type, which can have any number of links, particular
> instances of the link type, related to it. This combination of use
> types, link types, uses, and links describes a traditional one-to-many
> relationship, wherein the various uses of a use type serve as “records”
> of the parent entity type (on the “one” side), and the multiple links
> of a link type serve as “records” of the child entity type (on
> the “many” side).
>
> In CTP, state is an aspect of contexts representing their generality,
> and is designated in terms of the concepts of space, location, and
> standpoint. Declaring a state for a CTP context means that the context
> serves as a convention among all clients and servers that participate
> in that state. Space represents the notion of an abstract realm within
> which numerous CTP servers participate and interoperate as they support
> shared contexts. Location represents an individual CTP server.
> Standpoint is an abstraction used to represent states of narrow scope
> hosted at particular locations, for the purpose of independent or
> provisional development work.
>
> Generality of a state is designated by either providing key values for
> space, location and/or standpoint, or leaving their key values empty. A
> state representing generality across an entire space is represented by
> providing a unique key value for the space, while leaving the location
> and standpoint keys empty.
>
> A state for representing universal conventions would be designated by
> leaving all three key values empty. However, since this designates no
> authoritative server for the state, contexts defined within such a
> state cannot be managed by CTP, and would require ratification as
> standards by external standards bodies, followed by general adoption in
> code and practice. With CTP, this process of fostering general adoption
> by means of standards bodies becomes significantly less necessary.
> Instead of presupposing that state and physical data models are so
> arbitrarily complex and diverse as to necessitate such a process in
> order to assure interoperability, CTP provides for universal
> interoperability at the data transport level.
>
> Traditional entity-relationship modeling entails record- and table-
> level replication in distributed environments because it binds sets of
> attributes to individual physical tables representing discrete
> entities. Under CTP, distribution of attributes and their values is not
> accomplished in the same manner. CTP uses the UCF to distribute
> metadata describing the relational organization of information across
> servers, while it leaves particular attribute values at particular
> locations, where CTP servers act as their authoritative hosts. User
> agents and interoperating CTP servers may maintain the currency of
> their local caches of attribute values according to any algorithm
> appropriate to their own purposes.
>
> Instead of binding sets of attributes to particular tables representing
> particular entities, CTP uses the abstractions that make up the UCF to
> describe scopes of relevance for link and use attributes. Attributes
> can be declared to be relevant for all links of a particular link type,
> or for all links used by a particular use type, or for all instances of
> a particular use or link regardless of general context (use type and/or
> link type), or for any other of the finite number of scopes that can be
> described by the possible permutations of the UCF elements. CTP servers
> provide and maintain appropriate attributes and values for various
> contexts according to these scopes of relevance.
>
> CTP contexts do not presuppose or require locking mechanisms, since
> whenever user agents request an occasion to modify a context, CTP
> servers notify them whether the context has been modified in whole or
> in part since the time of the user agent's local copy. CTP servers may
> implement shared contexts as freely interruptible or as "reservable"
> according to diverse governing principles. Separate protocols may
> implement locking or other "reservation" schemes on top of the CTP
> layer, for contexts for which that is desired.
>
> Message structure
>
> - requests, responses, occasions, events
>
> State distribution system
>
> - metadata, attributes, values, hosts
>
> Data structure
>
> - denormalized
>
> Errors / Responses
>
> Appendix A: CTP and RDF
>
> The correlates for RDF's subjects, predicates, and objects under CTP
> are uses, link types, and links.
>
> CTP/Use - [RdfSubject]
> CTP/Link Type - [RdfPredicate]
> CTP/Link - [RdfObject]
> CTP moves beyond RDF's knowledge-modeling assertions by splitting
> subjects into use types and uses, and then using the combination of use
> types with link types to define atomic applications, contexts which
> automatically provide all fundamental information functions needed to
> manage information for any application. Because CTP is designed in this
> manner, it is perfectly suited for RDF applications. It simply goes
> beyond the knowledge-modeling purposes of RDF and the semantic web, to
> providing universal fundamental functions and implicit interoperability
> among all applications.
>
> Appendix B: CTP and REST
>
> Roy Fielding has articulated a comprehensive set of engineering
> principles which constitute an architectural style
> called "representational state transfer" (REST) intended to govern
> optimal Web architecture and Web application design. By describing how
> CTP's implementation of universal state transfer compares with the
> architectural principles of REST, we can address its design
> implications in an orderly and reasonably complete manner. The chief
> differences stem from the fact that past architectural principles have
> presupposed the arbitrary complexity of state and data models, and
> therefore have taken certain design decisions geared toward managing
> complexity, which are unnecessary within CTP.
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
|
