Cover Pages: XML Daily Newslink: Thursday, 11 October 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

Bytes not Infosets
Mozilla Plans Firefox Browser For Mobile Devices
Proposed Working Group: HyperText Transport Protocol Bis (httpbis)
Building RESTful Services for Your Web Application
IODEF Specification Approved by the IESG as a Proposed Standard
Open Source WS Stacks for Java - Design Goals and Philosophy
Integrate XForms with the Google Web Toolkit, Part 3

Security is the one area where the WS-* world has developed a set of standards that provide significantly more functionality than has so far been standardized in the REST world. I don't believe that this is an inherent limitation of REST; I'm convinced there's an opportunity to standardize better security for the REST world. So I've been giving quite a lot of thought to the issue of what the REST world can learn from WS-Security (and its numerous related standards). Peter Gutmann has a thought-provoking piece on his web site in which he argues that XML security (i.e. XML-DSig and XML encryption) are fundamentally broken... I would suggest that there are two different ways to view XML: (1) the concrete view: in this view, interchanging XML is all about interchanging sequences of bytes in the concrete syntax defined by XML 1.0; (2) the infoset view: in this view, interchanging XML is all about interchanging abstract structures representing XML infosets; the syntax used to represent the infoset is just a detail to be specified by a binding; the infoset view tends to lead to bindings up the wazoo. I think each of these views has its place. The infoset is an invaluable conceptual tool for thinking about XML processing. However, I think there's been an unfortunate tendency in the XML world (and the WS-* world) to overemphasize the infoset view at the expense of the concrete view. I believe this tendency underlies a lot of the problems that Gutmann complains of. There's nothing unstable or unsignable about an XML document under the concrete view. It's just a blob of bytes that you can hash and sign as easily as anything else (putting external entities on one side for the moment). The infoset view makes it hard to accommodate non-XML formats as first-class citizens. If your central data model is the XML infoset, then everything that isn't XML has to get mapped into XML in order to be accommodated. For example, the WS-* world has MTOM. This tends to lead to reinventing XML versions of things just so they can be a first-class citizens in an infoset-oriented world... Although infoset-level APIs are needed for processing XML, when you use infoset-level APIs for interchanging XML between separate components, I believe you pay a significant price in terms of flexibility and generality. In particular, using infoset-level APIs at trust boundaries seems like a bad idea. My conclusion is this: one aspect of the WS-* approach that should not be carried over to the REST world is the emphasis on XML infosets.

Mozilla Plans Firefox Browser For Mobile Devices
Elena Malykhina, InformationWeek

There isn't a perfect mobile browser and there is plenty of room for competition in the space, which is why Mozilla is stepping up its efforts to improve the browsing experience on mobile phones, the company said this week. Mozilla's plans include adding mobile devices to the first class/tier-1 platform set for Mozilla 2, the company's all-in-one open source Internet application suite that comes with a Web browser, e-mail, and newsgroup client. The move will make mobile devices part of Mozilla's core platform, Schroepfer said. Mozilla also will roll out a version of Mobile Firefox, which can run Firefox extensions on mobile devices. Developers will be able to build rich applications for Mobile Firefox using extensible user-interface language (XUL), a markup language based on XML. Mozilla browsers are already available on Nokia N800 smartphones and Mozilla offers Minimo, its mini Firefox browser, to users with a variety of Windows Mobile-based smartphones. It also offers a service called "Joey," which brings Firefox Web content to mobile devices. The service allows a person to use Firefox to send text clippings, pictures, videos, RSS content, and live bookmarks to their phone through the Joey server, and the content can then be accessed on the phone's Web browser. Mozilla, however, wants to further bridge the desktop and mobile browsing experience by allowing bookmarks, history, extensions, and other Firefox capabilities to work just as well on mobile devices. Mozilla is part of a larger movement by technology companies to bring a rich Internet experience to mobile devices. Last week, chip designer ARM Holdings partnered with six other companies to develop a new Linux-based open-source platform for ultra-mobile PCs. The platform will include a mobile operating system, application development framework, and Internet browser.

Proposed Working Group: HyperText Transport Protocol Bis (httpbis)
Staff, IESG Secretary Announcement

