Open Net Environment (ONE) Software Architecture White Paper

Open Net Environment (ONE) Software Architecture

An Open Architecture for Interoperable, Smart Web Services
Open Net Environment (ONE) Software Architecture Summary
Resources

Open Net Environment (ONE) Software Architecture

Introduction

The Internet has had a profound impact on user expectations. Not too long ago, a computer user was a highly trained individual. Businesses trained their employees to be experts in one or two specific applications. A Web user, though, is an entirely different breed. A business doesn't have the luxury of training its Web users. Web applications must be intuitive. Or perhaps it's more appropriate to say that Web applications have to be invisible. People simply use the Web to read e-mail, find directions, pay bills, approve an expense request, and so on. They don't view these activities as executing applications. They're simply using services that are available on the Web. They want to be able to access these services from a wide variety of client devices, such as desktop systems, PDAs, mobile phones, and in-car computers. Furthermore, the user wants these services to be smart enough to understand and act differently according to the context of the situation. Who am I? Where am I? What time is it? Am I acting as an employee or an individual?

These new user expectations are causing businesses to change the way they build application systems. Rather than creating large, monolithic applications or desktop-oriented, client/server applications, businesses are starting to build applications using a service-oriented application design. Software is being broken down into its constituent parts - into smaller, more modular application components or services. These application services make use of infrastructure software that has also been decomposed into discrete system services. All these discrete services can be deployed across any number of physical machines that are connected to the Internet. This modular services approach gives companies great flexibility in system design. By reassembling a few services into a new configuration, a business can create a new service.

Back to Top

Services

An application service represents a type of user or business activity, such as reading e-mail, getting a stock quote, authorizing a credit purchase, and procuring materials. A system service represents system infrastructure and management functionality, such as storage, security, transactions, messaging, and fault recovery.

A service exhibits the following characteristics:

  • It provides an interface that can be called from another program.
  • It is registered and can be located through a service registry.

Service-oriented systems are not a new concept - we've been using service-oriented systems such as ONC RPC, DCE, COM, CORBA, RMI, and Jini[tm] technologies for years. Now we're seeing a new, service-oriented system evolve: one that focuses on delivering services over the Web. This new type of service is commonly known as a Web service.

Web Services

A Web service represents a unit of business, application, or system functionality that can be accessed over the Web. Web services are applicable to any type of Web environment, be it Internet, intranet, or extranet, with a focus on business-to-consumer, business-to-business, department-to-department, or peer-to-peer communication. A Web service consumer may be a human who is accessing the service through a desktop or wireless browser, it could be an application program, or it could be another Web service.

A Web service exhibits the following characteristics:

  • It is accessible over the Web.
  • It provides an interface that can be called from another program.
  • It is registered and can be located through a Web service registry.
  • It communicates using messages over standard Web protocols.
  • It supports loosely coupled connections between systems.

The industry is clearly focusing in on the eXtensible Markup Language (XML) as the lingua franca to enable Web services. Most Web services use XML to describe their interfaces and to encode messages. What is most intriguing about XML-based Web services is that it doesn't matter what technologies are used to build the Web services. XML-based Web services communicate over standard Web protocols using XML interfaces and XML messages, which any application can interpret. Hence, all XML-based Web services can interoperate - at least in theory.

What Businesses Want

Since the advent of the Web in 1994, businesses have been using the Internet to get closer to their shareholders, employees, customers, and partners. They have been using the Internet to automate supply chains and improve business process efficiency. Electronic business is no longer a future direction; it has become the norm. Now businesses are intrigued by the Web services approach to Internet computing. The Web services computing model promises even better cross-business integration, improved efficiency, and closer customer relationships.

But in order to make the Web services model palatable, businesses must be able to leverage existing application assets and expose them as Web services. Businesses want tools and technologies that will reduce the cost, risk, and complexity of moving to this new model.

Web Services Technologies

