[May 05, 2004] "Web Services Find Way to Devices." By Joris Evers (IDG News Service). In Computerworld Hong Kong (May 05, 2004). "Microsoft Corp., Intel Corp., Lexmark International Inc. and Ricoh Co. Ltd. on Tuesday detailed new Web services technology designed to make it easier for users to connect devices such as printers, digital cameras and digital music players over a network. The companies at Microsoft's Windows Hardware Engineering Conference (WinHEC) officially announced a Devices Profile for Web services, which describes how devices should use Web services protocols. The announcement builds on WS-Discovery, a Web services specification that Microsoft, Intel, Canon Inc. and BEA Systems Inc. introduced in February. WS-Discovery describes a way for devices to find and connect to Web services. The plan to use Web services to connect peripherals to computers is a change from the current use of Web services as a technology to connect business software across corporate networks or the Internet. At WinHEC in Seattle, Microsoft announced a Network Connected Device Driver Development Kit (DDK) for the technology and said Canon and Hewlett-Packard Co. will showcase printers supporting Web services protocols at the event. Devices that use the new technology will automatically be discovered when connected to a home or company network and can subsequently be installed using the Windows plug and play subsystem as if connected directly to a PC... UPnP (Universal Plug and Play) 1.x used today is not enterprise ready, according to [Microsoft's] Allchin. Microsoft and the other developers of the Devices Profile plan to propose it to the UPnP Forum for consideration as the basis for the UPnP 2.0 Device Architecture before the end of the year... Assuming all goes well with the process of getting approval by the UPnP Forum, the first devices using the technology could be out in the 2006 or 2007 timeframe, said Stephen Whalley, technology enabling manager at Intel..." See details in the news story: "Microsoft Releases Devices Profile for Web Services Specification."

[May 04, 2004] "Portlet Standard Predicament: With Two Portlet Access Visions and No Single Standard to Bridge the Gap, the Choice Is Less Than Certain." By Alan Zeichick. In InfoWorld (April 30, 2004). "Two new industry specifications may standardize the logical separation of portal applications (aka portlets) from the portal servers that use their services. The benefits of such a separation are clear, but the choice of whether to adopt the Java Community Process' JSR (Java Specification Request) 168 or OASIS's WSRP (Web Services for Remote Portlets) is less certain. Why separate portlets from portal servers? The most obvious and short-term benefits come from improved scalability. In the traditional portal model, portlets ran on the same J2EE application server as the portal server, interacting via simple J2EE interprocess communication. However, as portal use grew, moving the portlet to another piece of hardware and accessing it remotely reduced processor utilization on the portal server. Also, departments within a business often want to write and maintain their own portlets — something that's hard to accomplish across cultural and technology boundaries if portlets must be deployed to a centralized 'glass house' portal server, but it is easy to do if portlets are hosted separately. It's only recently that industry consortia began defining standard interfaces and communications protocols for running portlets remotely. But the two top specs, JSR 168 and WSRP, are more competitive than complementary. WSRP was designed not only to allow remote portlet-to-portal communication via XML-based Web services but also to accommodate cross-platform portlets. Thus, a J2EE-based portal server could interoperate with a portlet running on a .Net machine as long as it exposes its functionality via WSRP-compliant Web services. The rich WSRP specification defines the communications protocol as well as standardized behavior language for portal-to-portlet transactions, and it uses WS-Security to add encryption and authentication to portlet-portal transactions. WSRP is also extensible and defines a method of extending the behavior language... By contrast, JSR 168's scope is more limited. It does not support cross-platform communications, Web services, or vendor-specific extensions — and it is more likely to ensure broad interoperability, at least within J2EE-based portlets. JSR 168 is defined as a set of extensions to the Java servlets APIs (javax.servlet.portlet), which is easier to implement than WSRP; JSR 168 is already found on most J2EE-based portlets..." See other references in: (1) "Portlet Open Source Trading (POST) Site for JSR 168 and WSRP Portlets"; (2) "Web Services for Remote Portals (WSRP)."

