April 2004

[Compilation in process]

• [April 29, 2004] "Databases Flex Their XML: IBM, Microsoft, Oracle, and Sybase Compete in Our Data Management Gymnastics." By Sean McCown. In InfoWorld (April 23, 2004). "If you could do one thing to improve integration and automate processes with customers and business partners, it would be to implement XML, which has become the standard for exchanging information between disparate systems because it is easily transformed into any format. With very little effort, the same file can be sent to several different customers with their own specific needs. XML eases the development effort for the transmitting company and gives recipients a safety net for altering the way they use the data without having to alter how they receive it. Being able to merge, query, and transform transmitted data with relational data is becoming as essential to businesses as data warehouses themselves. The good news is that the four leading relational databases, namely Oracle Database, IBM DB2, Sybase ASE (Adaptive Server Enterprise), and Microsoft SQL Server, not only can store XML data, but they hide much of the complexity of working with XML. Depending on which of these relational databases you use, however, the XML features you will have to work with may be extremely rich or limited in important ways. What does a fashionable XML database provide? Four basic functions: the ability to consume, store, search, and generate XML. The extent to which the database supports these functions and the methods it uses to accomplish them are what make for a successful implementation of XML in a database. I examined these four areas in Oracle Database 10g, IBM DB2 Universal Database V8.1, Sybase ASE 12.5.1, and Microsoft SQL Server 2000. I tested how they imported and read XML files, their options for saving the data, their indexing and query capabilities, and their options for creating XML and graded them based on the ease, flexibility, and speed with which they handled the most common XML operations. Of course, these products have many other capabilities beyond handling XML..." See other details in the InfoWorld special report. General references in "XML and Databases."

• [April 29, 2004] "Open-Source Backers Ready Longhorn Defense." By Mary Jo Foley. In Microsoft Watch [eWEEK] (April 21, 2004). "The open-source development community is looking to head off Microsoft Longhorn before it escapes the Redmond corral. Some key members of the community recently met to discuss ways the open-source movement can prepare for Longhorn, the next major version of Windows that is expected to debut on the desktop in 2006. According to the minutes posted to the Web from an April 21, 2004 meeting involving members of the Gnome Foundation and the Mozilla Foundation teams, Longhorn's Avalon and XAML technologies appear to be the most potentially worrisome for the open-source community. Avalon is the code name for the presentation subsystem that Microsoft is building to be part of Longhorn. XAML is the Extensible Application Markup Language that is tightly integrated with Avalon and will be the primary vehicle for writing Avalon application. Gnome co-founder Nat Friedman suggested that open-source vendors look into the possibilities of cloning XAML, as well as possibly building an Avalon competitor consisting of open-source components. Candidates for this collection include the GIMP-based GTK+, a library for creating graphical user interfaces for the X Window System, and the XML User Interface Language (XUL) developed by Mozilla..." See also: (1) "XML Markup Languages for User Interface Definition"; (2) "Microsoft Extensible Application Markup Language (XAML)."