A variety of technologies that support Web services is starting to appear. The leading candidates include SOAP, SOAP Messages with Attachments, WSDL, UDDI, and ebXML. Currently, these technologies are not available as supported products, but they are maturing quickly.

  • Simple Object Access Protocol (SOAP) technology was developed by DevelopMentor, IBM, Lotus, Microsoft, and Userland. SOAP provides an extensible XML messaging protocol as well as an RPC programming model layer. At this time, more than 50 SOAP implementations are available. The two most popular ones are an open source Java[tm] technology-based implementation from the Apache Software Foundation, and a Microsoft implementation within the .NET SDK. These two are fairly stable, although subtle discrepancies make interoperability challenging. In September 2000, the World Wide Web Consortium (W3C) formed an XML Protocol Working Group to develop a standard XML messaging protocol. The SOAP developers submitted the SOAP specification to the W3C, which is using it as a starting point for the XML Protocol activity. The future W3C XML Protocol (XMLP) will be similar, but not identical, to SOAP V1.1.


  • SOAP Messages with Attachments (SwA) was developed by HP and Microsoft. SwA extends SOAP V1.1 to enable a user to send attachments with a SOAP message. SwA has also been submitted to the W3C.


  • Web Services Description Language (WSDL) technology was developed by IBM and Microsoft. It specifies an XML language for describing a Web service interface. A number of SOAP toolkits include support for WSDL.


  • Universal Description, Discovery, and Integration (UDDI) project is an industry consortium lead by Accenture, Ariba, Commerce One, Compaq, Edifax, Fujitsu, HP, I2, IBM, Intel, Microsoft, Oracle, SAP, Sun Microsystems, and VeriSign. More than 250 companies have joined the UDDI project. The group is developing specifications for a Web-based business registry that can be used to describe and discover Web services. Uddi.org operates a global, public registry called the UDDI Business Registry. At this time, the UDDI V1 specification has been published, and the public UDDI Business Registry is running in production. Individuals can also set up private UDDI registries. Private registry implementations are available from IBM, Idoox, juddi.org, and The Mind Electric.


  • Electronic Business XML (ebXML) is a business-to-business (B2B) XML framework being developed by the ebXML Initiative. The ebXML Initiative is a joint project of the United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) and the Organization for the Advancement of Structured Information Standards (OASIS). The ebXML membership includes representatives from more than 2000 businesses, governments, institutions, standards bodies, and individuals from around the world. A complete B2B framework, ebXML enables business collaboration through the sharing of Web-based business services. It supports the definition and execution of B2B business processes expressed as choreographed sequences of business service exchanges. The framework includes specifications for Message Service, Collaborative Partner Agreements, Core Components, Business Process Methodology, and Registry and Repository. The ebXML Message Service provides a quality of service (QoS) framework layered on SwA. A proof-of-concept interoperability demonstration was presented in October 2000. Participants included Ajuba Solutions, Cisco, Extol, Fujitsu, IBM, IPNet, Netfish, NTT, Savvion, Sterling Commerce, Sun Microsystems, TIE, Viquity, webMethods, XML Global, and XML Solutions. The ebXML specifications were published in May 2001.

Back to Top

The Developer's Dilemma

Although these technologies are rapidly maturing, the nascent Web services developer is pretty much left to his own devices to figure out how to make Web services work. No guidelines exist to help put all of these technologies and standards into perspective. He can use a context-sensitive XML editor to manually define the Web service interfaces, or he can generate them using a SOAP or WSDL toolkit. But how does the developer associate these new Web service interfaces with existing applications and services? And how does he assemble multiple discrete Web services into a composite business service? Interoperability between vendor implementations is still very challenging. The vision of seamless assembly and integration of distributed, heterogeneous Web services is still a distant dream.

Shared Context

The issue is a matter of shared context. Context refers to the things that a Web service needs to know about the service consumer to provide a customized, personalized experience. These things include the identity of the consumer, the location of the consumer, and any privacy constraints associated with the consumer information. If a number of services are aggregated to create a composite business service, these services somehow need to share this context.

Take, for example, shared user identity. A Web service that offers a personalized experience maintains information about the identity of each user. When an individual uses that service, she identifies herself to it. Sometimes the service determines her identity automatically from a cookie maintained on her system. Sometimes she has to enter a user ID and password. Consider for a moment how many user IDs and passwords you have to remember for all of the Web sites you visit. Think about how many more cookies you have stored on your system. And consider how many businesses maintain their own private little databases of information about you.

