This issue of XML Daily Newslink is sponsored by:
IBM Corporation http://www.ibm.com
Turn Your Existing Systems Into an SOA Platform Using Apache Synapse
Rajith Attapattu and Paul Fremantle, IBM developerWorks
If you're planning to transform your existing middleware into a Service-Oriented Architecture (SOA) platform, consider using Apache Synapse. Apache Synapse, a simple, high-quality open source alternative, provides an approach to SOA that can expose existing applications without rewriting any code. This article gives you a thorough introduction to Apache Synapse and provides a use case to demonstrate how you can integrate and reuse existing applications using an SOA approach. The ability to reuse, integrate, manage, and control interactions with your existing applications without changing them makes Synapse an attractive choice and a key approach to an SOA strategy. The ESB concept is, unfortunately, poorly defined. However, we have a simple, pragmatic definition: Connect, transform, manage. The ESB model promotes SOA-based integration with service contracts and metadata associated with the service contracts, such as Web Services Description Language (WSDL), schema, or policy. The ESB model ensures that every message that goes into the bus ends up in the right place. Synapse is built around XML and Web services standards. Fundamentally, Synapse is based around the idea of messages moving around a network. The messages can be any format, but Synapse molds them into a logical infoset modeled on the SOAP idea of an envelope containing header and body. By using Web services standards, such as WS-ReliableMessaging and WS-Security, you can use Synapse to enable secure, reliable connections between applications. Synapse can offload these types of quality-of-service (QoS) capabilities without modifying existing applications. For example, by placing a Synapse instance directly in front of an existing XML/HTTP service, you can add support for WS-Security. This can add support for digital signatures, which can be important in a B2B environment.
See also: Apache Synapse
SPARQL Query Language for RDF
Eric Prud'hommeaux and Andy Seaborne (eds), W3C Technical Report
W3C has announced the advancement of "SPARQL Query Language for RDF" to the status of Candidate Recommendation. Implementation feedback is invited through 12-August-2007. RDF is a directed, labeled graph data format for representing information in the Web. The specification defines the syntax and semantics of the SPARQL query language for RDF. SPARQL can be used to express queries across diverse data sources, whether the data is stored natively as RDF or viewed as RDF via middleware. SPARQL contains capabilities for querying required and optional graph patterns along with their conjunctions and disjunctions. SPARQL also supports extensible value testing and constraining queries by source RDF graph. The results of SPARQL queries can be results sets or RDF graphs. With SPARQL (pronounced "sparkle"), developers and end users can consume search results across a wide range of information such as personal, technical, business or scientific data, social networks, or data about digital artifacts like music and images. The SPARQL query language is based on matching graph patterns. Graph patterns contain triple patterns. Triple patterns are like RDF triples, but with the option of a query variables in place of RDF terms in the subject, predicate or object positions. Combining triple patterns gives a basic graph pattern, where an exact match to a graph is needed. A related document "SPARQL Query Results XML Format" is a Last Call Working Draft with comments welcome through 5-July-2007.
See also: W3C Semantic Web
Web Structured, Schema'd and Searchable (Web3S)
Staff, Microsoft Corporation
The purpose of this document is to define a protocol that is a good fit for Live Contacts. Live Contacts is the central data store in Windows Live for address book information. All Hotmail contacts, Messenger buddies and Spaces' friends are recorded in Live Contacts. There are currently approximately 500,000,000 active address books in Live Contacts. The key issues that Live Contacts faces in terms of designing a protocol to let third parties access it are Simplicity, Cost of Read/Writes, and Versioning. (1) Simplicity: The target audience for Web3S are web developers and their code runs in a dizzying array of operating systems, application execution environments, programming languages, tool kits, etc. Many of these environments are completely custom so we can't just hand out sample code for all of them. This means that many people wanting to interact with us will have to build their own libraries to do so from scratch. As such it is critical that our protocol be as simple as possible. We have therefore chosen to take a straight forward HTTP approach where our resources are all URI addressable and use the standard RFC 2616 methods (DELETE/GET/PUT/POST). We have introduced, however, a new method—UPDATE. This method was introduced to deal with a specific issue that comes up with some of the more complex schemas. We have also defined a very simple data infoset that can be easily serialized into/out of XML and JSON. We feel that there are important communities that want to interact with us via both XML and JSON so we wanted a system simple enough to properly support both. (2) Cost of Read/Writes: every value in an address book is individually addressable with a URL using a path language; we specify the use of merge semantics which enables write requests to only specify values that need to be changed. (3) Versining: all clients implement an ignore rule—that is, clients must ignore data they don't recognize; this means that when new values are added older clients won't see them and thus not break...
See also: Yaron Goland's blog
NIEM 2.0: Information Exchange Model at the Next Level
Joab Jackson, Government Computer News
The National Information Exchange Model (NIEM) has gotten its first upgrade. Version 2 should be released by the end of this month, and the final beta is available on the NIEM site. The large Extensible Markup Language (XML) schema, overseen by the Homeland Security and Justice departments, provides a common language for federal, state and local agencies to share information on natural disasters, terrorist attacks and other crises. Each piece of agency data is tagged by a particular NIEM name so it can easily be identified by systems outside the one where it originated. The first production version of NIEM appeared in June 2006. It used Justice's Global Justice XML Data Model as the foundation, but is being expanded to cover other common items relating to criminal justice and law enforcement. Perhaps the major area of change is the unification of namespaces, a term applied to collections of tags. The first version of NIEM had two main namespaces, Universal and Common. Universal components were items that would be common to all parties using NIEM. Common components were items that existed in more than one domain... The specification is already being used in some law enforcement efforts, such as the National Data Exchange project, an electronic catalog of criminal information currently being developed by the FBI.
See also: the NIEM Web site
Ajax for JSF: Seam Remoting and Ajax4jsf Fuse Client and Server
Dan Allen, IBM developerWorks
XML Daily Newslink and Cover Pages are sponsored by:
|BEA Systems, Inc.||http://www.bea.com|
|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/