The Internet Engineering Steering Group has announced the proposal for a new "HTTP bis" IETF working group in the Application Area, to be managed by Application Area Director Chris Newman (Sun Microsystems) and Lisa Dusseault (Open Source Applications Foundation). A draft Working Group Charter has been submitted for informational purposes. The IESG has not yet made a determination about formation of the WG, but solicits public comment through October 17, 2007. Hypertext Transfer Protocol (HTTP/1.1) was published as IETF Standards Track Request for Comments (RFC) #2616 in June 1999. Its editors include Roy T. Fielding, James Gettys, Jeffrey C. Mogul, Henrik Frystyk Nielsen, Larry Masinter, Paul J. Leach, and Tim Berners-Lee. According to the proposed WG Charter, "HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC 2616 to: (1) Incorporate errata and updates—e.g., references, IANA registries, ABNF; (2) Fix editorial problems which have led to misunderstandings of the specification; (3) Clarify conformance requirements; (4) Remove known ambiguities where they affect interoperability; (5) Clarify existing methods of extensibility; (6) Remove or deprecate those features that are not widely implemented and also unduly affect interoperability; (7) Where necessary, add implementation advice; (8) Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications). In making these refinements, the WG should consider implementer experience, demonstrated use of HTTP, and the impact on existing implementations and deployments. The Working Group must not introduce a new version of HTTP, and should not introduce new features or capabilities to HTTP. The Working Group's specification deliverables are: [i] a document that is suitable to supersede RFC 2616, and [ii] a document cataloguing the security properties of HTTP.

See also: the RFC2616bis Issues list

Building RESTful Services for Your Web Application
Roland Barcia and Steve Ims, IBM developerWorks

"Introducing Project Zero, Part 1" explores a powerful, yet simple, platform to develop and execute modern Web applications. Project Zero is an IBM incubator project, focused on agile development of Web 2.0 applications following Service-Oriented Architecture (SOA). Web 2.0 applied to SOA allows Web artifacts to extend the reach of SOA. Think of this as Web-extended SOA. Project Zero introduces a simple environment for creating, assembling, and executing applications based on popular Web technologies. The Project Zero environment includes a scripting run time for Groovy and PHP, with application programming interfaces optimized for producing Representational State Transfer (REST)-style services, integration mashups, and rich Web interfaces. Project Zero is an incubator project started within IBM that focuses on agile development of the next generation of dynamic Web applications. Project Zero is now being developed openly using a community-driven commercial development process. In this first article installment in the Project Zero series, get a hands-on, guided tour of the project's innovations to create, assemble, and deploy powerful Web applications. First, you are introduced to the community-driven Project Zero and its conventions for creating RESTful Web services. Using a step-by-step example, you set up the environment, create a Zero project, build a RESTful service to expose data, test your application, and import a sample application to consume the RESTful services. Part 2 in this article series which will show how to build RESTful services for more complex data, and introduce other parts of the platform that can help assemble, secure, and deliver fully functional Web-extended SOA.

IODEF Specification Approved by the IESG as a Proposed Standard
Roman Danyliw, Jan Meijer, Yuri Demchenko (eds), IETF Internet Draft

The IESG has announced the approval of "The Incident Object Description Exchange Format" specification as an IETF Proposed Standard. This document has been produced by members of the IETF Extended Incident Handling Working Group. There was consensus in the WG to publish this document, though Working Group has now closed. There are seven implementations of the IODEF that provided useful feedback on the completeness and quality of the specification. These implementations come from CERT-Verbund (SIRIOS), Cooper-Cain Inc.* (Anti-Phishing WG), Cyber Solutions Inc.*, DFLabs*, eCSIRT.net, MIT Lincoln Labs*, and NTT*. Furthermore, a subset of these organizations [noted by an asterisk] participated in a semantics interoperability event that also yielded additional feedback on the data model. The Incident Object Description Exchange Format (IODEF) defines a data representation that provides a framework for sharing information commonly exchanged by Computer Security Incident Response Teams (CSIRTs) about computer security incidents. The I-D document describes the information model for the IODEF and provides an associated data model specified with XML Schema. Organizations require help from other parties to mitigate malicious activity targeting their network and to gain insight into potential threats. This coordination might entail working with an ISP to filter attack traffic, contacting a remote site to take down a bot-network, or sharing watch-lists of known malicious IP addresses in a consortium. IODEF provides an XML representation for conveying incident information across administrative domains between parties that have an operational responsibility of remediation or a watch-and-warning over a defined constituency. The data model encodes information about hosts, networks, and the services running on these systems; attack methodology and associated forensic evidence; impact of the activity; and limited approaches for documenting workflow. The IODEF is only one of several security relevant data representations being standardized. Attempts were made to ensure they were complimentary. The data model of the Intrusion Detection Message Exchange Format influenced the design of the IODEF... Implementing the IODEF in XML provides numerous advantages. Its extensibility makes it ideal for specifying a data encoding framework that supports various character encodings. Likewise, the abundance of related technologies (e.g., XSL, XPath, XML-Signature) makes for simplified manipulation.

See also: the specification

Open Source WS Stacks for Java - Design Goals and Philosophy
Stefan Tilkov, InfoQ

In addition to the options offered by commercial vendors, there are a number of open source Java frameworks one can choose from to implement Web services. Among the most popular open source stacks for implementing a SOAP/WS-* based solution in the Java space are Apache Axis2, Apache CXF, Spring Web Services, JBossWS and Sun's Metro. Stefan Tilkov posed a number of questions to the lead developers of these stacks about their design goals, their approach towards Java and Web services standards, data binding, accessing XML, interoperability, REST support, and framework maturity. As was to be expected, the results revealed many similarities and some noteworthy differences. The developers interviewed were Paul Fremantle (Axis2), Dan Diephouse (CXF), Arjen Poutsma (Spring Web Services), Thomas Diesler (JBossWS) and Kohsuke Kawaguchi (Metro). "There are some design goals that are shared among of all of the stacks, such as extensibility, modularity, and performance. Axis2 is designed around an XML object model called AXIOM, a mixture of streaming and tree-based messaging, and provides pluggable data binding support; CXF supports pluggable transports, data bindings, and can even support alternative formats such as JSON. Spring-WS supports lots of different ways to handle XML, too—from XPath-based access to a number of XML APIs such as DOM, SAX and StAX to data binding approaches such as JAXB, Castor and XStream. Metro also features pluggable transports and encodings. Assuming all of these approaches have been put into practice and actually work as expected, it's hard to see any major difference in this regard. Paul Fremantle noted that Axis2's architecture was designed to be implementable in both C and Java. He also highlighted Axis2's module concept, which allows related collections of handlers to be deployed, together with libraries and data files, as a single unit. Dan Diephouse pointed to CXF's embeddability as one of its key features; another aspect he noted was the focus on ease-of-use for the developer. Arjen Poutsma put strong emphasis on Spring-WS's support for the 'contract-first' style of WS development. Thomas Diesler pointed out that JBossWS can support both its own native stack as well as integrate with others, including CXF and Metro. Interoperability is listed by Sun's Kohsuke Kawaguchi as a design goal for Metro...

Integrate XForms with the Google Web Toolkit, Part 3
Michael Galpin, IBM developerWorks

The Google Web Tookit (GWT) has become a very popular way to develop Ajax applications. It allows Java developers to rapidly create Ajax applications by leveraging their knowledge of Java technology without requiring any knowledge of JavaScript. XForms represents an evolution in the HTML standard, and allows for simple constructs to create complex, dynamic behavior. Both GWT and XForms are powerful enough to provide complete solutions to many problems. This four-part series demonstrates how to use the Google Web Toolkit (GWT) and XForms together to create a dynamic Web application. Part 1 looked at the two technologies and how both had JavaScript underpinnings. Part 2 shows how to create a small application with two pages. One page uses GWT to show a list of artists managed by a record company. The second page uses XForms to display the albums recorded by a particular artist. Part 3 uses GWT and XForms on the same page. It shows how to take advantage of each technology's bindings to JavaScript by using JavaScript to achieve interactivity between GWT and XForms. In this installment, Part 3, we refactor the rock star application built in Part 2. That application allows for record executives to manage artists and their albums. We don't change any of the functionality from Part 2; instead we change the implementation of that functionality by mixing GWT and XForms together. You'll see how GWT can be easily introduced to any existing Web page. We use a GWT-style Ajax call to load the data dynamically and then use GWT's JSNI to dynamically create the XForms model. This will allow you to simplify your page, and you'll simplify it even more by using GWT JSNI to dynamically create your XForms controls. Mixing GWT elements will not only simplify the server-side code, it will create smaller initial pages, with faster downloads and rendering.


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

Headlines

Sponsors