This discussion has no doubt raised your hackles about privacy and security issues. It also points out a significant challenge facing Web services technology. There are no standards that allow Web sites to share something as simple as user identity. There are, in fact, no standards to represent user identity and no standards to ensure user privacy. How can we achieve the seamless integration of Web services if these services can't share identity, as well as other situational context?

Before the vision of transparent, dynamic interaction of widely distributed, heterogeneous Web services can become a reality, this issue of shared context must be solved. Shared context raises some fairly sensitive issues. The solution can't come from a single vendor. It cannot be proprietary. The solution must be open and interoperable. It must work with any Web service. And it must ensure the security and privacy of individual information.

What Developers Want

So where does this leave the developer? Obviously developers aren't going to sit back and wait for new standards to be developed. They need to start building Web services today. But they want help. They want help understanding how all the different Web services technologies work together. They want guidelines to ensure that Web services are interoperable. And they want to be able to build ?mart?Web services.

Back to Top

Smart Web Services

A smart Web service is a Web service that can understand situational context and share that context with other services. It produces dynamic results based on who, what, when, where, and why it was called. A smart Web service can be aware of a number of situational circumstances, such as:

  • Service consumer's identity, whether it be an individual, a business, or another Web service
  • Role that the consumer is using when the service is invoked
  • Preferences that the consumer may have defined for this type of service
  • Security policies associated with the consumer
  • Privacy policies associated with the consumer
  • Business policies associated with the consumer
  • Physical location of the consumer
  • Type of client device being used to invoke the service
  • Past history associated with the consumer of this service or related services
  • Service-level agreements that exist between the consumer and this service provider

Smart Service Examples

For example, let's say you invoke a smart restaurant finder service to help you select a restaurant. The smart restaurant finder wants to make a recommendation based on where you are, what you like, where you ate last night, and your companions. It makes a big difference whether you're going out with your children or an important prospective client. So the smart restaurant finder considers your identity, your preferences, your history, and your role.

As another example, imagine that there's a power emergency in California. The electric company broadcasts a Stage 3 alert to all power consumers. This notification would launch an energy conservation service, if available, at all consumer sites. In a business facility, the energy conservation service would automatically reduce power utilization by adjusting thermostats and switching off lights according to predefined policies based on parameters such as time of day and day of the week. Some of these predefined policies might be superseded by situational parameters, such as a temporary service-level agreement that's in effect during a particular production run. In a home, the energy conservation service could adjust the thermostat, switch off lights, and impose a volume governor on your teenager's stereo. But the smart service also considers who is physically present in the home. For example, the smart service knows that a baby is sleeping upstairs, and therefore doesn't adjust the thermostat for the upstairs heating zone.

As a final example, consider an order fulfillment process. Imagine that a customer has ordered six different items. At the time of the order, you promised that the goods would be shipped within two days, but as your procurement service places the order with your contract suppliers, it determines that a supply constraint on one of the items will prevent you from shipping the entire order as promised. Your standard policy in a situation like this is to send a partial shipment, but this eats away at your profit margin. What's most irritating is that even if you send multiple shipments, they often arrive all on the same day - and the customer may not care if the goods arrive today or tomorrow. You're looking for an alternative that saves money and still keeps the customer happy.

Rather than automatically sending the goods in multiple shipments, a smart service would determine a course of action by considering the customer's profile and past history, and weighing the profit impact of expediting missing components or reshuffling factory work orders. The service may also take into consideration other parameters, such as cost of inventory, cost of space, estimated shipping charges, and expected delivery times. It might send an inquiry to the customer -- by e-mail, short message service (SMS) message, automated voice response message, return fax, or some other delivery mechanism as defined in the customer profile -- requesting a decision:

  1. Please accept this coupon for your inconvenience; the goods will be shipped when the order is complete, which is currently estimated to take five days.
  2. Ship the order in pieces as they become available.

Making Web Services Smarter

Anyone can build context-sensitive Web services. Certainly many Web sites offer highly customized content based on who you are and your past history with the site. But context sensitivity is only half of the problem. A smart service must also be able to share context with other services. Unfortunately, no standards or conventions exist for representing this context. Every site that provides a personalized experience maintains identity and history information in a proprietary format.

What's needed is a new set of standards ?an XML framework -- to represent contextual information. What's also needed is an open architecture that defines how services use this information and assures service interoperability.

