This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com
- Oracle Updates Family of Open Source Berkeley DB Embeddable Databases
- Extensible Messaging and Presence Protocol (XMPP): Core
- Authoring Applications for the Multimodal Architecture
- Context Dependent Revocation in Delegated XACML
- Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG): Overview
- Fusion Middleware Roadmap
- XRX: XQueries in eXist
- BASE: An ACID Alternative
- Understanding XML: Thoughts on Agile Schema Development
Oracle Updates Family of Open Source Berkeley DB Embeddable Databases
Staff, Oracle Announcement
Oracle has announced new releases of Oracle Berkeley DB, Oracle Berkeley DB XML, and Oracle Berkeley DB Java Edition. The new releases and enhancements signify Oracle's commitment to continued innovation across the Oracle Berkeley DB product family, while maintaining the open source dual license business model. All three members of the Oracle Berkeley DB family are designed for high performance, reliability and embeddability within applications that have predictable data access patterns and therefore do not require a query language like SQL. For these applications, SQL is often unnecessary and may slow the overall performance. The software libraries directly linked into the application, eliminating the performance penalty of client-server architectures. Oracle Berkeley DB Release 4.7 now provides improved caching efficiency, faster database recovery, a cycling master feature for replicated (HA) environments, support for the Java Direct Persistence Layer (DPL) API, and QNX RTOS support Oracle Berkeley DB XML is an open source, embeddable XML database with XQuery-based access to documents stored in containers and indexed based on their content. Oracle Berkeley DB XML is built on top of Oracle Berkeley DB and inherits its rich features and attributes. Like Oracle Berkeley DB, it runs in process with the application with no need for human administration. Oracle Berkeley DB XML Release 2.4 offers support for XQuery update, cost-based query optimization for significantly improved performance and XQilla for XQuery processing. XQilla is an XQuery and XPath 2 library and command line utility written in C++, implemented on top of the Xerces-C library; it is made available under the terms of the Apache License v2. Oracle Berkeley DB Java Edition Release 3.3 provides improved scalability, caching improvements, more efficient in-memory and on disk storage, support for Google Android and Apache Maven.
See also: Oracle Berkeley DB
Extensible Messaging and Presence Protocol (XMPP): Core
Peter Saint-Andre (ed), IETF Internet Draft
Peter Saint-Andre of the XMPP Standards Foundation has published an updated Internet Draft for the revision of XMPP, "Extensible Messaging and Presence Protocol (XMPP): Core." This specification, when complete, would obsolete RFC 3920. IETF RFC 3920 was published in October 2004. As a result of extensive implementation and deployment experience with XMPP since 2004, as well as more formal interoperability testing carried out under the auspices of the XMPP Standards Foundation (XSF), this document reflects consensus from the XMPP developer community regarding XMPP's core XML streaming technology. In particular, this document incorporates a number of backward-compatible changes from RFC 3920. The Extensible Messaging and Presence Protocol (XMPP) is an open XML technology for real-time communication, which powers a wide range of applications including instant messaging, presence, media session management, shared editing, whiteboarding, collaboration, lightweight middleware, content syndication, and generalized XML routing. XMPP is typically used to exchange messages, share presence information, and engage in structured request-response interactions. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. The purpose of XMPP is to enable the exchange of relatively small pieces of structured data (called "XML stanzas") over a network between any two (or more) entities. XMPP is implemented using a client-server architecture, wherein a client must connect to a server in order to gain access to the network and thus be allowed to exchange XML stanzas with other entities (which may be associated with other servers). The basic syntax and semantics of XMPP were developed originally within the Jabber open-source community, mainly in 1999. In late 2002, the XMPP Working Group was chartered with developing an adaptation of the core Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology.
Authoring Applications for the Multimodal Architecture
Ingmar Kliche (ed), W3C Working Group Note
W3C has published an initial public draft of "Authoring Applications for the Multimodal Architecture." The document was produced by members of the Multimodal Interaction Working Group as part of the W3C Multimodal Interaction Activity. The W3C Multimodal Interaction (MMI) Working Group develops an architecture for the Multimodal Interaction framework. The Multimodal Architecture describes a general and flexible framework for interoperability of the various components of the multimodal framework (e.g. modality components and the interaction manager) in an abstract way. Among others it defines interfaces and messages between the constituents of the framework, but it is up to the implementation to decide how these messages are transferred in case of a distributed implementation. The intention of this document is to provide a proposal of how to implement a multimodal runtime environment as well as an application based on the W3C Multimodal Architecture using existing W3C technologies. This proposal uses CCXML and VoiceXML to implement a voice modality component. Note that this is just one possibility for implementing it. In particular, the document discusses a distributed implementation of the multimodal framework using the following components and technologies: (1) Interaction Manager (IM) based on a state machine, described using "State Chart XML (SCXML): State Machine Notation for Control Abstraction"; (2) GUI Modality component based on XHTML and ECMAScript; (3) Voice Modality component based on VoiceXML and "Voice Browser Call Control: CCXML Version 1.0"; (4) Modality component API based on HTTP (event transport) and XML (event representation). The Runtime Framework [one implementation proposal] provides the environment which hosts the SCXML interpreter. It has to provide an interface to receive events from external components (modality components) and must be able to inject these events into an existing SCXML session or to start SCXML interpreter sessions. The Runtime Framework also needs to provide the possibility to send events to external components (i.e. some implementation of the SCXML 'send' tag). Note: The W3C Voice Browser Working Group is currently developing VoiceXML 3.0 which is the next major release of VoiceXML and will enable voice browsers to fit into the W3C Multimodal Architecture as a modality component. As VoiceXML 3.0 implementations are not yet available, this document relies on the existing VoiceXML 2.1 specification.
See also: the W3C Multimodal Interaction Activity
Context Dependent Revocation in Delegated XACML
Erik Rissanen and Ludwig Seitz (eds), SICS Technical Report
"The XACML standard defines an XML based language for defining access control policies and a related processing model. Recent work aims to add delegation to XACML in order to express the right to administrate XACML policies within XACML itself. The delegation profile draft explains how to validate the right to issue a policy, but there are no provisions for removing a policy. This paper proposes a revocation model for delegated XACML. A novel feature of this model is that whether a revocation is valid or not, depends not only on who issued the revocation, but also on the context in which an attempt to use the revoked policy is done... Informally, in our model someone with the authority to support a policy, either directly or indirectly, can also revoke it. The motivation for choosing this model is that in many cases it is natural for the right to issue and revoke to go together. Also, being able to indirectly support a policy implies authority over the policy, so it is not far fetched to allow for revocation of indirectly supported policies. An alternative would be to only allow to revoke policies which are directly supported, which has the benefit that such a model is not NP-complete. Note however, that since our revocations cascade, revoking a directly supported policy also invalidates indirectly supported policies... The model could be summarized as 'You may revoke those policies which you could create yourself'. The use case is that administrators may change positions, in which case each administrator should be able to handle those policies which are his duties, whether they were issued by him in person, or someone else. This is in contrast to the more typical revocation model, for instance in X.509 PKI, where the issuer of something is the authority of revocation. In the model we wanted the already existing administrative policies also to define the scope of rights to revoke policies in addition to the scope of rights to issue policies... The central novel feature of our model, which is not captured by any of the characteristics described [in Hagstroem, Barka and Sandhu, Sadighi] , is that the effect of a revocation depends on which access request is being processed. We call this characteristics context dependency. A revocation which is context independent will have the same effect on a permission regardless for what the permission is used. We are not aware of any other access control model which has context dependent revocation
Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG): Overview
Alan Chuter and Yeliz Yesilada, W3C Technical Report
A Second Public Working Draft has been released by W3C describing the "Relationship between Mobile Web Best Practices (MWBP) and Web Content Accessibility Guidelines (WCAG)." The overview was produced jointly by the Mobile Web Best Practices Working Group and the Education & Outreach Working Group (EOWG) of the Web Accessibility Initiative (WAI). The technical report was created as a supporting document to WCAG and MWBP, but does not replace either of those. The document includes five subpages that describe the relationship between each version of WCAG and MWBP 1.0... With global mobile phone use at an all time high, there has been a surge of interest in developing Web sites that are accessible from a mobile device. Similarly, making Web sites accessible for people with disabilities is an integral part of high quality Web sites, and in some cases a legal requirement. Most Mobile Web specialists don't know about design issues for people with disabilities. Likewise, most Web accessibility specialists don't know Mobile Web design best practices. Web sites can more efficiently meet both goals when developers understand the significant overlap between making a Web site accessible for a mobile device and for people with disabilities. Users of mobile devices and people with disabilities experience similar barriers when interacting with Web content. For example, mobile phone users will have a hard time if a Web site's navigation requires the use of a mouse because they typically only have an alphanumeric keypad. Similarly, desktop computer users with a motor disability will have a hard time using a Web site if they can't use a mouse. Additionally, people with disabilities may use a mobile device to access the Web site.
Fusion Middleware Roadmap
Antony Reynolds, Blog
I spent last week in Redwood Shores listening to product development outline their plans and directions for Fusion Middleware in the light of the BEA acquisition. Today we made those plans public through a webcast hosted by Charles Phillips and Thomas Kurian... I think the decision to promote the AquaLogic Server Bus into the Oracle SOA Suite as the preferred ESB is again the right decision. Personally this is causing me a lot of problems because I am in the midst of writing a book about the SOA Suite and now I have to revise it to use the Oracle Service Bus (nee ALSB) rather than the old Oracle ESB. Over the last few months as I have looked into the BEA product set I have been surprised how complementary much of the technology actually is. For example one area where Oracle has been weak in product is around the governance space. This area will receive a big boost from the Oracle Enterprise Repository. The area of Business Process Management is an interesting one, because in the past we have pushed BPEL—which is really a service orchestration engine—as a BPM tool. The addition of BPEL to ALBPM in the BPM Suite will strengthen the ALBPM story and at the same time continue to allow BPEL to be used as a service orchestration engine in the SOA Suite. In the longer term the plan to converge the two products into a single run time will be worth watching. So all told, I am happy about the stated product directions. They all seem to drive towards Thomas' goal of a single, complete and integrated middleware suite. The next couple of years may be a bit bumpy as we smooth out the differences between the two product sets, but even today I think we have a cracking offering...
See also: BPEL references
XRX: XQueries in eXist
Jeni Tennison, O'Reilly Blog
I want to explore the XRX (XForms, REST, XQuery) architecture, so I've set myself the challenge of implementing a social bookmarking web service modelled on del.icio.us as described in Chapter 7 of Leonard Richardson's and Sam Ruby's "RESTful Web Services", using Orbeon Forms and eXist. This is the first post in a series that will look at how the implementation works, and any problems I run into along the way. In this post, I'll be looking at setting up eXist with some basic data and queries that will support the rest of the application. eXist is an open-source native XML database; you might want something a bit more heavy-weight if you're looking to do this with enterprise-level quantities of content, but eXist has the basic capabilities that you'd expect from an XML database and is more than sufficient for exploring the XRX principles. eXist comes bundled with Orbeon; you can download the latest standalone version but the URLs that I'll be referencing here are all based on the bundled version.
BASE: An ACID Alternative
Dan Pritchett, ACM Queue
In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability. Web applications have grown in popularity over the past decade. Whether you are building an application for end users or application developers (i.e., services), your hope is most likely that your application will find broad adoption -- and with broad adoption will come transactional growth. If your application relies upon persistence, then data storage will probably become your bottleneck. There are two strategies for scaling any application. The first, and by far the easiest, is vertical scaling: moving the application to larger computers. Horizontal scaling offers more flexibility but is also considerably more complex. Horizontal data scaling can be performed along two vectors. Functional scaling involves grouping data by function and spreading functional groups across databases. Eric Brewer, a professor at the University of California, Berkeley, and cofounder and chief scientist at Inktomi, made the conjecture that Web services cannot ensure all three of the following properties at once (signified by the acronym CAP): Consistency, Availability, Partition tolerance. Specifically, a Web application can support, at most, only two of these properties with any database design... ACID database transactions greatly simplify the job of the application developer. If ACID provides the consistency choice for partitioned databases, then how do you achieve availability instead? One answer is BASE (basically available, soft state, eventually consistent). BASE is diametrically opposed to ACID. Where ACID is pessimistic and forces consistency at the end of every operation, BASE is optimistic and accepts that the database consistency will be in a state of flux. Although this sounds impossible to cope with, in reality it is quite manageable and leads to levels of scalability that cannot be obtained with ACID... EDA (event-driven architecture) can provide dramatic improvements in scalability and architectural decoupling... Scaling systems to dramatic transaction rates requires a new way of thinking about managing resources. The traditional transactional models are problematic when loads need to be spread across a large number of components. Decoupling the operations and performing them in turn provides for improved availability and scale at the cost of consistency. BASE provides a model for thinking about this decoupling.
Understanding XML: Thoughts on Agile Schema Development
Kurt Cagle, O'Reilly Blog
Much of this article is inspired by a panel discussion that I had with a number of experts in XML document management systems at the MarkLogic conference, moderated by Marc Strohlein, Chief Agility Officer for Outsell. Dave Kellogg, CEO of MarkLogic, has some excellent coverage of the panel in his well read (and respected) blog. A question asked by one of the audience, Mira Bossowska of Cengage Learning Technology Services afterwards led to a discussion about whether in fact you could work with XML Schema design in an agile fashion, given the interdependencies that so many process have upon such a schema, which in turn led to this particular article. In truth, XML Schema design (and general data modeling, for that matter) benefit strongly from Agile methodologies, but it needs to be understood that whereas the end point of agile development for imperative code is a working (and dynamically adaptable application), the end point for declarative schema development is ultimately a solid data model first and foremost. Indeed, I think that this is one of the fundamental differences that XML development has from most other forms of computer programming; in "traditional agile", the design phase is something that tends to be subsumed into the development—indeed, the idea of designing too deeply at the outset of development is a major no-no in agile programming, since in essence one of the tenets of agile development is that the design process is an evolutionary one that runs in tandem with application creation. With XML, however, what you are in fact creating is an expression of a data model -- that is the target, which means that the XML developer in fact spends an inordinate amount (perhaps the entire) part of the development cycle in the design phase..."
XML Daily Newslink and Cover Pages sponsored by:
|Sun Microsystems, Inc.||http://sun.com|
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter Archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: firstname.lastname@example.org
Newsletter unsubscribe: email@example.com
Newsletter help: firstname.lastname@example.org
Cover Pages: http://xml.coverpages.org/