Loading...
Posts on the
Design Decomposition Blog
Iridium Satellite Collision in Space
You might have seen the recent news reports about the collision between U.S. and Russian communication satellites. The U.S. satellite was one of the Iridium satellites. What wasn’t reported and you probably don’t know is that an object database management system (ODBMS) is an important part of the Iridium system. Even though ODBMSs are a [...]
February 13, 2009
(The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services
I am now also posting on the Cutter Blog. My initial posting is (The Acronym) SOA is (Perhaps) Dead (at Some Companies); Long Live Services. It is a response to Anne Thomas Manes’ SOA is Dead; Long Live Services on her blog at the Burton Group.
January 9, 2009
Atomicity
The typical definition of an atomic task or process is one that cannot be decomposed further. This is vague and subject to interpretation. The Decomposition Matrix on this site uses a specific definition: A task (for business process diagrams) or a process (for data flow diagrams) is atomic if every input relates to every output [...]
December 3, 2008
Well-Formed Business Process Diagrams
My last posting referenced the criteria for a well-formed business process diagram mentioned in Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. I am going to expand on their criteria to create a more comprehensive definition of a well-formed business process diagram. To start, here are three criteria [...]
November 18, 2008
Recent Business Process Modeling Books
I recently received two new books on business process modeling. Both books looked interesting because they had great titles. As it turns out, one book is great and the other not so good. The not so good book is Business Process Driven SOA using BPMN and BPEL by Matjaz B. Juric and Kapil Pant. There [...]
October 9, 2008
The Design Decomposition Blog
is written by Doug Barry.
Loading...

The Web Services Resource Framework (WSRF) defines a generic and open framework for modeling and accessing stateful resources using Web Services. This includes mechanisms to describe views on the state, to support management of the state through properties associated with the Web Service, and to describe how these mechanisms are extensible to groups of Web Services. It defines the means by which:

Organization: OASIS

More information: WSRF page on the OASIS website (new window)

Additional related specifications that have been developed that will be considered by OASIS for the WSRF. These were developed by Computer Associates, Fujitsu, Globus Alliance, Hewlett-Packard, IBM, and the University of Chicago. The motivation for these specifications is that while Web service implementations typically do not maintain state information during their interactions, their interfaces must frequently allow for the manipulation of state, that is, data values that persist across and evolve as a result of Web service interactions

WS-ResourceProperties: This defines how the data associated with a stateful resource can be queried and changed using Web Services technologies. This allows a standard means by which data associated with a WS-Resource can be accessed by clients. The declaration of the WS-Resource’s properties represents a projection of or a view on the WS-Resource’s state. This projection represents an implied resource type which serves to define a basis for access to the resource properties through Web service interfaces. More on WS-ResourceProperties at IBM website (new window).

WS-ResourceLifetime: This defines two ways of destroying a WS-Resource: immediate and scheduled. This allows designers flexibility to design how their Web Services applications can clean up resources no longer needed. More on WS-ResourceLifetime at IBM website (new window).

WS-BaseFaults: This defines an XML Schema type for a base fault, along with rules for how this fault type is used by Web Services. A designer of a Web Services application often uses interfaces defined by others. Managing faults in such an application is more difficult when each interface uses a different convention for representing common information in fault messages. Support for problem determination and fault management can be enhanced by specifying Web Services fault messages in a common way. When the information available in faults from various interfaces is consistent, it is easier for requestors to understand faults. It is also more likely that common tooling can be created to assist in the handling of faults. More on WS-BaseFaults at IBM website (new window).

WS-ServiceGroup: This defines a means by which Web Services and WS-Resources can be aggregated or grouped together for a domain specific purpose. In order for requestors to form meaningful queries against the contents of the ServiceGroup, membership in the group must be constrained in some fashion. The constraints for membership are expressed by intension using a classification mechanism. Further, the members of each intension must share a common set of information over which queries can be expressed. More on WS-ServiceGroup at IBM website (new window).

Also see WS-Notification.

Related content for: Web Services Resource Framework (WSRF)

More on the general topic: Models and metamodels

Read more free articles on this site

There are nearly 400 pages of articles on this site with over 130 pages on Web services and service-oriented architecture.

Search this site for more articles

Custom Search

Browse this site for more articles

Click on the topics below to browse the articles on this site. You can see more detail by clicking on the arrows. This highlights the location of the current article: Web Services Resource Framework (WSRF).

Loading...