Back to Top

An Open Software Architecture for Interoperable, Smart Web Services

Sun has defined an open software architecture to support interoperable, smart Web services. The Open Net Environment (ONE) software architecture addresses important issues, such as privacy, security, and identity. It defines practices and conventions to support situational context, such as client device type and user location. And it supports systems that can span multiple networks, including the traditional Web, wireless Web, and home networks. The architecture is designed to ensure that smart Web services, developed using any tool, running on any platform, can seamlessly interoperate.

The ONE architecture includes a developer model that provides guidelines for building Web services. The principles defined with the developer model apply to any programming language, but the ONE developer model specifies programming practices in terms of Java APIs.

The ONE architecture is based on a recommended set of open and pervasive standards, technologies, and protocols. While defining the architecture, Sun identified additional standards that are needed to complete the architecture. Sun is working with other companies to foster the development of these new standards through appropriate standards bodies and industry initiatives, such as W3C, OASIS, IETF, UDDI, ebXML, and the Java Community Process program. In particular, Sun is working with others to foster the development of new standards to support shared context.

Core Standards and Technologies

At its essence, the ONE architecture is based on XML and Java technologies and core infrastructure standards. Sun's technical philosophy is to use common, pervasive technologies ?to use what is available, and not reinvent the wheel. The core standards used with the architecture are:

  • XML standards and initiatives, including:
    • Core W3C XML Recommendations (XML, DOM, XML Namespaces, XSLT, XPath, XLink, and XPointer)
    • Development community XML parser, SAX
    • Presentation formats (XHTML, WML, and VoiceXML)
    • XML schema systems (DTD, XML Schema, RELAX, and TREX)
    • XML messaging systems (XMLP, SOAP, SwA, and ebXML Message Service)
    • XML registries and repositories (UDDI Business Registry, ebXML Registry and Repository, and OASIS xml.org)
    • XML service description languages (WSDL and ebXML Specification Schema)
    • XML management information interchange frameworks (DMTF CIM and WBEM)
    • B2B XML frameworks (ebXML)
    • XML security systems (W3C XML Signature, W3C XML Encryption, and OASIS SAML)


  • Java technologies, including:
    • Java 2 Platform, Enterprise Edition (J2EE[tm]), Java 2 Platform, Standard Edition (J2SE[tm]), and Java 2 Platform, Micro Edition (J2ME[tm])
    • Mobile Information Device Profile (MIDP)
    • Java Card[tm] API, Java Servlet, and JavaServer Pages[tm] (JSP[tm]) technology
    • Java API for database access (JDBC[tm] API)
    • Java APIs for XML (Java API for XML Processing, Java API for XML Data Binding, Java API for XML Registries, Java API for XML Messaging, and Java APIs for XML-based RPC)


  • Core infrastructure standards, including:
    • Lightweight Directory Access Protocol (LDAP)
    • Secure Sockets Library (SSL)
    • Hypertext Transfer Protocol (HTTP)

ONE Software Architecture Functional Overview

The ONE architecture is a living system, and it will continue to grow as new technologies appear that might enhance the environment. The illustration in Figure 1 shows a high-level, functional overview of the major components of a Web services architecture.

A functional overview of the major components of a Web services architecture.
Figure 1: A functional overview of the major components of a Web services architecture.
Service Creation and Assembly

Across the top of the illustration is a box entitled Service Creation and Assembly. This part of the architecture represents the tools used to develop systems based on the Web services model. A Web service is often made up of a number of discrete service components that instantiate various bits of content, business logic, and applications. Therefore, the service development process involves two distinct steps.

The first step involves creating discrete services, which the ONE architecture refers to as micro services. The second step involves assembling the micro services into composite services, or macro services. Developers create micro services using integrated development environments, code generators, XML editors, and authoring tools. (More information about the micro service development model appears later in this paper.) Service assemblers use business process modeling tools, workflow tools, scripting engines, and other types of ?lue?tools to assemble macro services. Assemblers also use policy tools to define business rules, security policies, and context-sensitive policies that can dynamically change the macro services process at runtime.

Web Services

Once fully tested and complete, the Web services are ready to be delivered to a deployment platform, and the policies and rules are ready to be deployed to an open directory that manages identity, security, and policy.

