Standards Descriptions - V2

Here's another pass at a list of standards efforts.  I have tried to
respond to comments as best I can.  Again, I don't think that this is at
a stage where it would be an appropriate WG product -- there's way too
much personal opinion expressed, for one thing -- but I hope it is at
least interesting and useful to the WG members individually.
Partial List of Standards and Standards Wannabe's
Following is a partial list of standards efforts of which I am aware,
along with my personal opinion of what's going on. 
SOAP - Basic messaging spec for Web services. SOAP 1.1
<http://www.w3.org/TR/SOAP/>  has been very widely implemented and is
part of the WS-I Basic Profile Version 1.0
<http://www.ws-i.org/Profiles/Basic/2003-03/BasicProfile-1.0-BdAD.html>
. SOAP 1.2 <http://www.w3.org/TR/2003/REC-soap12-part0-20030624/>  went
to Recommendation status in June, 2003. It does not seem likely that
SOAP 1.2 will be particularly controversial and major vendors will
probably implement it quickly now that it is a recommendation.
EbMS
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg>
- EbXML Messaging - transport, routing and packaging of business
transactions. Part of the larger ebXML structure, this spec leverages
SOAP 1.1 but adds a number of business-critical capabilities such as
security (roughly at the level of WS-Security, I think) and reliability.
EbMS 1.0 was part of the original ebXML package, ebMS 2.0 is a
significant improvement, currently in "final draft" in OASIS (I think).
In practice it appears that much of the industry uptake of ebXML has
been essentially ebMS as opposed to the higher level portions of the
ebXML package.
WSDL - Basic Web services description spec. WSDL 1.1
<http://www.w3.org/TR/wsdl>  has been very widely implemented and is
part of the WS-I Basic Profile Version 1.0
<http://www.ws-i.org/Profiles/Basic/2003-03/BasicProfile-1.0-BdAD.html>
. WSDL 1.2 <http://www.w3.org/2002/ws/desc/>  is being developed in the
W3C and is in a "middle" stage of the process. There does not seem to be
any particular competition to WSDL 1.2 in other standards organizations
and major vendors will probably implement it quickly once it becomes a
recommendation (which will take a while).
EbCPPA
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa>
- EbXML Collaboration Protocol Profile and Agreement - The Collaboration
Protocol Profiles (CPPs) and Agreements (CPAs) which define a business
partner's technical capabilities to engage in electronic business
collaborations with other partners, and the technical agreement between
two or more partners to engage in electronic business collaboration.
Version 1.0 was part of the original ebXML package, version 2 has
significant upgrades and was ratified Dec, 2002. Although the CPP/CPA
framework seems very business oriented, I do not know of many (or any,
to be honest) examples of it being used in production. 
UDDI
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec>
(Universal Description, Discovery, and Integration)- Web services
registry. Version 2 adopted 4/2003 has been implemented by a number of
vendors. Version 3, under development, includes new features like
federation, which should allow communication between locally customized
servers. Implementation of UDDI on the internet has stalled but there is
widespread interest in using UDDI in corporate intranets.
ebXML Registry Services <http://www.ebxml.org/specs/ebrs2.pdf>  - -
ebeXML registry, provides function along lines similar to UDDI. Version
2 adopted 12/2001. See also the ebXML Registry Information Model
<http://www.ebxml.org/specs/ebrim2.pdf>  
AS2 - Probably best viewed as an alternative to Web services, AS2 is a
draft spec
<http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-13.txt>  from
the IETF. It has not made it completely through the IETF process, but it
appears to be relatively stable nonetheless. It provides basic but
non-extensible security and reliability features for a payload that may
be a binary file (typically an old fashioned EDI file) or XML. AS2 seems
to be appropriate for simple transactions, particularly those that can
be performed synchronously, but may not lend itself to more elaborate
scenarios. WalMart has provided a huge boost to AS2 implementation by
requiring in order to do EDI business with them. See, for example,
discussions in product offerings from Isoft
<http://www.isoft.com/press_walmart.htm>  and Sterling Commerce
<http://www.sterlingcommerce.com/go/walmart/walmartwebinar.html> .
XML Signature <http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/>  -
Digital signature for an XML document, providing proof of data
integrity, message and user authentication. Used by WS-Security and
ebXML security. This is a mature, widely used spec.
XML Encryption <http://www.w3.org/Encryption/2001/>  - Digital
encryption of documents or portions of documents. Recently (12/2002)
finalized, not yet widely used but presumably it will be.
XKMS <http://www.w3.org/2001/XKMS/>  - XML Key Management - Protocols
for distributing and managing public keys, intended for use with XML
Signature and Encryption. Work in progress. Based on XKMS proposal
http://www.w3.org/TR/xkms/
WS-CHOR <http://www.w3.org/2002/ws/chor/>  - Web Services Choreography
WSCI <http://www.w3.org/TR/2002/NOTE-wsci-20020808/> , from Sun and
others (not MS/IBM), was a major submission but the working group has
received other submissions and has moved significantly beyond WSCI.
Describes the flow of messages exchanged by a Web Service participating
in choreographed interactions with other services. Considerable overlap
with BPEL, but more declarative and oriented toward message sequencing
rather than process description. WS-CHOR is intended to be a language
that allows machines to figure out how to use Web services, BPEL focuses
on how to control Web services.
BPEL <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel>
- Web Services Business Process Execution Language business process
execution language which form the necessary technical foundation for
multiple usage patterns including both the process interface
descriptions required for business protocols and executable process
models. Based on BPEL4S
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbiz2
k2/html/bpel1-0.asp>  submission from Microsoft, IBM and BEA.
Considerable overlap with Web Services Choreography, but more process
oriented. See above.
ebBPSS
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp>  -
ebXML Business Process - Representation and model compatible with an
underlying generic metamodel for business processes, activities, and
collaboration. This is the ebXML version of choreography, and I think it
is simpler than either WS-CHOR or BPEL. Version 1.001 was part of the
original ebXML package, and I think that an OASIS TC is just now in the
process of starting up to work on enhancements. I am not aware of any
significant applications of ebBPSS.
WS-Security
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/ws-security.asp>  - Construct secure SOAP message exchanges,
including provision for multiple security tokens for authorization and
authentication, multiple trust domains, multiple encryption technologies
and end-to-end message-level security (not just transport-level
security). Out of scope: multiple message exchanges, key exchange,
establishing and maintaining trust. WS-Security defines two core
capabilities: 1- how to use XML-Signature and XML-Encryption with SOAP
messaging. It specifies how to pass signatures and key information in a
SOAP header. 2- how to pass security tokens with a SOAP message.
WS-Security supports a variety of security tokens (each defined by its
own binding specification), such as userid/password, X.509 certificates,
Kerberos tickets, and SAML tokens. The WS-Security TC is just starting
in OASIS, but major vendors (MS, IBM) have already implemented the
submitted spec. 
SAML
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security>  -
Security Assertion Markup Language. Exchanging authorization and
authentication information. Version 1.0 finalized 11/2002. SAML defines
three core capabilities: 1- how to represent security tokens in XML.
These tokens are called assertions, and SAML defines three types of
assertions -- authentication, authorization, and attributes. (attributes
provide qualifying information that constrain the other assertions --
such as spending limits or timing constraints). An assertion is made by
some type of trust authority. 2- a process model for obtaining security
tokens from a trust authority. This includes a set of protocols for
accessing a trust authority. SAML defines two types of trust
authorities: Policy Decision Points (PDPs) and Policy Enforcement Points
(PEPs). SAML has defined bindings for multiple protocols, including
SOAP/WSDL. 3- a set of protocol bindings for conveying SAML tokens. SAML
1.1 defines how to pass SAML tokens for browser applications. It does
not define bindings for how to pass SAML tokens in SOAP messages -- that
is left to WS-Security. It appears that this spec may be getting some
real traction in terms of practical implementations. See, for example,
this auto industry implementation
<http://www.nwfusion.com/news/2003/0901covisint.html> . 
Reliable Messaging: A protocol that allows messages to be delivered
reliably between distributed applications in the presence of software
component, system, or network failures by implementing an
acknowledgement infrastructure. There are two major specs that differ in
some technical respects but which by and large implement the same type
of functionality:
- Web Services Reliability
<http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm>  -
OASIS TC. Based on WS-Reliability
<http://otn.oracle.com/tech/webservices/htdocs/spec/ws-reliability.html>
submission from Oracle, Sun and others.
- WS-ReliableMessaging
<http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/
dnglobspec/html/ws-reliablemessaging.asp>  from BEA Systems, Microsoft,
IBM, Tibco. Not currently submitted to any standards body but being
implemented nevertheless by several technology vendors.
XACML <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml>
- XML Access Control Markup Language - Fine-grained access control to
XML documents, including by element, sub-tree, temporal, data dependent
and so on. Here is a brief introduction
<http://www.oasis-open.org/committees/download.php/2713/Brief_Introducti
on_to_XACML.html>  to XACML. XACL <http://xml.coverpages.org/xacl.html>
from IBM, was one of the major submissions for this spec but there were
a number of others and XACML differs substantially from XACL. Spec
finalized 2/2003.
WS-Transaction Framework - WS-Transaction
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/ws-transaction.asp>  and WS-Coordination
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/ws-coordination.asp>  were originally released by IBM,
Microsoft and BEA along with BPEL4WS. These specifications have recently
been updated and revised. The latest set of specifications for the WS
Transaction Framework, published by the same authors, include an updated
WS-Coordination spec
<http://msdn.microsoft.com/webservices/understanding/advancedwebservices
/default.aspx?pull=/library/en-us/dnglobspec/html/wscoor.asp> ,
WS-AtomicTransaction
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglob
spec/html/wsat.asp>  which replaces part 1 of WS-Transaction, and
WS-BusinessActivity (still to be published) which replaces part 2 of
WS-Transaction. WS-Coordination defines the protocols for creating
activities, registering in activities, and transmitting information to
disseminate an activity. WS-AtomicTransaction defines the Atomic
Transaction coordination type, which is appropriate to use when building
applications that require a consistent agreement on the outcome of a
short-lived distributed activity, where strong isolation is required
until the transaction completes. WS-BusinessActivity defines the
Business Activity coordination type, which is appropriate to use when
building applications that require a consistent agreement on the
coordination of a distributed activity, where strong isolation is not
feasible, and application-specific compensating actions are used to
coordinate the activity. It appears to me that the WS-Transaction
Framework and the Web Services Composite Application Framework
(described below) are playing in more or less the same space and are not
obviously compatible. That is, that they are in competition.