[May 04, 2004] "Diving Into Portals' Distinguishing Characteristics." By Mike Heck (InfoWorld Test Center). In InfoWorld (April 30, 2004). ['More than a single access point to enterprise data sources, portals are evolving into the Web application framework of the future.'] "Portals are no longer just jazzed-up intranets. Now that many applications are Web-enabled, portals are becoming the enterprise desktop and replacing the familiar browser. Dive below the surface, and you'll find a portal's distinguishing characteristics: Rich functions that enable swift information exchange for employees, partners, and consumers... A basic portal won't automatically lessen information overkill; that takes support for strong identity management along with role-based customization and personalization. If this support is executed properly, users log in once and interact with information tailored to their jobs, whether that data is fed from a legacy database, content- or document-management system, another portal, or a new Internet-based application. Moreover, portals are redefining the way new applications are created, deployed, and managed. At the core of this movement you'll find Web services and related open standards. Microsoft .Net, Sun's Java System, WSRP (Web Services for Remote Portlets) and a number of Java Portlet Specifications JSR (Java Specification Request - 168, 170, 188, and 207) may help disparate systems freely interact. This openness and modularity provides the option of purchasing third-party portlets for specific functions... The top portal solutions will run on common J2EE app servers, such as IBM WebSphere or BEA WebLogic, or .Net, or both. Here's what differentiates otherwise closely matched products: whether a portal runs best on a vendor's own platform and how well it truly integrates with existing enterprise systems, such as directory and security. There are three portal formats. One favors a tightly integrated APS (application platform suite) approach. Here, the application server, integration framework, and portal are combined into one platform. BEA, Oracle, Sun, Microsoft, and IBM follow this model. With the APS approach, developers can more easily leverage existing databases and reuse business logic. However, you can get locked in to a particular vendor's method of deploying applications or server management. An alternate method, fusing diverse systems through the portal application, is the path Vignette and Plumtree follow. With this method, you may sacrifice some ability to manage applications throughout their life for the freedom to choose the best application server and other components to meet specific needs. Lastly, ERP vendors such as SAP provide portal access to their own application along with some additional integration capabilities..." See also the "Checklist for Enterprise Portals: Eight Features Your Portal Shouldn't be Without." Other references in "Web Services for Remote Portals (WSRP)."

[May 04, 2004] "Microsoft Announces Updated Developer Preview Code for Longhorn at WinHEC 2004." By Paula Rooney. In CRN (May 04, 2004). "At its annual Windows Hardware Engineering Conference (WinHEC) 2004 in Seattle, Microsoft Chairman Bill Gates announced updated developer preview code for the Longhorn version of Windows that will enable device manufacturers to begin development of native Longhorn device drivers... Microsoft also detailed new Web services technology and a Web services specification designed to make it easier for a variety of PC and network-attached devices, such as Palm devices and Microsoft SmartPhones, to work together. Microsoft, Intel, Ricoh and Lexmark, for example, unveiled the Devices Profile for Web Services specification that describes how devices can support Web services. At the show, Microsoft and Hewlett-Packard demonstrated an HP printer connecting to a Windows-based PC using the new Web services discovery protocol. Canon and HP showcased printers supporting these protocols at WinHEC. The Devices Profile will be proposed to the UPnP Forum for consideration as the basis for the UPnP 2.0 Device Architecture..." See details in the news story: "Microsoft Releases Devices Profile for Web Services Specification."

[May 04, 2004] "The Conference Policy Control Protocol (CPCP)." By Hisham Khartabil and Petri Koskelainen (Nokia). IETF Centralized Conferencing Working Group [XCON], Internet Draft. Reference: 'draft-ietf-xcon-cpcp-xcap-00'. April 19, 2004, expires October 18, 2004. 32 pages. The Centralized Conferencing Working Group is part of the IETF Transport Area. "This document describes the Conference Policy Control Protocol (CPCP). It specifies an Extensible Markup Language (XML) Schema that enumerates the conference policy data elements that enable a user to define a conference policy. It also defines an XML Configuration Access Protocol (XCAP) application usage that is needed to store and manipulate a conference policy." Background: "SIP conferencing framework defines the mechanisms for multi-party centralized conferencing in a SIP environment. Existing SIP mechanisms allow users, for example, to join and leave a conference. A centralized serve, called focus, can expel and invite users, and may have proprietary access control lists and user privilege definitions. However, in many cases it is useful to have a standardised conference policy elements such as access control lists and a standardised protocol means to manipulate them. The requirements for such protocol are defined in ['Requirements for conference policy control protocol']. This document provides an XML Schema that enumerates the conference policy data elements that enable a user to define a conference policy. It also defines an XML Configuration Access Protocol (XCAP) application usage that is needed to store and manipulate a conference policy. Other mechanisms, such as web page or voice response system can also be used to manipulate conference policy data... XCAP has many advantages in its use for conference policy control protocol. It is a HTTP 1.1 based protocol that allows clients to read, write, modify and delete application data stored in XML format at a server. XCAP maps XML document elements and attributes to HTTP URIs that can be directly accessed by HTTP. One application area which has already adopted XCAP is the manipulation of event lists..." See also: (1) "IETF Publishes Internet Drafts for XML Configuration Access Protocol (XCAP)"; (2) "IETF SIMPLE Specifications Support Presence-Based IM, Video, and Voice"; (3) IETF Centralized Conferencing (XCON) Working Group Charter."

[May 04, 2004] "Statement to W3C Compound Document Committee." By Eliot Kimber (Innodata Isogen) and Michael Priestley (IBM). Posted 2004-05-03 to the OASIS DITA TC document repository, and proposed as a statement "on behalf of the OASIS Darwin Information Typing Architecture Technical Committee." Excerpt: "The subject of compound documents is of primary interest to the DITA Technical Committee. The Darwin Information Typing Architecture defines a set of techniques for using XML in order to enable the effective and efficient development of re-usable information components, primarily in the context of technical documentation, informative Web sites, and similar types of structured, topically-focused information for consumption by humans. This activity naturally involves the combination, whether syntactically or semantically, of elements from different name spaces and governed by different schemas... As we understand the scope of the W3C Compound Document Workshop, it is focused primarily on issues surrounding XML documents that have elements from different name spaces (and thus implicitly, different schemas) and what that means. Within this scope there are a number of important use cases that must be considered, including the implications for processors that must make sense of compound documents, how communities of interest can define and impose constraints on what combinations are allowed, and how to do controlled specialization of element types in a way that does not, for example, require the creation of overarching XSD schemas that define the specializations as part of the base element type definitions. DITA has a part to play in each of these areas: (1) Our specialization-based processing architecture lets both standard and customized transforms work with unknown document types based on their ancestry. (2) Our DTD/schema integration rules provide a framework in which communities can define their own combinations of markup without breaking interoperability or processing infrastructure. (3) Our specialization scheme separates out the definition of new markup into modules that can be consistently and predictably integrated with other DITA modules... We observe that the term 'compound document' is often used to refer not to single instances that combine elements from different name spaces but systems of independent documents linked together in order to define a single unit of processing, delivery, or management (i.e., hyperdocuments explicilty created and processed as a single unit of processing, as opposed to ad-hyperdocuments created through the creation of uncoordinated linking actions). Both the XLink and XInclude specifications define mechanisms for creating this type of compound document, as does the current DITA specification (through its map mechanism). This sense of compound document is largely orthogonal to the question of combining elements from different schemas: most existing systems that create this type of compound document do so in the context of a single document type. We urge the W3C to clarify its use of the term 'compound document' to clearly distinguish at least these two senses in order to establish a clear and unambiguous standard vocabulary by which we, as a community, can communicate efficiently and effectively on this important and challenging subjects..." See: (1) W3C Workshop on Web Applications and Compound Documents, June 1-2, 2004; (2) "Darwin Information Typing Architecture (DITA)."[cache]

[May 04, 2004] "Six Strategies for Grid Application Enablement, Part 1: Overview." By David Kra (Executive Consulting IT Architect, IBM). From IBM developerWorks (April 27, 2004). ['This article, first in a series, defines six strategies for grid application enablement. It explains the characteristics of applications suitable for these strategies and the benefits to organizations that run these applications. Subsequent articles will explain how to enable applications using strategy 1 through strategy 5 with as little effort as possible.'] "There are six strategies for grid enablement. They start with simply running in a grid and end with fully exploiting the grid. It's very important to note that by merely running in a grid, your customer gains value and you gain revenue and industry leadership. Also, by letting the grid provide facilities that are currently in your offering (such as file movement and scheduling), you might be able to reduce the non-core-competency code from your product without a loss of function. Over time, there will be an unavoidable requirement for grid enablement: your application must be accessible as a Web service. For example, your application must have its Session Enterprise JavaBeans (EJBs) components exposed as Web services, or it must have a Web services artifact (a wrapper, an interface, a facade, a veneer, or whatever you want to call it) that can invoke the existing code. Available tooling helps accomplish that. As grid standards are built into the appropriate Web services specification, Web service enablement becomes increasingly important. Service-oriented architectures and Web services are becoming the substrate on which strategic grid environments are based... Strategy 1: Batch Anywhere; Strategy 2: Independent Concurrent Batch; Strategy 3: Parallel Batch; Strategy 4: Service; Strategy 5: Parallel Services; Strategy 6 :Tightly Coupled Parallel Programs. These strategies can be grouped into three stages for implementation: (1) Run — Strategies 1 and 2, and the simplest form of Strategy 3, focus on the ability of an application to run in a grid. (2) Adapt — The more complex form of Strategy 3 as well as Strategies 4 and 5 significantly adapt the function and value of the business application by enabling it to use a grid without requiring many changes that are specific to grid middleware. The same application could be structured to run in a non-grid environment. (3) Exploit — Applications at Strategy 6 exploit the grid or cluster infrastructure for their operation because they were written from the start with a grid in mind. Strategy 6 applications cannot finish in a timely and successful manner without running in a grid..."

[May 03, 2004] "OASIS Frees Universal Business Language for General Use." By Darryl K. Taft. In eWEEK (May 03, 2004). "E-business standards consortium OASIS announced that the Universal Business Language (UBL) 1.0 specification has been approved as an OASIS draft and is now available for general use. Jon Bosak, a distinguished engineer at Sun Microsystems Inc. and chairman of the OASIS UBL technical committee, said UBL 1.0, which OASIS released for general use over the weekend, represents six years of development in building a standard XML business syntax. Bosak said business is built on the use of standard, legally binding documents and that UBL is an effort to bring those documents — such as purchase orders, shipping notices and invoices —online. UBL schemas plug into traditional business legal and records management practices, and they fill the 'payload' slot in XML-based, business-to-business frameworks... Bosak said he sees broader implications for the XML EDI framework enabled by UBL and ebXML that extend beyond B2B relationships and into interactions such as those between governments and their citizens, retailers and consumers, and tenants and landlords, because those relationships depend on the same features required for B2B. UBL 1.0 provides a library of XML schemas for components such as Address, Item and Payment, and other schemas such as Order and Invoice are constructed from the UBL library components. Meanwhile, UBL schemas come with such supporting materials as Unified Modeling Language class diagrams, spreadsheet models, sample instances and formatting specifications..." See: (1) details in the news story "Universal Business Language (UBL) 1.0 Approved as an OASIS Committee Draft"; (2) general references in "Universal Business Language (UBL)."

[May 03, 2004] "Universal Biz Language Ready for Web Services." By Clint Boulton. From InternetNews.com (May 03, 2004). "E-commerce standards across the globe could start to align now that standards body OASIS has approved for public use a description language for XML-based purchase orders, invoices and shipping notices. After six years in development, the Universal Business Language Version 1.0 is now available in draft form for users to freely test the specification, according to an OASIS document published Friday. UBL, which aims to provide a universal syntax for business documents, is geared to work within a larger standard business framework such as ISO 15000 (ebXML). Messaging exchange languages such as UBL and ebXML define how enterprises can conduct business across the globe, knocking down barriers associated with distance and language with e-commerce facilitated by Web services... The UBL v1.0 library features XML schemas for eight business document types designed for standard order-to-invoice trading, and support for the customization of UBL in specific trading scenarios. The commercial draft release contains modularized common XML schemas, including Business Information Entities (BIEs), which are assembled into document models such as Order and Invoice, as well as reusable data type schemas, a metadata schema, and thirteen code list schemas..." See: (1) details in the news story "Universal Business Language (UBL) 1.0 Approved as an OASIS Committee Draft"; (2) general references in "Universal Business Language (UBL)."