The Applications & Web Services box in Figure 1 represents the deployed Web services, which can be deployed on any type of platform or intelligent device, from a tiny smart card to a massive mainframe. What appears to the user as a single Web service might actually be a macro service composed of a number of micro services. The discrete components of a macro Web service may be deployed on any number of physical platforms. Micro services can be assembled, configured, and reconfigured at any time.

Deployment Architecture

The remainder of Figure 1 represents the ONE software deployment architecture. Working from left to right, the diagram depicts service consumers interacting with service delivery facilities. A service consumer may be a human interacting through a variety of devices, another application, or a Web service. Service delivery facilities provide basic connection, location, discovery, and communication functionality. This part of the architecture includes all types of user and business portals that enable Web users, wireless users, voice users, and external business systems to invoke services. Service delivery facilities direct each request to an appropriate Web service.

A Web service executes within some type of service container, such as a Web or application server. The service container provides a runtime environment for the service and persistence and state management services as well as process management facilities, which manage service workflow and event processing. Service integration facilities enable the service to access other Web services and resources such as databases, files, directories, and legacy applications.

The entire environment runs on a service platform, which provides access to local operating system services such as databases, directories, and messaging services. Identity and policy facilities within the service platform manage the environment and ensure security. The service platform resides on an operating system or virtual machine, providing access to hardware, storage, and networks. Any kind of processor can act as a service platform, from a smart card to a mainframe.

Adding Smarts to the System

The illustration in Figure 2 shows the Web services architecture with additional functionality to support context sensitivity. The smart delivery facilities can aggregate, customize, and personalize service results based on context. The smart policy facilities coordinate activities according to policies associated with identity, context, and roles. The smart process facilities use context to affect business service workflow. And the smart management facilities ensure privacy, security, and access rights based on specific situations as defined by the context.

Making Web services smarter.
Figure 2: Making Web services smarter.

Web Services Processing Model

Figure 3 shows an overview of the processing model based on the smart Web services architecture.

Figure 3: Smart facilities affect Web service processing.
Figure 3: Smart facilities affect Web service processing.
[Click image for larger view]
Preparing a Web Service

Smart management facilities manage, monitor, and maintain a Web service to:

  • Ensure that the service is properly registered and can be located through one or more service registries
  • Ensure that appropriate pay-per-use or subscription agreements are in place and properly executed
  • Coordinate the provisioning of a service and ensure that the service performs according to a minimum QoS as determined by service-level agreements or other criteria
  • Obtain management and runtime policies from the smart policy facilities

Smart policy facilities manage and interface with the various directories and repositories that contain the policies and business rules that affect service processing.

Processing a Service Request

A service request comes in through a delivery channel, such as a Web server, wireless server, or business portal. Smart delivery facilities capture the current context of the request; record information such as location, role, and time; and pass the request to the service.

Service Process

Smart process facilities manage the choreography of a macro service. Based on the contextual assignments and policies and business rules defined for the service, smart process facilities ensure that the appropriate micro services are invoked in the proper sequence. The services use integration and resource access engines to invoke other services and access databases, files, legacy applications, and other resources.

Delivering a Service Response

When processing is complete, smart delivery facilities tailor a response for the consumer using personalization and contextual sensitivity engines. The final response is delivered back to the user through appropriate delivery channels.

Standards Backplane

The illustration in Figure 4 shows the Web services architecture overlaid with many of the standards and technologies that provide the foundation for the ONE architecture. Not all of these standards are required in every case. The standards are provided as a guideline and aid for interoperability.

Standards ensure interoperability.
Figure 4: Standards ensure interoperability.
Smart Delivery Standards

Smart delivery facilities support a variety of client devices using a number of device-specific presentation formats, including HTML, XHTML, WML, and VoiceXML.

  • Hypertext Markup Language (HTML) is the most commonly used technology for presenting electronic information to browser users and is an effort of the W3C.


  • XHTML is an XML-compliant variant of HTML and is an effort of the W3C.


  • Wireless Markup Language (WML) is the presentation format used on many WAP-compliant wireless devices, such as mobile phones, and is an effort of the WAP Forum. The WAP Forum recently adopted a subset of XHTML, known as XHTML Basic, as a follow-on to WML.


  • VoiceXML allows for the creation of audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and mixed-initiative conversations. Its major goal is to bring the advantages of Web-based development and content delivery to interactive voice response applications. VoiceXML is a joint effort of the VoiceXML Forum and W3C.

