This issue of XML Daily Newslink is sponsored by:
Oracle Corporation http://www.oracle.com
- Tech Road Map: Enterprise Key Management Infrastructure (EKMI)
- Google Announces Improved Flash Indexing
- WS-Reliable Messaging with WSO2 WSAS Version 1
- New OpenOffice.org ODF Validation Service
- REST Anti-Patterns
- Will XML Schema 1.1 Solve the Problem?
- Oracle Reveals BEA Roadmap
Tech Road Map: Enterprise Key Management Infrastructure (EKMI)
David Brown, InformationWeek
Information security pros do put stock in encryption — it was named the third-most-effective security practice in our most recent Strategic Security Survey, behind only firewalls and antivirus products. However, there have been obstacles along the path to ubiquitous encryption of data, including weak ciphers, deployment and integration issues, and, perhaps most notably, key management. Public key infrastructure, or PKI, systems alone have simply failed to address the challenge of keeping encryption keys in order. Enter the Enterprise Key Management Infrastructure initiative, a promising program spearheaded by the OASIS consortium, with organizations including CA, Red Hat, the U.S. Department of Defense, and Wells Fargo represented on the technical committee. The objective with EKMI is to create open standards for the interaction of various platforms, applications, and technologies that would benefit from the security of symmetric encryption with a central key management system, referred to as the Symmetric Key Management System, or SKMS. Combine SKMS with PKI—for strong authentication, message integrity, and key encryption; client software that includes an API designed to interact with Java-based applications, such as Web apps or middleware systems; and an XML-based protocol for communication between client and server—and EKMI becomes a single platform for managing what has, to this point, been a morass of cryptographic key management functions... EKMI holds a great deal of promise to solve these problems by combining essential elements into a holistic key management system. Creating a single interaction point for provisioning, escrow, recovery, caching, and destruction of symmetric keys will provide greater scalability to encryption deployments. If accepted and adopted, the standards would create a management platform that is independent of the technology applying the encryption, yet centralized in nature. Use of existing PKI systems for more extensive protection and establishing a single audit point for key management transactions are very attractive benefits of EKMI.
Google Announces Improved Flash Indexing
Ron Adler and Janis Stipins, Google Announcement
"We've received numerous requests to improve our indexing of Adobe Flash files... We've now improved our ability to index textual content in SWF files of all kinds. This includes Flash "gadgets" such as buttons or menus, self-contained Flash websites, and everything in between. All of the text that users can see as they interact with your Flash file. If your website contains Flash, the textual content in your Flash files can be used when Google generates a snippet for your website. Also, the words that appear in your Flash files can be used to match query terms in Google searches. In addition to finding and indexing the textual content in Flash files, we're also discovering URLs that appear in Flash files, and feeding them into our crawling pipeline—just like we do with URLs that appear in non-Flash webpages. For example, if your Flash application contains links to pages inside your website, Google may now be better able to discover and crawl more of your website." Adobe's Ryan Stewart clarifies: First off, yes, Google has always been able to index Flash content—sort of. They could scrape some text by introspecting the SWF file and pull some meaningful data from it. But that's about it. This new player behaves much more like a human player. It allows Google's spiders to click on links, move through states of an application, detect when the URLs change, and everything else a 'normal' Flash Player can do. So instead of grabbing text, it's grabbing text and context for the application. In theory, Google will know that clicking on a button changes the URL or loads a new state and then loads some new text. Before we never had that. There was no context for what Google was seeing because the spiders didn't understand what was going on inside of the Flash movie to make the state changes happen. So how do you get your Flash site to the top of Google? No one knows. That's the same thing as asking how you get your HTML site to the top of Google. No one knows. There are tricks and theories, but Google changes the algorithm and evolves it's index. The point is that now Flash/Flex applications will have the same kind of context that Ajax applications do according to Google. So we're subject to the same rules and every Flash and Flex developer should start figuring out how Google treats Flash content. That's not something they're going to tell Adobe. Details from Adobe are presented in the announcement "Adobe Flash Technology Enhances Search Results for Dynamic Content and Rich Internet Applications."
WS-Reliable Messaging with WSO2 WSAS Version 1
Charitha Kankanamge, Blog
Web services are an essential component of distributed computing. Reliable communication between services and service consumers should be taken in to account when designing SOA based systems. WS-Reliability is a SOAP-based specification that fulfills reliable messaging requirements critical to web service applications. I'm going to demonstrate the simplest RM scenario, one-way single channel invocation using WSO2 mercury, which is an implementation of WS-RM using Apache Axis2. WSO2 mercury is shipped as a module with WSO2 web services application server version 2.3 (WSO2 WSAS-2.3) as well as a separate piece of product. I'm going to describe the scenario using WSO2 WSAS, however you may also follow the given steps with Axis2-1.4 . We are going to send a set of ping messages (one-way messages) to a web service in reliable manner. In other words, we send a set of requests to a service and block the channel at the middle of message transmission. Then we restart the transport channel. If WS-RM is not enabled, the message transmission will be lost when the transport channel goes down. You have to re-send messages. However, if our service and client are configured to use Wso2 mercury (WS-RM implementation), it will take care of guaranteed delivery of the rest of the messages when the transport channel is back again... [Note: WSO2 Mercury is a WS-ReliableMessaging specification implementation that uses Apache Axis2/Java as the SOAP engine. Additionally Mercury implements the Replay model to support anonymous client invocations. WSO2 Mercury is a component of WSO2 Commons project and is released under Apache License v2.0.]
See also: Reliable Messaging specifications
New OpenOffice.org ODF Validation Service
Michael Brauer, Blog
A new service is provided by Sun Microsystems, Inc: "I would like to announce the availability of a new ODF Validation service at openoffice.org. What is it? It is actually a web page where you can check whether an ODF file meets some basic conformance or validation requirements defined by the ODF specification. This service is in particular useful for developers that want to test their implementations, but it may also be used to check if a particular file is a valid ODF file. Actually, this service has its roots in a validation tool that I have developed some time ago to help Sun's OpenOffice.org engineers to test OpenOffice's ODF implementation. However, the service and its underlying tool are in no way restricted to this, and in particular not restricted to validate documents created by OpenOffice.org. The validation service supports multiple modes. In the conformance test mode it is checked whether the individual streams of the ODF document, like content.xml or styles.xml, are valid with respect to the OpenDocument schema after the pre-processing of foreign elements and attributes described in section 1.5 of the OpenDocument specification has been applied. This comes very close to a conformance test for ODF documents, but not all provisions for conforming documents are checked. The validation mode is like the conformance mode, except that the pre-processing of foreign elements and attributes is omitted. Which means that a document only passes this test if it does not contain any elements or attributes not defined by ODF. The only exception are elements and attributes in the meta data and formatting properties, because the ODF schema allows arbitrary elements and attributes to appear here. The third mode is the strict validation mode. In this mode, the streams are validated with respect to the strict variants of the ODF schema. The difference to the regular schemas is that meta data and formatting properties are restricted to those elements and attributes that ODF itself defines. This mode is useful if you want to check that a document contains only elements and attributes that ODF defines, but no extensions..." Background information is available via the ODF Validator Info Page explaining options and implementation details; also Sun Multi-Schema XML Validator (MSV).
See also: the OpenOffice.org ODF Validator
Stefan Tilkov, InfoQueue
When people start trying out REST, they usually start looking around for examples—and not only find a lot of examples that claim to be 'RESTful', or are labeled as a 'REST API', but also dig up a lot of discussions about why a specific service that claims to do REST actually fails to do so. Why does this happen? HTTP is nothing new, but it has been applied in a wide variety of ways. Some of them were in line with the ideas the Web's designers had in mind, but many were not. Applying REST principles to your HTTP applications, whether you build them for human consumption, for use by another program, or both, means that you do the exact opposite: You try to use the Web 'correctly', or if you object to the idea that one is 'right' and one is 'wrong': in a RESTful way. For many, this is indeed a very new approach. The usual standard disclaimer applies: REST, the Web, and HTTP are not the same thing; REST could be implemented with many different technologies, and HTTP is just one concrete architecture that happens to follow the REST architectural style. So I should actually be careful to distinguish 'REST' from 'RESTful HTTP'. I'm not, so let's just assume the two are the same for the remainder of this article. As with any new approach, it helps to be aware of some common patterns. In the first two articles of this series, I've tried to outline some basic ones—such as the concept of collection resources, the mapping of calculation results to resources in their own right, or the use of syndication to model events. A future article will expand on these and other patterns. For this one, though, I want to focus on anti-patterns—typical examples of attempted RESTful HTTP usage that create problems and show that someone has attempted, but failed, to adopt REST ideas. Let's start with a quick list of anti-patterns I've managed to come up with: (1) Tunneling everything through GET; (2) Tunneling everything through POST; (3) Ignoring caching; (4) Ignoring response codes; (5) Misusing cookies; (6) Forgetting hypermedia; (7) Ignoring MIME types; (8) Breaking self-descriptiveness. Let's go through each of them in detail...
Will XML Schema 1.1 Solve the Problem?
Michael Kay, XTech 2008 Presentation
W3C issued a last call review for the 2-part "W3C XML Schema Definition Language (XSD) 1.1" specification [Part 1, Strutures; Part 2, Datatypes], ending 12-September-2008. At XTech 2008, Michael Kay (Saxonica Limited) provided an overview of changes in XSD 1.1 which may solve some of the pain points: "XML Schema is in an odd position: everyone is using it, but no-one really likes it. It's clearly fit for purpose, or people wouldn't be using it; but it attracts complaints both because of its immense complexity and because there are basic features that it doesn't provide. Version 1.1 in on the way: this talk surveys the new features and tries to assess whether they will solve the problem... The paper starts with an assessment of XML Schema 1.0. What do people want from the technology, and is it meeting their requirements? Clearly it must be doing something useful, because it has been so widely adopted. It hasn't suffered the fate of some standards of being ignored. But at the same time it's widely criticized on two almost contradictory grounds: it's an immensely complex specification, and yet at the same time it often fails to provide the basic features that users are looking for. We take a quick look at the original design objectives for XML Schema, but concentrate our attention on what people actually want from it today (the differences are instructive). There are basically two applications for XML Schema today: validation of instances, and definition of data types for XML processing, whether by use of data binding to languages such as C++ and Java, or as the type system that underpins XQuery 1.0 and XSLT 2.0. We'll examine where the specification lets these user communities down in terms of not providing the features they need. We then provide a quick tour of the new features of the 1.1 specification, some of which are impressive: assertions, conditional type assignment, open content models, interleave structures, and more."
Oracle Reveals BEA Roadmap
Paul Krill, InfoWorld
Oracle has provided a comprehensive roadmap for its recently acquired BEA Systems middleware technologies, making BEA's application server Oracle's strategic Java container and pledging continued support for BEA customers. In a 105-minute Web conference, Oracle President Charles Phillips and, primarily, Oracle Fusion Middleware Senior Vice President Thomas Kurian covered product plans in the SOA, development tools, identity management and other middleware spaces. Oracle closed its $8.5 billion merger with BEA in late-April. Phillips cited SOA synergies and said Oracle, with BEA in tow, becomes number one in the middleware market. Oracle's plan categorizes BEA products into three areas. Strategic products, which will be adopted immediately with limited re-design into the Oracle Fusion Middleware platform. Continue and converge products, which are BEA products being incrementally re-designed to integrate with Fusion Middleware. These products will continue to be developed and maintained for at least nine years. Maintenance products, which BEA had put on an end-of-life status and will get continued maintenance for five years. One example is BEA's Beehive applications framework. Perhaps the biggest—but most expected—revelation was in the application server arena. The BEA Weblogic Server Java application server "becomes Oracle's strategic J2EE container," Kurian said. It has been integrated with Oracle technologies like Oracle TopLink for Java persistence and Oracle Coherence grid capabilities. Application server modernization plans call for modularization based on the OSGi standard. However, Oracle's own application server continues development going forward. SOA plans call for integrating the Oracle ESB with BEA Aqualogic Service Bus. This provides a best-of-breed offering for customers, said Kurian. Also, the former BEA Aqualogic Enterprise Repository becomes Oracle's SOA governance repository; with it, SOA artifacts can captured shared and change-managed across the lifecycle... [And Bruce Silver provides analysis:] " Oracle says ALBPM will be integrated with the BPEL metamodel for round trip design, and 'process documentation' will be available via BPA Suite. How much of that is hobbling ALBPM and how much enhancing BPEL remains to be seen. All of this means there is finally a product named 'Oracle BPM Suite.' It includes: (1) Oracle BPM Studio (ALBPM Studio, BPEL Designer); (2) Oracle BPEL Process Manager - runtime; (3) Oracle Business Rules; (4) Oracle Business Activity Monitoring; (5) Restricted use of Oracle WebCenter Suite, for Process Portal..." Bruce Silver's commentary "Oracle Unveils Plans for BEA" is available through Intelligent Enterprise "Bruce Silver's BPMS Watch" or at his blog.
See also: Bruce Silver's commentary
John Fronckowiak, IBM developerWorks
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: email@example.com
Newsletter unsubscribe: firstname.lastname@example.org
Newsletter help: email@example.com
Cover Pages: http://xml.coverpages.org/