• [April 29, 2004] "Longhorn's Real Job: Trying to Gore Linux." By Steven J. Vaughan-Nichols. In eWEEK (April 29, 2004). ['Microsoft's No. 1 job for Longhorn is to make money, but killing off the Linux desktop isn't far behind, Linux and Open-Source Center Editor Steven Vaughan-Nichols writes.'] "Now, after having their hands gently slapped by the Department of Justice, the boys from Redmond have another plan: Make it so that users of their next desktop system won't be able to use non-Microsoft-blessed servers or programs at all. I'm not the only one who sees this coming. The GNOME Foundation and Mozilla Foundation teams also see it coming, and they're trying to come up with a plan of defense. They're convinced that Avalon, Longhorn's presentation subsystem, and XAML, Avalon's Extensible Application Markup Language, will lock in users to Microsoft's proprietary programs or only to programs written with Microsoft-proprietary tools. Me, I think that's a big deal, but I think WinFS, Longhorn's file system, is at least as big a problem. You see, Microsoft is busy patenting everything it can lay its hands on with all three. In fact, Microsoft is now building up its patent arsenal, applying for a rather amazing 10 patents a day. The idea isn't to ensure that Microsoft makes a fair profit from its patents; it's to make sure that no one else can write fully compatible software. The irony of this is twofold: It's exactly the opposite of what the patent system was supposed to do, and XML was meant to open internetwork and interapplication communications, not provide a way to lock them up. The open-source leaders are considering ways around these problems, such as promoting the use of open standards-based technologies like GNOME's open-source GUI toolkit, GTK+ and Mozilla's User Interface Language, XUL. Or, taking a leaf from the Samba crew, just try to reverse-engineer and clone Avalon and XAML. Either approach could work, but work needs to start sooner rather than later, no matter which direction developers end up going in... Miguel de Icaza, one of the most respected open-source programmers and father of the Mono project, which attempts to bring .NET to Linux, says it best. He writes in his blog, 'What makes Longhorn dangerous for the viability of Linux on the desktop is that the combination of Microsoft deployment power, XAML, Avalon and .NET is killer'..." See: "Microsoft Extensible Application Markup Language (XAML)."

• [April 26, 2004] "Countdown to BPEL Begins - A Dev's FAQ." By Vance McCarthy. In Integration Developer News (April 26, 2004). "Controversy may be giving way to simple heads-down hard work when it comes to BPEL4WS, the proposed orchestration standard for web services supported by both Java and .NET vendors. Leading J2EE app server vendors BEA and IBM have jointly proposed extensions to BPEL (Business Processing Execution Language) to make the standards implementable within Java/J2EE environments. BPELJ is 'a reflection that BPEL will happen, and we hope it will happen this year. Too many vendors want it to happen,' Stephen Hood, BEA product manager for WebLogic Integration, told Integration Developer News. Further, Hood told IDN, 'BEA will write and provide a reference implementation of BPELJ. Depending on demand and the evolution of the specification, we will also consider making this implementation open source and royalty-free. We're very serious about it. We want this to be very portable across the Java platform.' To get more perspective in BPELJ, IDN spoke in depth with BEA's Hood. He addresses the genesis of BPELJ, how it will help developers implement BPEL, and what assurances are in place to make sure that BPELJ doesn't undo any interoperability between Java and .NET orchestration... BPELJ is a joint submission from IBM and BEA that will amend JSR 207 within the Java Community Process (JCP). The proposed extensions in BPELJ will enable Java and BPEL to cooperate by allowing sections of Java code, called Java snippets, to be included in BPEL process definitions. Snippets are expressions or small blocks of Java code that can be used for things such as, but not limited to, the following: Loop conditions; Branching conditions; Variable initialization; Web service message preparation; and Logic of business functions. In addition, BPELJ enables J2EE developers to create business processes that include both web services and currently existing traditional J2EE business components..." General references in "Business Process Execution Language for Web Services (BPEL4WS)."

• [April 21, 2004] "Why WSDL Is Not Yet Another Object IDL." By Jim Webber (University of Newcastle upon Tyne) and Savas Parastatidis (North-East Regional e-Science Center - NEReSC, Newcastle, UK). In Web Services Journal (April 05, 2004). "There has been much debate lately on what exactly WSDL's purpose is, and much of that debate has focused on whether WSDL is an interface definition language (IDL), or whether WSDL is better used to specify message-level contracts (without any associated operational semantics). In this article we present an argument that dealing with WSDL as a message-level contract description language is the right way to go for building loosely coupled Web services. In an object-oriented view of the world, applications are composed from objects - entities that encapsulate state and have a well-defined, publicly visible interface. The interface describes the operations or methods that an object supports and that other objects can invoke. Each method represents an action that, when invoked, may or may not result in the state of the object being changed. Unlike an interface, a contract is about the information on the wire and not about how the in-memory representations of objects are accessed... Contracts allow systems to be built from components (services) that have well-defined boundaries. These services can be developed and evolve independently since they do not share any abstractions. No single type system spans all the components. All that is agreed upon is the information that is exchanged and not how to access any in-memory representation of the objects. In the Web services arena, a WSDL document is the contract that a service advertises to its potential consumers. Since it is written in XML and (potentially) uses XML Schema, there is no need for shared abstractions or interfaces of in-memory representations... Like XML Schema that can be used as a document validation mechanism or a meta-level type system, WSDL is broad enough in its scope to be (ab)used as something akin to an object IDL or as a contract description language. While there are proponents of the former, the simplicity of the contract view of WSDL is compelling since it is a natural fit with the loosely coupled nature of Web services-based applications. Though WSDL 2.0 may yet provide the features necessary to support both views, we advocate the use of WSDL as a means of describing message exchanges in which a Web service participates. We believe that this approach yields the most loosely coupled system architectures, which are more robust in the face of changing requirements than those systems that impose an object-like view of the world onto a service-oriented application..."