Smart delivery facilities also manage content transformation, generally using XML and XSLT.

  • eXtensible Markup Language (XML) is a platform-independent, language-neutral data representation format that forms the underpinning for most efforts focused on Web services and e-business. Applications manipulate XML using either the Document Object Model (DOM) or the Simple API for XML (SAX). DOM is a platform-independent, language-neutral API that allows programs to dynamically access and update the content, structure, and style of XML and HTML documents. It provides in-memory, tree-structured access to XML data so that the entire structure of a document is accessible for reading and writing. SAX provides an event-based, serial XML parser. XML and DOM are work efforts of the W3C, and SAX is a collaborative effort of the XML-DEV discussion group.


  • eXtensible Stylesheet Language Transformations (XSLT) is a language for programming the transformation of XML documents to a variety of formats, such as XHTML, WML, VoiceXML, other XML documents, or to other data formats. XSLT is a work effort of the W3C.

A Web service exposes an XML interface, which communicates using an XML messaging protocol such as SOAP, SwA, ebXML Message Service, or XMLP. The format of the XML message should be defined using an XML schema, such as W3C Document Type Definition (DTD), W3C XML Schema, RELAX (an emerging ISO standard), or TREX (an emerging OASIS standard). The message schema should be registered in a schema registry, such as xml.org. The service interface can also be described using a Web service description language, such as WSDL. The semantics of the Web service may be described using business modeling tools and registered in a semantic service registry such as the ebXML Registry and Repository. The business that offers the service should register it in the UDDI Business Registry.

Service Container

The service container provides the runtime environment for Web services. The type of service container used depends on the type of platform hosting the services. The ONE architecture provides recommendations for both servers and devices.

  • On a server, the recommended service container is a J2EE application server. Web services can be implemented as Java servlets, JSP pages, and Enterprise JavaBeans[tm] (EJB[tm]) components. Server-based Web services will generally need to support high-volume scalability requirements. A J2EE application server transparently manages much of the complexity associated with scalable application systems. A J2EE container automatically manages multithreading, session state, transactions, security, and persistence for the Web service.


  • On a device, the recommended service container is J2ME technology. It provides a deployment platform for Web services on consumer devices such as wireless phones, PDAs, televisions, automotive information systems, and a wide variety of other consumer and embedded devices. A J2ME device is defined in a profile, which includes a Java virtual machine and a collection of APIs that provide access to capabilities of the underlying device. Profiles provide the necessary abstractions, allowing transparent deployment of services and content across an extremely wide variety of networks and device types. Technologies currently available include the Mobile Information Device Profile (MIDP) for wireless phones and PDAs, and the Java TV[tm] API for broadcast televisions, set top boxes, and personal video recorders. These platforms provide application models that enable services to access unique features of devices, including storage, user interface, and personalization services.
Smart Management

System, network, and application management works as a distributed application involving management control services and numerous management agents deployed across each managed node in the environment. The agents on systems, devices, and applications collect information as defined by the Simple Network Management Protocol (SNMP) standard and relay this information to the control services. Traditionally, most management systems require a homogeneous infrastructure to effectively manage the entire environment. This approach has led to large, expensive system management frameworks that lock customers into a single vendor for all aspects of management.

The Common Information Model (CIM), defined by the Distributed Management Task Force (DMTF), enables a new generation of system management solutions based on modular and interoperable management services that communicate SNMP information using XML. CIM defines the schema and protocol standards that enable the design of Web-Based, Enterprise Management (WBEM), which works independently of the underlying design of other services and agents with which they interact.

In this model, system and network equipment will include its own management agents, and a wide variety of companies will compete with modular Web services targeting specific aspects of management. So instead of customers being locked into a single vendor, they will be able to choose best-of-breed vendors for each aspect of management.

Web services can also be managed using this model. Developers can instrument a Web service using Java Management Extensions (JMX[tm]) technology or the Java WBEM Services API and create standard interfaces for managing deployment, health, and performance of the service. CIM enables this work to be done by the people who are in the best position to optimally implement these features ?developers. As Web services are deployed, Web-based management services will be able to use these same standards to discover services and manage them through their agents.