Web Services Composite Application Framework (WS-CAF) - WS-CAF defines a
generic framework for applications that contain multiple services used
in combination (composite applications). It specifies interoperable
mechanisms to set the boundaries of an activity (such as start/end, or
success/failure), to create, access and manage context information, and
to inform participants of changes to an activity. And it supports a
range of transaction models, including simple activity scoping, single
and two phase commit ACID transactions, and recoverable long running
activities. The WS-CAF suite includes three specs published by Arjuna,
Fujitsu, IONA, Oracle and Sun: Web Service Context (WS-CTX
<http://developers.sun.com/techtopics/webservices/wscaf/wsctx.pdf> ) a
lightweight framework for simple context management, Web Service
Coordination Framework (WS-CF
<http://developers.sun.com/techtopics/webservices/wscaf/wscf.pdf> ) a
sharable mechanism that manages context augmentation and lifecycle, and
Web Services Transaction Management (WS-TXM
<http://developers.sun.com/techtopics/webservices/wscaf/wstxm.pdf> )
which comprises three distinct, interoperable transaction protocols that
can be used across multiple transaction managers. A new OASIS TC has
recently been created to further develop the WS-CAF specifications.
WS-Policy
<http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/
dnglobspec/html/ws-policy.asp>  is a grammar for specifying Web services
policy assertions such as authentication schemes, transport protocol
selection, privacy policy, QoS characteristics. Another Microsoft, IBM,
BEA spec, not submitted yet to any standards body.
WS-Addressing
<http://www-106.ibm.com/developerworks/webservices/library/ws-add/>  -
provides transport-neutral addressing for Web services that work through
firewalls, gateways, etc. Another spec from MS/IBM/BEA, it apparently
replaces WS-Routing. I don't think it has been submitted to any
standards body.
WS-Federation - A spec for standardizing the way companies share user
and machine identities among disparate authentication and authorization
systems spread across corporate boundaries. Developed by IBM/MS/BEA/RSA,
I think it is at least partly in competition with the ID-WSF from the
Liberty Alliance, discussed below..
SPML - Service Provisioning Markup Language - exchanging and
administering user access rights and resource information across
heterogeneous environments. How this differs from N other security specs
is beyond me, but supposedly it works in conjunction with WS-Security
and SAML. Currently in "public review" period at OASIS, which means it
is close to being approved as a spec, it has apparently been implemented
in the catalyst industry.
ID-FF - IDentity Federation Framework, from the Liberty Alliance
<http://www.projectliberty.org/> . Defines an architecture for providing
federated network identity that enables single signon functionality for
a user to multiple service providers. Liberty is a major consortium that
does not include MS or IBM, and the products are more or less in
competition with varioius WS-* specs. I think that ID-FF is more or less
along the same lines as WS-Policy. Submitted to OASIS.
ID-WSF - IDentity Web Services Framework - Another spec from the Liberty
Alliance, it builds on ID-FF and provides a framework for identity based
web services in a federated network identity environment. I believe that
ID-WSF is pretty much in the same space, and incompatible with,
WS-Federation. Detailed comparison is beyond the scope of this document,
but it appears that both have a number of components for which there is
no comparable function in the other, with Liberty possibly being the
more fully developed. In addition, they have made different technology
choices for similar functions (e.g. ID-WSF Discovery Services vs UDDI
for WS-Federation.
WSRP <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp>
- Web Services for Remote Portlets - Intended to provide "plug-n-play"
for portals and other apps that aggregate content. Recently adopted as
an OASIS standard, the players in the interop testing include BEA, IBM
and Oracle. Microsoft, Sun and many others participated in the TC. This
spec seems to have wide industry participation, but I have no idea how
soon to expect implementation.
Overview of MS/IBM Security roadmap
<http://www.dstc.edu.au/Tech_Transfer/Events/Evolve02/presentations/Kelv
in_Evolve_Sydney_2002.pdf> , a comprehensible slide show.
Microsoft documentation
<http://msdn.microsoft.com/webservices/understanding/specs/default.aspx>
of the WS-* specification stack.
IBM/Microsoft whitepaper
<http://msdn.microsoft.com/webservices/understanding/advancedwebservices
/default.aspx?pull=/library/en-us/dnwebsrv/html/wsoverview.aspv>  on the
WS-* stack.