• [April 15, 2004] "WSRP and JSR 168: Will These Portal Standards Matter to You?" By Penny Lunt Crosman. In Transform Magazine (April 15, 2004). "WSRP is a communication protocol that allows 'portlets' (packaged content and/or computing capabilities) from one application to work within another (notably, but not only, portals). JSR 168 is a Java programmatic interface that lets Java-based portlets work within WSRP-compliant applications. In the absence of these standards, any consuming application requires individual integration points to be hand-built between every application and information source. With WSRP and JSR 168, compliant portlets are transformed into fungible business objects that can be brought into many different applications and combined into various combinations of content and capabilities. Thus, these standard protocols allow user-driven integration, while leaving content and information to be managed at its native source. Integration costs are reduced without jeopardizing the integrity of information and content repositories... In the future, WSRP and JSR 168 should benefit customers in two ways. First, as the standards become adopted, portal developers will need less platform-specific training; their skills will become portable, making them easier to find and less expensive to hire. Second, as firms' portal strategies mature, they'll start to expose internal portal components — such as collaboration spaces and order-entry systems — to partners. JSR 168 will let companies share portlets by sending each other code; WSRP will let them share a centrally-hosted portlet..." General references: "Web Services for Remote Portals (WSRP)."

• [April 12, 2004] "BPELJ: BPEL for Java. A Joint White Paper by BEA and IBM." March 2004. By Michael Blow (BEA), Yaron Goland (BEA), Matthias Kloppmann (IBM), Frank Leymann (IBM), Gerhard Pfau (IBM), Dieter Roller (IBM), and Michael Rowley (BEA). Copyright (c) BEA Systems, Inc. and International Business Machines Corp 2004. 24 pages. With overview. "The Web Services Business Process Execution Language (BPEL) is a programming language for specifying business processes that involve Web services. BPEL is especially good at supporting long-running conversations with business partners. Even before the standard is formally released it is becoming clear that BPEL will be the most widely adopted standard for business processes involving Web services. BPEL is geared towards 'programming in the large', which supports the logic of business processes. These business processes are self-contained applications that use Web services as activities that implement business functions. BPEL does not try to be a general-purpose programming language. Instead, it is assumed that BPEL will be combined with other languages, which are used to implement business functions ('programming in the small'). This white paper proposes a combination of BPEL with Java, named BPELJ, that allows these two programming languages to be used together to build complete business process applications. By enabling BPEL and Java to work together, BPELJ allows each language to do what it does best. BPELJ enables Java and BPEL to cooperate by allowing sections of Java code, called Java snippets, to be included in BPEL process definitions. Snippets are expressions or small blocks of Java code that can be used for things such as: loop conditions, branching conditions, variable initialization, Web service message preparation, logic of business functions etc. BPELJ introduces a few minor changes to BPEL as well as several extensions in order to fit BPEL and Java conveniently together; the changes to BPEL are listed in the appendix. However, if any of these changes are not accepted, BPELJ will use existing features of BPEL, with a somewhat more awkward result. BPELJ extensions are introduced via extension points defined in the BPEL standard to provide the new functionality. A BPELJ process will execute on any platform that supports the BPELJ extensions to BPEL. Note especially, that BPELJ does not include any extensions that are required for all BPELJ processes, so any BPEL process is a valid, executable BPELJ process. In addition to making it possible to use Java to do the computational work of a business process, BPELJ also makes it possible to use BPEL to orchestrate long-running interactions with J2EE components. There is a lot of business logic that is currently deployed in Java components and BPELJ makes it possible to create business processes that include these components as well as Web services within the same business process..." General references in "Business Process Execution Language for Web Services (BPEL4WS)."