Because these are well-defined services, companies will be able to outsource aspects of their system and network management to third-party management service providers (MSPs) that can perform those same tasks over the network. Since the services are modular, customers can determine on a case-by-case basis which parts of management they want to retain in-house, and which parts they would like to outsource.

Smart Process

Smart process facilities enable context-sensitive service choreography. Context-based smart processing can change the outcome of a macro Web service by dynamically altering the choreographed sequences of micro Web service invocations based on the context of the request, such as geography, jurisdiction, or the maturity of the business relationship.

  • ebXML. In an ebXML environment, a B2B business process is expressed as a choreographed sequence of business service exchanges. Each basic service exchange is referred to as a business transaction. A business service is typically high level, such as an ordering service or billing service. But behind the scenes, that single business service is recursively composed of a number of lower-level services, such as a product look-up service, pricing service, and currency conversion service.


  • Business Process Modeling Language (BPML) is a meta-language for the modeling of business processes. BPML provides an abstracted execution model for collaborative and transactional business processes based on the concept of a transactional finite-state machine. BPML is being developed by the Business Process Management Initiative (bpmi.org), a group of more than 100 software vendors, consulting firms, and industry organizations.
Smart Policy

A Web service can use a policy engine to dynamically adapt processing and results according to rules that consider user identity, authorization levels, and other contextual information. The context-oriented standards have yet to be defined, but a number of standards and proposals exist for security. User and policy information can be maintained in an open directory accessed using LDAP. Kerberos and Public Key Infrastructure (PKI) provide services for authentication, authorization, privacy, and data integrity. In addition, the OASIS Security Services Technical Committee is working on the Security Assertion Markup Language (SAML), an XML framework for exchanging authentication and authorization information so that cross-enterprise transactions can be made more secure using open technology. This framework will provide a request/response protocol for accessing authentication and authorization services, encode requests for and assertions of identity and entitlement in XML form, and supply bindings of security messages to various transport and messaging protocols. SAML is based on two proposed security specifications: the Security Services Markup Language (S2ML) and AuthXML. The S2ML specification was written by Bowstreet, Commerce One, Jamcracker, Netegrity, Sun Microsystems, VeriSign, and webMethods. The AuthXML specification was written by an industry consortium led by Outlook Technologies.

Back to Top

Web Services Developer Model

The ONE Web services developer model provides recommendations for building Web services using XML and Java technologies. The Java platform includes native support for XML. The Java API for XML Processing (JAXP) provides a native Java interface to DOM, SAX, and XSLT. Additional Java APIs for XML are in various stages of development through the Java Community Process (JCP) program:

  • The Java API for XML Data Binding (JAXB) binds XML data to Java code. A developer uses JAXB to compile XML schema information into Java objects. At runtime, JAXB automatically maps the XML document data to the Java object, and vice versa.
  • The Java API for XML Messaging (JAXM) provides a native Java interface to XML messaging systems, such as the ebXML Message Service, XMLP, and SOAP.
  • The Java API for XML Registries (JAXR) provides an interface to XML registries and repositories, such as the ebXML Registry and Repository, and the UDDI Business Registry.
  • The Java APIs for XML based RPC (JAX/RPC) will provide direct support for an RPC programming convention for XML messaging systems, such as SOAP and XMLP.

The Anatomy of a Web Service

Figure 5 shows a micro Web service from the developer's perspective. A Web service consists of a Web service interface and one or more service components. The Web service interface manages and manipulates XML messages. Service components contain business logic that implements the service. Business components frequently interact with external resources and services through a variety of integration services.

Figure 5: Current and future Java APIs.
Figure 5: Current and future Java APIs.
[Click image for larger view]
Web Service Interface

