Interoperability is an important factor in the success of solutions that are based on Web Services and Service Oriented Architecture (SOA), along with other key factors such as contracts, loose coupling, and reuse. Interoperability is generally accomplished by developing your Web Services using the well-established guidelines for implementing Web Services and by following industry standards such as XML, WSDL, SOAP, and UDDI. However, just following Web Services standards and guidelines during the development phase of a project isn't sufficient to achieve interoperability.
[May 2, 2005] XML and Web Services security specifications define elements to incorporate security tokens within a SOAP message. We propose a method for mapping such messages to an abstract syntax in the style of Dolev-Yao, and in particular Casper notation. We show that this translation preserves flaws and attacks. Therefore we provide a way for all the methods, and specifically Casper and FDR, that have been developed in the last decade by the theoretical community for the analysis of cryptographic protocols to be used for analysing WS-Security protocols. Finally, we demonstrate how this technique can be used to prove properties and discover attacks upon a proposed Microsoft WS-SecureConversation protocol.
Public Review Drafts from the OASIS Web Services Security (WSS) TC on Message Security v1.1 and a number of token profiles.
As the Apache Software Foundation, Microsoft Corp. and IBM sort out licensing issues around making the WS-Security specification open-source-friendly, the issue becomes something of a precedent for how Web services specifications will evolve in the open-source world.
The alphabet soup of WS-* is difficult to master and yet, very essential for the immediate future. Here's our pocket guide to the basics of the 12 most important WS standards and in what situations they apply, for both .NET and Java.
The Achilles' heel of service-oriented architectures (SOAs) has been policy enforcement. A standard is emerging for run-time control: the Governance Interoperability Framework (GIF). Web Services Pipeline, 1 June 2005.
According to the Organization for the Advancement of Structured Information Standards (OASIS), the two different groups of vendors behind the overlapping specifications WS- Reliability and WS-ReliableMessaging have agreed to work together to end duplicate efforts. Web Services Pipeline, 10 May 2005.
Two reliable delivery specifications create confusion. Examine two Web services specifications that address the problem of reliably delivering messages between Simple Object Access Protocol (SOAP) endpoints: WS-ReliableMessaging (WS-RM) and WS-Reliability (WS-R). Follow along with Doug Davis as he summarizes the key differences and similarities between them.
The good news is that a group of technology heavyweights, including IBM, Microsoft, BEA Systems and TIBCO Software, submitted the latest version of their Web Services ReliableMessaging (WS-RM) specification to the Organization for the Advancement of Structured Information Standards (OASIS).
METEOR-S project on Semantic Web Services and Processes at the Large Scale Distributed Information Systems Lab at the University of Georgia. Applying Semantics in Annotation, Quality of Service, Discovery, Composition, Execution.
A Web services security specification, introduced this week by IBM and Microsoft, could emerge as a rival to the existing Sun Microsystems-backed Liberty Alliance Project.
James Snell's introduction to BPELWS, WS-Coordination, and WS-Transaction
The firms make sure they won't be left at home when the Business Process Execution Language committee for Web services convenes next week. May 8, 2003.
This specification describes coordination types that are used with the extensible coordination framework described in the WS-Coordination specification. It defines two coordination types: Atomic Transaction (AT) and Business Activity (BA). Developers can use either or both of these coordination types when building applications that require consistent agreement on the outcome of distributed activities.
BPEL4WS provides a language for the formal specification of business processes and business interaction protocols. By doing so, it extends the Web Services interaction model and enables it to support business transactions. BPEL4WS defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces.
This Basic Profile consists of a set of non-proprietary Web services specifications, along with clarifications and amendments to those specifications which promote interoperability.
The Web Service Inspection Language (WSIL) is an XML document format to facilitate the discovery and aggregation of Web service descriptions in a simple and extensible fashion.
The recently released Business Process Execution Language for Web Services (BPEL4WS) specification is positioned to become the Web services standard for composition. It allows you to create complex processes by creating and wiring together different activities that can, for example, perform Web services invocations, manipulate data, throw faults, or terminate a process. These activities may be nested within structured activities that define how they may be run, such as in sequence, or in parallel, or depending on certain conditions. This series of articles aims to give readers an understanding of the different components of the language, and teach them how to create their own complete processes.