|
XML and Web Services In The News - 05 May 2006
Provided by OASIS |
Edited by Robin Cover
This issue of XML.org Daily Newslink is sponsored by SAP
HEADLINES:
Microsoft Office to Get A Dose of OpenDocument
Martin LaMonica, CNET News.com
A group of developers has written software to convert documents from
Microsoft Office into the OpenDocument format, a feature Microsoft
said it will not provide in Office 2007. The plug-in lets customers
use Microsoft products in tandem with OpenDocument formats. But long
term term, any broad adoption of the document standard will lessen
customers' reliance on Microsoft products. Gary Edwards, an engineer
involved in the open-source OpenOffice.org project and founder of the
OpenDocument Foundation, on Thursday discussed the software plug-in
on the Web site Groklaw. The new program, which has been under
development for about year and finished initial testing last week,
is designed to let Microsoft Office manipulate OpenDocument format
(ODF) files, Edwards said: "The ODF Plugin installs on the file menu
as a natural and transparent part of the 'open,' 'save,' and 'save as'
sequences. As far as end users and other application add-ons are
concerned, ODF Plugin renders ODF documents as if (they) were native
to MS Office." In a related development, the commonwealth of
Massachusetts, a highly visible example of OpenDocument's momentum,
on Wednesday publicly stated the need for an ODF Office plug-in.
On the Massachusetts' procurement Web site, it issued a request for
information (RFI) for a "plug-in component or other converter options
to be used with Microsoft Office that would allow Microsoft Office to
easily open, render and save to ODF files."
See also: the MA Commonwealth RFI text
Apache WSS4J 1.5.0 Web Service Security Implementation for SOA Released
WSS4J Team, Project Announcement
The WSS4J Team development team announced the version 1.5.0 release of
Apache WSS4J, a Web service security implementation. Apache WSS4J is
an implementation of the OASIS Web Services Security (WS-Security)
from OASIS Web Services Security TC. WSS4J is a primarily a Java
library that can be used to sign and verify SOAP Messages with
WS-Security information. WSS4J will use Apache Axis and Apache
XML-Security projects and will be interoperable with JAX-RPC based
server/clients and .NET server/clients. WSS4J implements (1) OASIS Web
Serives Security: SOAP Message Security 1.0 Standard 200401, March 2004;
(2) Username Token profile V1.0; (3) X.509 Token Profile V1.0. As to
WS-Security features, WSS4J can generate and process the following
SOAP Bindings: (a) XML Security [XML Signature and XML Encryption; (b)
Tokens [Username Tokens, Timestamps, SAML Tokens] WSS4J supports X.509
binary certificates and certificate paths.
See also: XML Security Standards
Java to get Linux Boost: Sun, Others Talk Up New Enterprise Version of
Programming Language
Paul Krill, InfoWorld
Sun officials conducted a teleconference at Sun offices to unveil
Java EE 5, which was approved by the Java Community Process this week.
The unveiling of Java EE 5 serves as a curtain-raiser for the JavaOne
conference, which begins in San Francisco on May 16. "This is a very
significant upgrade to the enterprise Java platform," said Joe Keller,
vice president of marketing for SOA and Integration Platforms at Sun.
Java EE features simplified programming, especially for Web services,
the Web tier, and transactional components, Keller said. Key
improvements include adherence to the Enterprise JavaBeans 3
specification, for programming of "plain old Java objects," and also
backing for JavaServer Faces (JSF) 1.2, for simplified Web development.
JSF support gives Java EE 5 a Web 2.0 bent, enabling development of
applications via AJAX (Asynchronous JavaScript and XML), according to
Sun. The event brought together representatives of companies often at
odds with one another -- Sun, Oracle, SAP, JBoss, and BEA Systems --
in support of Java EE 5. According to SAP's Aiaz Kazi: "The very fact
that you have on this call people from SAP, Oracle, JBoss, and BEA all
standing behind this announcement should go to show this is very
critical for the role of enterprise SOA; SAP has provided Java
capabilities through its stack; Interoperability and being able to
use standards is key to being able to build and run smoothly your
business applications across your heterogeneous systems within an
enterprise SOA."
Point of View for WSRP Compliant Portal Technologies
A. Saurav Das, A. Pal Chaudhuri, M. Chawla, SearchWebServices.com
Broadly, portals are regarded as one-point access to all applications
a consume needs. Often, a portal is aggregation of pluggable UI
fragments called portlets. Portlets are interactive Web applications
that aggregate data from local or remote applications/services and
displayed by portals. These portlets are often complex and hard to
design, sit locally on system and are particular to the portal
container. This marrs the dynamic integration of business applications
and information resources into portals, which would often require
redesign of portlets for each particular service consumed. By
integrating these portlets (i.e. the presentation logic) with
corresponding services (i.e. the application), often called Remote
Portlets, the extra burden of portlet management can be avoided
Application integration is major issue for enterprise portal projects.
WSRP standard enables development of interoperable portlets on
different portal products thereby increasing the scalability,
reliability, performance and availability of portlets to an
organization. This along with the advantage of user dependent
selectivity and aggregation of information from all kinds of sources
can dramatically increase reach and productivity when building
enterprise portals. Without WSRP, organizations are limited to propriety
portlet technology that not only locks it to a particular vendor, but
also increases the development and deployment time for front-end
applications that talk to standardized Web services at the back end.
See also: WSRP references
WS-I Initiates Work on Three New Profiles
Web Services Interoperability Organization, Announcement
On May 01, 2006, the Web Services Interoperability Organization announced
that the WS-I Board of Directors had approved two new working group
charters, which will result in the development of three new WS-I profiles
in 2006: the Basic Profile 1.2, Basic Profile 2.0 and the Reliable Secure
Profile 1.0. WS I is a global industry organization that promotes
consistent and reliable interoperability among Web services across
platforms, applications and programming languages. The first charter,
a revision to the existing WS-I Basic Profile Working Group charter,
will result in the development the Basic Profile 1.2 and the Basic
Profile 2.0. The Basic Profile 1.2 will incorporate asynchronous
messaging and will also consider SOAP 1.1 with Message Transmission
Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP).
The Basic Profile 2.0 will build on the Basic Profile 1.2 and will be
based on SOAP 1.2 with MTOM and XOP. The second charter establishes a
new working group, the Reliable Secure Profile Working Group, which
will deliver guidance to Web services architects and developers
concerning reliable messaging with security. Work on the new profiles
will start immediately. The newly chartered Reliable Secure Profile
Working Group will begin developing scenarios, requirements and profile
guidance in parallel with the related standardization efforts within
the OASIS WS-Reliable Exchange Technical Committee. The working group's
primary deliverable is the WS-I Reliable Secure Profile (RSP) 1.0
which will provide guidance to architects and developers concerning
reliable messaging with security. RSP 1.0 will be based upon the
following specifications: (1) OASIS WS-ReliableMessaging 1.1;
(2) OASIS WS-SecureConversation 1.3. The scenarios and requirements
work will consider interoperability issues identified across a wide
range of Web services applications (e.g., mobile, devices,
intermediaries, enterprise applications, etc.).
See also: reliable messaging references
Installable Unit Deployment Descriptor Version 2.0 Submitted to OASIS SDD TC
Randy George, Technical Submission on behalf of IBM and Macrovision
A 4-part IUDD 2.0 submission to the OASIS Solution Deployment Descriptor
(SDD) Technical Committee presents enhancements to the Version 1.0
Solution Installation Schema presented to W3C in June 2004. According
to the "Solution Deployment Architecture V2.0 Overview": The Solution
Deployment Architecture defines a schema for XML documents called
Installable Unit Deployment Descriptors, or IUDDs. IUDDs define the
characteristics of resources that are relevant for their creation,
configuration and maintenance. IUDDs also define external metadata that
is common across all resource types. The Solution Deployment
Architecture also defines required characteristics of the context in
which these XML documents are used. In this version 2.0, "there has
been a substantial amount of work revising the V1.0 Installable Unit
Deployment Descriptor to make it more consumable and to improve the
overall quality of the schema." The submission includes: "(1) An
overview document describing the concepts behind the IUDD V2.0 schema.
We believe this document provides a good starting point for the
formation of the SDD V1.0 specification. (2) The IUDD V2.0 schema
including example deployment descriptors. (3) A draft specification
that consists of an outline with some sections augmented with figures
and examples, but no explanatory text. We believe this document
provides a useful guide to studying and understanding the schema.
(4) A document describing which of the formal SDD requirements are
met by this submitted schema."
See also: SDD references
JBoss Web Services Released
Thomas Diesler, JBoss Blog
"I am happy to announce that the web service team has released
JBossWS-1.0.0, ready to be used in the upcoming JBoss-4.0.4 release.
Support for the WS-Coordination, WS-AtomicTransaction and
WS-BusinessActivity specifications will be provided by technology
recently acquired from Arjuna Technologies Ltd. This technology will
be present within the JBoss Transactions 4.2.1 release. Further
information can be obtained from the JBoss Transactions Project;
both integration tasks are scheduled for jbossws-1.0.2. The
JBossWS-1.0.0 final release passes our internal testsuite, the
testsuite for the jboss-4.0.x web service stack and the more-than
2200 web service tests that come with Sun's Compatibility Test Suite
(CTS). It comes with its own tool set (wstools) that generates portable
J2EE-1.4 web service artifacts both from WSDL and from Java. JBossWS
currently supports [several] standard J2EE-1.4 features... JBossWS
also supports: Message style endpoints; Attachments Profile Version
1.0; Dynamic client/server side handler injection; Web Service Metadata
(JSR-181); EJB3 Stateless Session endpoints; WS-Security for
XML Encryption/Signature of the SOAP message; WS-Addressing and
JSR-261; WS-Transaction; WS-Eventing; WS-Policy; MTOM/XOP."
See also: the project web site
Simplifying VoiceXML Development with JSP-based VoiceXML Applications
Brett McLaughlin, IBM developerWorks
There are several ways to get VXML output by Java servlets. You can
simply write a VXML file and let a Java servlet output the VXML
directly from a file; you can do all the work of outputting VXML from
within a servlet, using out.println() statements; or you can use a
combination of these two techniques. You can also add dynamic, run-time
data to VXML with your Java servlets. All of these approaches should
make it clear to you that using Java for outputting VXML offers you
several advantages: (1) Flexibility. You can store your VXML in
several different mediums, from a static file to compiled code. (2)
Reactivity. You can react to users' choices by dynamically generating
VXML as needed. (3) Extensibility. It's easy to take a core servlet
that outputs basic VXML and extend it with other servlets, each of
which provide custom behavior. In this article, you'll learn about a
true middle-of-the-road approach: using JSP pages to output your VXML.
JSP pages have most of the features of Java servlets, and yet do not
require manual recompilation every time you modify a tag in the VXML
or JSP. As a result, you can make changes to your VXML and JSP pages
easily, while still retaining the power of a solution based on the
Java platform. By using the JSP page approach outlined in this article,
you can largely avoid the need for frequent recompilation and extensive
testing. Not only do you gain the ability to use familiar JSP page
coding techniques to develop your VXML applications, you are now
easily able to make incremental changes to your application without
having to recompile.
See also: VXML references
XML.org is an OASIS Information Channel sponsored by Innodata Isogen and SAP.
Use http://www.oasis-open.org/mlmanage to unsubscribe or change an email address. See http://xml.org/xml/news_market.shtml for the list archives. |