A Web service communicates by passing XML documents over standard Web protocols, such as HTTP. The Web service interface, which runs as a JSP page or servlet running within a Web server, implements the code that produces and consumes these XML messages. The ONE architecture recommends four types of XML messaging systems: SOAP, SwA, ebXML Message Service, and XMLP.

  • SOAP, as previously mentioned, is a lightweight, extensible XML messaging protocol. A SOAP message is an XML document. The SOAP header provides message directives, and the SOAP body contains message data. SOAP supports an optional RPC programming convention that automatically binds input and output parameters to XML elements in the SOAP message body.

    Since an XML document cannot contain another XML document, SOAP cannot transport a complete XML document, such as a purchase order. It also does not support attachments, such as multimedia files or other nonXML data. SOAP does not provide a QoS framework. Java tools for implementing SOAP interfaces are available from the Apache Software Foundation and many other sources.


  • SOAP Messages with Attachments (SwA) extends the SOAP protocol by packaging SOAP messages in MIME multipart/related envelopes. An SwA message can transport XML elements, XML documents, and nonXML data. SwA supports an RPC programming convention, but does not provide a QoS framework. Java tools for implementing SwA interfaces are available from the Apache Software Foundation and many other sources.


  • ebXML Message Service, as previously mentioned, is an XML messaging service designed to support the requirements of B2B e-commerce. The ebXML Message Service extends SwA by adding a QoS framework that ensures reliable and secure message delivery. An ebXML message can transport any number of XML documents and nonXML attachments. However, the ebXML Message Service does not support an RPC programming convention.


  • XML Protocol (XMLP) specification is under development. Its stated goal is to be an extensible, general-purpose XML protocol. The XMLP Activity is using the SOAP V1.1 specification as a starting point.

A service consumer invokes a Web service by posting an XML message to the URL that represents the JSP page containing the Web service interface. The service interface receives the XML message and extracts the XML document. Currently, this process is performed using SOAP or ebXML APIs. In the future, developers will use JAXM or JAX/RPC to more efficiently process XML messages. The service interface takes XML documents and maps XML data into Java object data. Today, developers can use JAXP to process XML documents. In the future, they will be able to use JAXB to automatically bind documents to Java objects.

Capturing Context Information

The Web service interface also captures as much context information as is available. User identity might be captured by retrieving a cookie from the client's system or by challenging the user for a user ID and password. Once the service interface has determined identity, the service can query its proprietary user history files to retrieve additional context. Sun is collaborating with partners to foster a standards effort that will define standard frameworks for identity and context. Details of the context framework have yet to be defined, but it is expected that a new set of standard APIs will be developed to access user context.

Business Logic

Once the service interface has mapped the XML data to Java data and captured the context, it uses servlet facilities to perform the usual session management services, and then it invokes the business logic, which performs the actual service. The business logic is implemented as an EJB component, or possibly a servlet for light-duty applications. The business logic component interfaces with a workflow engine that choreographs the composite business transaction, and a policy engine that applies appropriate business rules according to the situational context. The specifics of this process have yet to be defined. No doubt, ebXML, BPML, and the OASIS security services will play a role.

Integration Services

The business logic component interfaces with various resources. The JDBC API provides access to databases; J2EE Connectors and the Java Message Service (JMS) API can be used to access other application systems; and XML messages are used to interface with other Web services. Currently, developers construct XML messages using SOAP and ebXML APIs. In the future, they will use JAXM or JAX/RPC to more easily manipulate XML messages.

Returning Results

When the business logic component has completed its work, it returns a Java result object to the JSP page or servlet interface component. The interface component maps the results from the Java object to the output XML document using JAXP or, in the future, JAXB. The interface component can then use the context to further customize the response document as appropriate. When ready, the response is packaged back up into a XML message and returned to the requestor.

Back to Top

Summary

The ONE architecture is designed to help developers be successful building Web services today. The Web services technologies currently available are still rudimentary, but that fact shouldn't stop developers from venturing into this exciting new territory. Web services represent the next generation of software. This architecture provides a guideline to help developers put the myriad XML standards, technologies, and initiatives in perspective. The developer model provides a foundation for development efforts, indicating which technologies and APIs should be used for each facet of a Web service.

Meanwhile, Sun is working with the community to foster new standards and technologies that will enhance and enable the Web services model. Initial topics to be considered include the creation of a standard XML framework that:

  • Represents personal, corporate, and service identity
  • Can be used to specify privacy policies
  • Handles context descriptions
  • Enables businesses to unambiguously identify the business documents that must be exchanged in a particular business context

Back to Top

Resources

For more information about the products and technologies mentioned in this white paper, please visit:

Back to Top