Cover Pages: XML Daily Newslink: Tuesday, 12 June 2007

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com

Headlines

WSO2 Releases Synapse-based Open-source ESB
Unit-Testing XML
SIP SAML Profile and Binding
Google Apps: A Simple, Hosted On-Demand Offering
Interview and Book Excerpt: RESTful Web Services

WSO2 Releases Synapse-based Open-source ESB
Martin LaMonica, CNET News.com Blog

Open-source start-up WSO2 has released an open-source enterprise service bus based on any Apache Synapse project. Called WSO2 ESB, the server software is designed to integrate different applications by translating between different protocols and converting different XML formats. The product is based on Synapse, an open-source ESB done at the Apache Foundation with the participation of WSO2 employees. The company adds additional features on top of Synapse including a Web-based administration console and a registry and repository. There are several open source ESB product in the marketplace, such as MuleSource, as well as those from entrenched integration vendors, such as IBM. WSO2, which was started by IBM employees worked on Web services protocols, distinguishes itself from the competition by being very lightweight and designed for XML, said to Paul Fremantle, WSO2 co-founder and Vice President of technical sales. The company's revenue model is to provide services, come including installation and support for the product which is available under the Apache license. According to the announcement: "The WSO2 ESB is the first product to be closely based on the Apache Synapse 1.0 Web service management and integration broker, also being launched today. The Apache Synapse project has built a high-performance, flexible SOA framework around XML and Web services. The Apache Synapse project has released 1.0 of the code base after graduating from the Apache Incubator project at the beginning of the year. The WSO2 ESB 1.0 extends the Apache Synapse XML router and mediation engine with an integrated registry and simple graphical interface that allows administrators to connect, manage and transform Web service interactions across their networks. The WSO2 ESB can instantly virtualize services, enabling users to route, version, load-balance, log, monitor and manage services without changing their application code."

See also: the announcement

Unit-Testing XML
Stefan Bodewig, InfoQ

There are many occasions where software creates XML output. XML documents are used for data interchange between different applications, web application create (X)HTML output or respond to AJAX requests using little XML snippets. There are many use cases where XML is generated and the outputs have to be tested as much as any other part of the application. Several approaches are used for testing the generated XML, and each of these approaches has its flaws when used in isolation... XMLUnit is a SourceForge open source project licensed under the BSD license. It provides a small library of interrelated classes that simplify each of the different ways to test XML pieces that have been outlined in the previous section. Special APIs are provided to simplify writing unit tests with J/NUnit, but the library itself is fully usable without any testing framework at all. XMLUnit's APIs will accept 'pieces of XML' as input using several different forms. In most cases they can be provided as InputStreams, Readers, Strings, InputSources or readily parsed DOM Document instances. XMLUnit also provides a Transform class that can be used to apply an XSLT transformation to an existing input (using one of the formats provided above) and use the output of this transformation in further tests. XMLUnit can validate an XML document against a DTD or W3C XML Schema. Later versions of XMLUnit will leverage the javax.xml.validation package added with JAXP 1.3 and thus potentially offer validation for RELAX NG, Schematron or other grammars as well... Any software that creates XML should have tests for its output just like it needs tests for any other part of its functionality. Testing XML can take several different approaches and sometimes a combination of more than one approach yields the best results. For simple cases comparing the generated output with an expected output probably is enough, for more complex cases formal validation of the output structure should be combined with content tests that involve either XPath queries (for small outputs) or programmatic tests. The APIs for dealing with XML in Java are often inconvenient to use, XMLUnit provides a simplified API for all test approaches outlined in this article. There is also support for HTML documents that are not well-formed XML via implementations of special DocumentBuilder and SAXParser classes. In addition to the XMLAssert class that is shown in some examples there also is a XMLTestCase class that extends JUnit's TestCase and provides similar methods to XMLAssert.

SIP SAML Profile and Binding
H. Tschofenig, J. Hodges (et al, eds) IETF Internet Draft