• [April 12, 2004] "Java, BPELJ Hailed. J2EE 1.4 Boosters to Gather." By Paul Krill. In InfoWorld (April 09, 2004). "Java is getting promotional boosts in the form of a gathering of vendors touting the latest Java specification and a whitepaper pertaining to BPELJ (Business Process Execution Language for Java), which links Java and Web services business processes. Java proponents will hold a unity-driven 'J2EE 1.4 Kickoff' media and analyst event in San Francisco on April 26, 2004, featuring speakers from Sun Microsystems, IBM, and even JBoss, which had been at odds with Sun over licensing of Java. he event is designed to showcase unity in the J2EE marketplace around J2EE 1.4, which has been cited as the Web services-based version of Java. J2EE 1.4 was approved in November. Scheduled to appear at the event are John Fowler, Sun CTO; Mark Bauhaus, vice president of Java Web services at Sun; George Paolini, vice president and general manager of Java solutions at Borland; Ted Farrell, chief architect and senior director of strategy for application development tools at Oracle; Steve Harris, vice president of the Java Platform Group at Oracle; and Mark Fleury, CEO and founder of open source Java application server provider JBoss. Also slated to attend are Mike McHugh, vice president of engineering at WebLogic Server at BEA Systems, and Mark Heid, program director for WebSphere at IBM. Sun and JBoss had had their differences pertaining to JBoss' licensing of the Java certification test suite and the expense involved. The two have since settled their differences. In addition to appearing at the J2EE 1.4 event, JBoss also will make a first-ever appearance at the JavaOne conference in San Francisco in June. BEA Systems and IBM, meanwhile, have published a white paper on BPELJ, which enables Java and BPEL to be used together to build business process applications..." General references in "Business Process Execution Language for Web Services (BPEL4WS)."

Earlier XML Articles

• XML Articles and Papers March 2004
• XML Articles and Papers February 2004
• XML Articles and Papers January 2004
• XML Articles and Papers December 2003
• XML Articles and Papers November 2003
• XML Articles and Papers October 2003
• XML Articles and Papers September 2003
• XML Articles and Papers August 2003
• XML Articles and Papers July 2003
• XML Articles and Papers June 2003
• XML Articles and Papers May 2003
• XML Articles and Papers April 2003
• XML Articles and Papers March 2003
• XML Articles and Papers February 2003
• XML Articles and Papers January 2003
• XML Articles and Papers December 2002
• XML Articles and Papers November 2002
• XML Articles and Papers October 2002
• XML Articles and Papers September 2002
• XML Articles and Papers August 2002
• XML Articles and Papers July 2002
• XML Articles and Papers April - June, 2002
• XML Articles and Papers January - March, 2002
• XML Articles and Papers October - December, 2001
• XML Articles and Papers July - September, 2001
• XML Articles and Papers April - June, 2001
• XML Articles and Papers January - March, 2001
• XML Articles and Papers October - December, 2000
• XML Articles and Papers July - September, 2000
• XML Articles and Papers April - June, 2000
• XML Articles and Papers January - March, 2000
• XML Articles and Papers July-December, 1999
• XML Articles and Papers January-June, 1999
• XML Articles and Papers 1998
• XML Articles and Papers 1996 - 1997
• Introductory and Tutorial Articles on XML
• XML News from the Press