This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com
How Do I Model State? Let Me Count the Ways
Ian Foster, Savas Parastatidis, Paul Watson, Mark McKeown; ACM Queue
In this article we discuss a technical matter that has spurred vigorous debate in recent years: How to define interactions among Web services to support operations on state (that is, data values associated with a service that persist across interactions, so that the result of one operation can depend on prior ones). The debate over this issue does not concern the need for such operations but rather the specifics of how exactly to model and implement service state and the associated interactions on that state. State may be modeled explicitly by the distributed computing technology used (for example, as an "object" with create, read, update, and destroy operations) or implicitly by referring to application domain-specific concepts within the interactions (for example, "create reservation" and "update reservation," messages that include a domain-specific identifier such as an ASIN—Amazon standard identification number—in the body). Along a different dimension, we may use HTTP or SOAP as an implementation technology. Our goal here is to shed light on possible approaches to modeling state. To this end, we present four different approaches and show how each can be used to enable access to a simple job management system. Then we summarize the key arguments that have been made for and against each approach. In addition to providing insights into the advantages and disadvantages of the different approaches, the discussion may also be interesting as a case study in technical debate.
(1) WS-RF Approach: The WS-RF (Web Services Resource Framework) defines conventions on how state is modeled and managed using Web services technologies. WS-RF implements an architectural style similar to that of distributed objects or resources. Projected state is explicitly modeled as an XML document (the state representation) and is addressable via a WS-Addressing EPR (endpoint reference), a conventional representation of the information that a client needs to access a network service. (2) WS-Transfer Approach: WS-Transfer, like WS-RF, models the projected state explicitly through an XML document accessible via an EPR. However, the only operations defined on that state are, as per the CRUD (create, retrieve, update, and delete) architectural style: create a new resource state representation by supplying a new XML document; get an entire resource state representation; put a new resource state representation to replace an existing one; and delete an existing state representation. Distributed, resource-oriented applications are then built by using these operations to exchange state representations. (3) HTTP Approach: HTTP is an application protocol implementing a resource-oriented approach to building distributed systems. It has been described as an implementation of the REST architectural style. Like WS-RF and WS-Transfer, HTTP implements a resource-oriented approach to building distributed systems. According to REST, a small set of verbs/operations with uniform semantics should be used to build hypermedia applications, with the Web being an example of such an application. The constraints applied through the semantics of these operations aim to allow applications to scale (for example, through caching of state representations). State representations are identified through a URI. HTTP defines simple verbs (such as POST, PUT, GET, DELETE) and headers to enable the implementation of applications according to REST principles. XML is just one of the many media formats that HTTP can handle. (4) No-Conventions Approach: Finally, in the "no conventions for managing state" approach, there are no such concepts as operations, interfaces, classes, state, clients, or servers. Instead, applications are built through the exchange of one-way messages between services. Semantics to the message exchanges (for example, whether a message can be cached or whether a transactional context is included) are added through composable protocols...
The four approaches to modeling state do not differ greatly in terms of what they actually do. All send essentially the same messages, with the same content, across the network. For example, a request to destroy a particular job will in each case be directed to a network endpoint via an HTTP PUT, and will contain the name of the operation to be performed, plus some data indicating the job that should be destroyed. The approaches vary only in how these different components are included in a message, an issue that may have implications for how messages can be processed and routed but that has no impact on how services are implemented.
Working Draft Review Document: Efficient XML Interchange Evaluation
Carine Bournez (ed), W3C Technical Report
Members of W3C's Efficient XML Interchange Working Group have published an updated Working Draft for "Efficient XML Interchange Evaluation." Comments on this document are invited and are to be sent to the public mailing list. This Wg was chartered to develop a format that allows efficient interchange of the XML Information Set, based on the conclusions of the earlier XML Binary Characterization Working Group. This "Efficient XML Interchange Evaluation" document presents the anticipated benefits of the EXI format 1.0 compared to XML and gzipped XML. Additionally, tests for compactness include comparison to ASN.1 PER. The points of comparison are the requirements set by the EXI Working Group charter, based on the results of the XML Binary Characterization Working Group. The summarized evaluation of the EXI format uses the testing framework built during the first phase of the EXI Working Group's work so as to select a baseline candidate technology. Although this evaluation aims at demonstrating EXI benefits in the targeted XBC Use Cases, it can be read as a summary of the EXI measurements Note. The methodology used in the evaluation relies on previous work on measurements. The Properties referred to in this document have been defined by the XBC Working Group. The methodology for measurement is detailed in the XBC measurement methodology document. For convenience, Appendix A gives an overview of the properties definitions, as well as some details of their measurements. In addition, two Properties require an implementation to be evaluated: Compactness and Processing Efficiency. These Properties have been tested using the EXI measurement framework and the associated methodology. At the time of the first publication of this document, the Working Group has not tested conformance of implementations. The methodology and framework designed and implemented on Japex by the Working Group are used for the properties that require implementation testing. The other properties can be asserted by checking the specification only... This test has been run over the EXI Working Group's framework test data, which contains 94 test documents from 21 test groups. The following graphs show the resulting size as a percentage of the original XML document size, sorted by the EXI result, for the sake of legibility (i.e. "best" results on the left). The implementation of EXI used for the measurements is Efficient XML 4.0. It implements the specification of the EXI format 1.0 at the time of writing.
Sun VirtualBox 2.2 Adds Open Virtual Support
Kurt Mackie, Application Development Trends
Sun Microsystems has released VirtualBox 2.2, an update to the company's free and open source desktop virtualization solution. The new release includes a number of performance and feature enhancements, as well as support for the Open Virtualization Format (OVF) specification. OVF is a Distributed Management Task Force (DMTF) standard that enables virtual machines or appliances to be imported and exported. Virtual appliances are one or more virtual machines that are pre-installed and configured so they can be shared, published and distributed. VirtualBox, which, according to Sun, has had more than 11 million downloads and 3.5 million registrations since its launch in 2007, is a cross-platform, open source hypervisor that supports hosts ranging from Mac OS X and Windows to Solaris and 22 varieties of Linux. With its new support for OVF, VirtualBox adds the ability to import and export virtual machines using a graphical user interface or using the command line, allowing for the packaging and distribution of preconfigured virtual appliances. To support these virtual appliances, version 2.2 has a host-only networking mode, which is designed to help multiple virtual machines communicate with one another.... VirtualBox 2.2 is available as of Wednesday as a free download. The following operating systems are supported: Mac OS X; various versions of Linux, both 32- and 64-bit; Windows (32- and 64-bit); and Solaris 10 5/08 and OpenSolaris (32- and 64-bit). From the announcement: "VirtualBox 2.2 software enables users to build virtual machines or appliances and effortlessly export them from a development environment and import them into a production environment. Support for OVF also helps to ensure VirtualBox 2.2 software is interoperable with other technologies that follow the OVF standard. Sun offers a complete desktop-to-datacenter virtualization product and services portfolio, which includes solutions and services for both the management and virtualization of operating systems, servers, storage, networking, desktops and applications. With proven virtualization service expertise, Sun helps customers deploy new services faster, maximize the utilization of system resources, and more easily monitor and manage virtualized environments... Additional features of VirtualBox 2.2 software include: (1) Hypervisor optimizations to make this the fastest VirtualBox release available to date; (2) 3D graphics acceleration for Linux and Solaris applications using OpenGL, allowing a whole new class of applications to run in a virtual machine; (3) Support for Snow Leopard, Apple's forthcoming 64 bit platform; (4) Increased maximum memory size of guests to 16Gb RAM; (5) New host- interface networking mode, which makes it easier than ever before to run server applications in virtual machines..."
See also: the Sun announcement
We Live in Interesting DAM Times
Kas Thomas, CMS TrendWatch Blog
Reportedly, The FeedRoom is implementing the draft OASIS CMIS speification as its primary integration API for digital asset management (DAM) and SaaS applications. According to CMS Watch analyst Kas Thomas: "One of the more noteworthy trends that's emerging that's wise for all to embrace is an understanding that rich-media types (Flash, AVI, MPEG, MP3 and others), because of their growing pervasiveness, need to be treated as 'first-class' content types in the enterprise. This means they need first-class 'content services' supporting them: version control, security, logging, workflow, collaboration services, lifecycle management, and so on. Traditionally, DAM systems have not done these ECM sorts of things well, and so-called ECM tools have been more document-oriented than media-oriented (hence the need for DAM in the first place). It's going to be a while before DM and DAM fuse together (if indeed they ever do). This leads, of course, to discussions around systems integration, something DAM products have been notoriously poor at supporting, and enterprises often don't plan for adequately. That may be starting to change. The FeedRoom, which acquired ClearStory's ActiveMedia last fall and also sells a video aggregation and transformation/transcoding platform called FeedRoom Enterprise Video Platform, have decided to attack the problem by embracing CMIS as its primary integration API. The FeedRoom has already begun to write code that will very shortly be tested by beta customers. The fact that vendors are already writing code against a standard that technically isn't a standard yet (and won't be, until OASIS blesses it around the end of this year) doesn't surprise me—we know of others who are writing code against CMIS already—but what is surprising is that it's a DAM company (not an ECM company that happens to have a DAM product), and The FeedRoom is not one of the original sponsors of CMIS... Content is getting richer and more interactive by the day. The state of the economy doesn't really play a role in this: content gets richer on its own whether you want it to or not. This is driving some important changes in the way people are thinking about content. Metadata matters more; storage (and the ability to remove content as soon as it's no longer needed) matters more. Interoperability between silos matters more. The puzzle pieces are morphing more quickly now. Agility matters. All of this points to a bright future for DAM, near-term as well as medium-term..."
Conference Information Data Model for Centralized Conferencing (XCON)
Oscar Novo, Gonzalo Camarillo, David Morgan (et al., eds) IETF Internet Draft
Members of the IETF Centralized Conferencing (XCON) Working Group have released a new version of the specification "Conference Information Data Model for Centralized Conferencing (XCON)." This WG, part of the IETF Real-time Applications and Infrastructure Area, was chartered to "develop a standardized suite of protocols for tightly-coupled multimedia conferences, where strong security and authorization requirements are integral to the solution. Tightly-coupled conferences have a central point of control and authorization (known as a focus) so they can enforce specific media and membership relationships, and provide an accurate roster of participants." This document defines an Extensible Markup Language (XML)-based conference information data model for centralized conferencing (XCON). A conference information data model is designed to convey information about the conference and about participation in the conference. The conference information data model defined in this document constitutes an extension of the data format specified in the Session Initiation Protocol (SIP) Event Package for Conference State. Document Section 9 presents the Relax NG Schema Registration, and Appendix provides the Non-Normative RELAX NG Schema in XML Syntax.
Overview: " There is a core data set of conference information that is utilized in any conference, independent of the specific conference media. This core data set called the 'conference information data model' is defined in this document using an Extensible Markup Language (XML)-based. The conference information data model defined in this document is logically represented by the conference object. Conference objects are a fundamental concept in Centralized Conferencing, as described in the Centralized Conferencing Framework (RFC 5239). A conference object contains data that represents a conference during each of its various stages (e.g., created/creation, reserved/reservation, active/activation, completed/completion). A conference object can be manipulated using a conference control protocol at a conference server. The conference object represents a particular instantiation of a conference information data model. Consequently, conference objects follow the XML format defined in this document. A conference object contains the core information of a conference (i.e., capabilities, membership, call control signaling, media, etc.) and specifies who, and in which way that information can be manipulated. The Session Initiation Protocol (SIP) Event Package for Conference State, specified in (RFC 4575), already defines a data format for conferences. However, that model is SIP specific and lacks elements related to some of the functionality defined by the Centralized Conferencing Framework (e.g., floor control)... The data model specified in this document is the result of extending the data format defined in (RFC 4575) with new elements. Examples of such extensions include scheduling elements, media control elements, floor control elements, non-SIP URIs, and addition of localization extensions to text elements. This data model can be used by conference servers providing different types of basic conferences. It is expected that this data model can be further extended with new elements in the future in order to implement additional advanced features. A conference object document is an XML document that MUST be well formed and SHOULD be valid...
Make Dashboards with XQuery
James R. Fuller, IBM developerWorks
A "dashboard" is a visual display of important information needed to achieve one or more objectives, consolidated and arranged preferably on a single screen, allowing the information to be comprehended at a glance. Many digital dashboards that cropped up in the 1980s were horrible (if not unsubtle) analogs to a car's dashboard. Very few presented business data in a compelling manner... Some years ago, I worked for a client that generated a broad range of sports-related data feeds. We needed to come up with a way to demonstrate the breadth and depth of the client's data services product and decided to use a scoreboard analogy that could be placed on the client's Web site. The idea was that showing key sports statistics like "football goals scored," "horse races covered," or "number of cricket runs"—all kept current in real time—would have the desired effect and convey the quality of the client's data services to potential customers. After the scorecard was in use, the client's senior management started to ask questions about the figures generated. Initially, these questions revolved around the correctness of our summations, then became more introspective, such as, "We should have more football goals showing" or "Why is the update speed on busy sports days slower than expected?" The various figures that we generated turned out to be effective benchmarks of the quality and overall health of the client's sports- related data feeds. As the scorecard application updated every second or so, it relayed a heartbeat of the company to senior management, who were quick to pick up on any irregularities. Of course, what we had done was nothing new—just a reformulation of the concept of developing a dashboard of KPIs—but it took a marketing initiative to create it...
Using XML technologies like the eXist XML database and XQuery, you can aggregate and consume XML data, then create a HTML representation of a dashboard... The goal of a dashboard is to present KPIs, so it follows that data sources need to be integrated that are either KPIs themselves or contribute to their calculation. Regardless of whether a KPI is qualitative or quantitative in nature, all KPIs need to say something useful about the running of the business... I built the example dashboard to demonstrate how to use XQuery first rather than to create something speedy or highly reusable... With three straightforward XQuery files, you can implement a Web dashboard that shows the power of XQuery and XML databases to aggregate and present data...
See also: W3C XML Query (XQuery)
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/