Members of the IETF Session Initiation Protocol (SIP) Working Group have published a "SIP SAML Profile and Binding" Internet Draft. The document specifies a Session Initiation Protocol (SIP) profile of Security Assertion Markup Language (SAML) as well as a SAML SIP binding. The defined SIP SAML Profile composes with the mechanisms defined in the SIP Identity specification and satisfy requirements presented in 'Trait-based Authorization Requirements for the Session Initiation Protocol (SIP)'. Trait-based authorization is where one is authorized to make use of some resource based on roles or traits rather than ones identifier(s). Various means of providing trait-based authorization exist: authorization certificates (RFC 3281), SPKI (RFC 2693), or extensions to the authenticated identity body (RFC 3893). The authors selected SAML due to its increasing use in environments such as the Liberty Alliance, and the Internet2 project, areas where the applicability to SIP is widely desired. The goal of this endeavor is to specify a SIP profile of SAML (aka a 'SIP SAML profile') such that a subject's profile attributes, and their domain's certificate, can be conveyed to a relying party using SAML. Employing SAML in SIP necessitates devising a new SAML profile(s) and binding(s) because the those already specified in the SAMLv2 specification set are specific to other use contexts, e.g., HTTP-based web browsing. Although SIP bears some similarity to HTTP, it is a seperately distinct protocol, thus requiring specification of SIP-specific SAML profile(s) and binding(s). This is technically straightforward as both SAML and SIP are explicitly extensible. The 'Authenticated Identity Management in SIP' specification (RFC 4474) facilitates the composition of SAML and SIP in that it defines a 'mediated authentication architecture' where verifying endpoints verify SIP identity assertions signed by an Authentication Service (AS). The semantic being that the AS is vouching that it did indeed authenticate the calling party. Such an Authentication Service, which likely has access to various pieces of information concerning the calling party, could also act as a SAML Authority, and make such information available to the callee via SAML.

See also: SAML references

Google Apps: A Simple, Hosted On-Demand Offering
Cameron Sturdevant, eWEEK

eWEEK Labs found Google Apps to be a simple, hosted on-demand offering that can be used with nothing more than a PC with a Web browser. On its own, Google Apps is a simple, hosted on-demand offering that requires no additional hardware or software beyond a PC with a Web browser. Enabling Google Apps for SSO (single sign-on) via SAML (Security Assertion Markup Language) definitely ups the ante in terms of IT resources that must be available to an organization. However, in exchange for the additional IT investment, extending Google Apps in this way saves users time logging in to the system and gives administrators one fewer user list to track. SAML is an XML security standard for exchanging authentication and authorization data between security domains. Google Apps offers optional SAML-based authentication and authorization add-ons through partnerships with several vendors, including Sxip Identity and SSOCircle. For our tests, we used VWware's VMware Player to run a virtual machine provided by Sxip Identity. When a user started to log in to the hosted Google Apps, Google generated a SAML request and redirected the browser to the SSO sign-in URL that we configured as our identity provider—in this case, our Sxip Identity VM that we'd integrated through LDAP with an Active Directory instance. Because Google is using the SAML standard to assist with user management, IT managers have choices in the vendors they may seek for these services. There are several open-source SAML identity providers, including the Central Authentication Service that was developed at Yale University. There are several other university-originated projects, many of which have active user communities around them. When using any of these identity providers, Google acts as the service provider offering services, including the eweekdemo.com start page that was the basis for our testing. Using SAML, Google Apps administrators can also turn to hosted or home-built identity providers to authenticate users who are trying to access secured content.

Interview and Book Excerpt: RESTful Web Services
Stefan Tilkov, InfoQ

This article presents an interview based upon the O'Reilly book "RESTful Web Services", by Leonard Richardson and Sam Ruby. Accompanying the article is a sample chapter: 'Chapter 4: The Resource-Oriented Architecture'. The world's shortest tutorial on what REST actually is: "Give everything its own URI." There are hundreds of everyday activities that people used to do through the mail, over the phone, or through featureful Internet protocols like FTP and WAIS. Now we do these things over the web. The web's interface (HTML, links, and forms) is very simple but it's good enough to encapsulate all these disparate activities. Because everything works the same way it's easy to use, and you get emergent properties like PageRank. REST is a formal description of the vague things just mentioned: 'simple' and 'encapsulate' and 'everything works the same way'. When you apply REST to the problem of distributed programming, as the authors do in the book, you get a simple architecture that can solve a huge number of problems in the space. A RESTful architecture is the best one for any web service. That is, if you don't want REST you probably don't want HTTP either. But it's much easier to make the case for read-only applications. A read-only RESTful web service works exactly the same way as a read-only web site. We've been exposing data through GET for fifteen years. We know how to do it. We have client libraries in every language, debugging tools, transparent intermediaries like caching proxies. But most websites don't expose write operations RESTfully: they tend to put the operation name in the URI: '/story/publish' and '/product/add-to-cart', and so on. To get to REST you need to obey some kind of uniform interface constraint. This means thinking of the URI as identifying an object: '/story' and '/product'. A thing whose state you can change by sending messages...

See also: the sample chapter


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors