| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 |
||||
|
|
|
||
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
 TEST CENTER Next-generation e-biz By James R. Borck May 11, 2001 Web-services-oriented architectures are gearing up to inspire e-business efficiency and dynamic partner integration
Java and XML have brought a high degree of portability to enterprise applications, but the hard-coded interface elements of today's distributed systems make integration difficult. Extending systems to new business partners means rebuilding the system to match new requirements. The Web services model overcomes the inflexibility of component-based architectures. In contrast to today's static and unwieldy applications, dynamic, flexible Web services will integrate partners and solutions faster and more cheaply, allowing companies to scale operations, streamline business processes, and get products to market faster. If this sounds too good to be true, it currently is. Competing architectures, incomplete standards, unresolved security issues, and limited developer support all cloud the future of Web services. Nevertheless, by the second half of 2002, Web services will emerge as the definitive standard for the next phase of global e-business. In the interim, your company should plan a Web services strategy, and your developers should familiarize themselves with Web services frameworks and tools. What exactly are Web services? "Web services" describes a service-oriented architecture in which self-contained, distributed applications, comprising very specific business functions, are enveloped in XML to facilitate integration intraenterprise and with business partners. Using a global publish and lookup mechanism, these task-specific software services can be described, published, located, and engaged, either directly or programmatically, over the Internet and private networks. With Web services, you, your suppliers, trading partners, and customers will be able to dynamically discover and call one another's published applications and chain them together to automate entire workflow processes. Private exchanges and marketplaces, procurement, billing and payment verification, and legacy application availability all will benefit from the streamlining mechanisms of Web services. But companies won't reap these benefits overnight. Many, still trying to catch up to the adoption of XML, are hard-pressed to devote the necessary resources to break existing applications into discreet Web services components. But what is lost in XML's transactional inefficiency is made up for in the reduction of the complexity inherent in today's e-business systems. Development times, and consequently time to market, can be reduced from months to just days, systems can be made easier to maintain, and new revenue streams can be tapped thanks to improved application accessibility. Better still, Web services deliver these benefits not by supplanting the distributed technologies in use but by extending their functionality. Web services suffer from several popular misconceptions. One is that Web services are simply hosted applications. Another is that they are merely a new way of interfacing with another company's software. But Web services do more than merely expose interfaces, for this discounts the impact of run-time discovery and binding (the process of determining how the applications will interface), the key capabilities that separate Web services from other application integration methods. In the evolution of enterprise computing, the generic, object-oriented software components of yesterday yielded to standards such as COM (Component Object Model), CORBA, Enterprise JavaBeans (EJB), and then distributed server-side computing. But each new integration scheme continued to demand tightly coupled, agreed-on preconfigurations for exchanging data requirements that needed addressing at the point of design. If an interface was changed, the system was broken. The next generation of software components will be more loosely coupled, binding applications at execution instead of during development. The process will make interoperability a word of the past. How Web services work Web services frameworks use XML to envelop applications and facilitate messaging. (See our illustration, "A Web-services-oriented architecture.") The original executable can be coded in any language or run on any platform because Web services don't rely on object-model-specific protocols such as DCOM (Distributed Component Object Model), as do other component-based technologies. Services can be developed to offer multiple options for communication, selectable at the point of engagement. SOAP (Simple Object Access Protocol) is used to define distributed object communication procedures. The XML-based protocol carries additional instructions on how data should be processed and, like XML, is platform-and transport-neutral. WSDL (Web Services Description Language) provides an abstract for exchange by describing service-specific data including details on the interface, available protocols, and other implementation-specific particulars. And finally, the UDDI (Universal Description, Discovery, and Integration) specification at the repository level provides the indexing and lookup capability for services through DNS data and SOAP-based APIs. UDDI data contains information about businesses and their location, services they offer, billing information, and allowable protocols. If your company wants to make an application available for service-based licensing over the Internet, you begin by defining an interface to your application using XML-based WSDL (Web Services Description Language). The resulting API, along with pertinent business-specific details, are published to a public UDDI (Universal Description, Discovery, and Integration) registry, where the service is indexed and classified for lookup. Businesses searching for an application, whether a stock-quote streamer or shipping services, can poll the UDDI registry and obtain the requirements for interfacing with your application. With this information, they can programmatically integrate your application into their in-house systems, using SOAP (Simple Object Access Protocol) to engage it or access it from a Web browser when they want to draw on your application manually. Web services would make it possible for companies to piece together complete financial architectures on an ad hoc basis using externally called applications. A Web service could even call other Web services to recursively complete much larger tasks. Entire travel itineraries could be booked when your in-house travel department syncs with airline, hotel, and car-rental booking services; each application calls the next until all the necessary criteria, such as dates and prices, are matched. The abstraction from the underlying implementation specifics including platform, language, and transport protocols provides a lowest common denominator by which data and services can be exchanged between applications. Using Web services, partners in a supply chain could be integrated more easily using a single, common interface to your applications. Your software developers build a single interface, and they aren't sent back to square one with each update or new partner integration. Although developers can see the great potential of Web services, CTOs can't cash in on the promise yet. Definitive standards, security, and QoS (quality of service) issues remain unanswered. Before CTOs can consider adoption seriously, problems of securing end-to-end data transport across multiple services and ensuring transactional committal, guaranteeing nonrepudiation, must be solved. The reality is that attempts at seamless interoperability will take some time. Today, vendors are beginning to push their visions for Web services frameworks and toolsets. Sun Open Net Environment (SunONE), Oracle9i Dynamic Services, and Microsoft HailStorm include support for various mixes of emerging Web services standards. Hewlett-Packard has a well-developed Web services model and deployment framework, but despite being the Web services forerunner, HP has taken a back seat to Microsoft and IBM, largely due to an initially unwise isolationist approach. HP has since integrated support for UDDI into its e-Speak registry and adopted SOAP in place of its own RPC (Remote Procedure Call) technology. IBM, which has remained impartial on interoperability, has made several development tools available on its alphaWorks site and recently announced that WebSphere Technology for Developers will support Web services standards as well as Java 2 Enterprise Edition (J2EE). Web services models are still developing. The leading contender in Web services foundations is ebXML (e-business XML), being developed by the OASIS group. The ebXML specification provides for a thorough, end-to-end handling of services and even factors in business process requirements and security details. Despite sizable differences between the specifications, work is being done to ensure interoperability. The ebXML standard has recently adopted SOAP Messages with Attachments in lieu of MIME, and it can integrate its service repository scheme with UDDI registries. Good development begins at home The limited availability of services and brokers also constrains developers' capabilities. But services will beget services. Early adopters are focusing on reworking in-house systems to take advantage of Web services on the home front. Learning Web services won't require much effort for anyone with a background in object-oriented design. Web services follow familiar rules such as encapsulation, message passing, and dynamic binding and are designed with good separation between logic and presentation layers. For many businesses, dissecting existing applications into bite-size service components will be a time-consuming project. But by beginning slowly and approaching new application development from a service-oriented standpoint, in-house developers will gain the knowledge they need to prepare for widespread Web services integration. Most companies appear to be taking a wait-and-see attitude toward Web services, but few are debating that the service-oriented architecture will provide the next set of building blocks in the evolution of e-business. As Web services move from curiosity to compulsory, how dynamic e-business can become will ultimately depend on good vendor cooperation and the ability to enhance standards without breaking them. The success of Web services frameworks and tools vendors depends on these same criteria. No vendor currently enjoys a clear competitive advantage in Web services, and we should all hope that's the way it remains.  Test Center Managing Analyst James R. Borck (james_borck@infoworld.com) covers e-business solutions for enterprise computing.
 RELATED ARTICLES  HP's call to Web actionJump-start developersPlugging in Web appsSPONSORED WHITE PAPERS 
SPONSORED LINKS
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
