 |
|
|
Abstract
There is huge amount of hype around Web services and its standards such as SOAP, WSDL and UDDI. Although they are currently being used successfully, they have well known limitations that prevent them being used more widely by business.
This paper helps by providing an overview or "scorecard" of Web services standards from a business perspective.
The paper: explains the different areas of Web services that need standardization before businesses can realize the maximum benefit that Web services technology will bring; describes the benefits that standardization of each area could eventually bring; and, identifies and assesses the major Web services standards that have been developed in each area.
As a result of reading this paper, the reader should: better understand the benefits that Web services can bring to a business’ use of Information Technology; understand the limitations of existing Web services solutions caused by lack of standardization; and, be able to better identify those solutions that enable a business to realize the benefits of Web services now, whilst minimizing the costs associated with the changes arising as Web services standards evolve.
Keywords
Table of Contents
Web services are driven by standards. Understanding how Web services standards will evolve should make planning how to use Web services, both now and in the future, easier.
This presentation provides an overview of the Web services standards required for business. It is a much shortened version of the 75+ page Business Web Services Scorecard paper - see Section 6, “More Information” for more information.
As well as providing an overview, the paper also summarizes the main standards that are being developed now identifying gaps where they exist as well as suggesting the type of architecture you should build or buy given the current state of standards development.
The remainder of this paper covers the following topics:
Web Services Basics Section 2, “Web Services Basics” and Why Standards Section 3, “Why Standards” – This provides a level-set of what Web services are and the importance of developing and adopting Web services standards
The Web Services Standards Required Section 4, “What Web Services Standards are Required” in the following areas: Complex Web Services; Definition Languages; Semantic Definitions; Profiles, Policies and Agreements; Web Services Management; Registries; and Program APIs
What should you do now? Section 5, “What Should You Do Now” – Given the background on Web services standards, this section describes an approach that will help you manage implementations that use Web services as your business, your business partners and Web services standards evolve.
Although Web services have been around for several years, using Web services for business is different than using Web services for Remote Procedure Calls (RPC).
Figure 1 shows the fundamentals of what is required when sending data between businesses in the real world. Essentially a (paper) document is put in an envelope that is then addressed to create a letter which is given to a postal system for delivery.
This system only works because:
The sender and recipient of the message both understand the document since it is written in a language that they share and is about a topic they both understand – in this case the acceptance of a quotation
The recipient of the letter, once they have understood what it contains, knows how to respond
Conventions have been adopted over many years for what an address looks like and how the actual written address can be resolved to the physical location
A Postal System exists that understands what to do with an addressed letter and can deliver it to the correct location
When using Web services for business, exactly the same is required, i.e. sending pieces of business information to integrate systems within a business as well as connecting to businesses partners outside. This means that the same problems need to be solved – see Figure 2.
Electronic message delivery is similar to real world letter delivery except that the document and its envelope are electronic rather than paper and the delivery system is the web rather than a postal service. Also, if Web services are being used, then the envelope will be SOAP rather than paper.
However the critical difference between electronic and real-world delivery is that computers need to understand what is going on rather than people, but computers are dumb. This means that you need to be much more rigorous in understanding how the connection would work so that you at least stand a chance of realizing interoperability. In summary, you have to solve the same problems as you do in the real world:
The sender’s software and the receiver’s software must both understand the (XML) business document – i.e. its structure and semantics
The recipient, once they have understood what the message contains, must know which type of message, if any they should send in return
Conventions are needed that define how to address a SOAP envelope so that the destination and purpose of the message is clear, and
A delivery system must exist that works acceptably securely and reliably so that the participants can use the system with confidence.
However, once these problems are solved, then Web services should offer significant cost savings and improvements in the speed and accuracy with which business can be done.
Making this happen is where standards come in. Standards are important for two reasons: interoperability and lower cost.
In the past, standardization of the railway gauge in the 19th century resulted in an explosive growth of railway systems. Only when there was a standard railway gauge could locomotive and rail car manufacturers build products that could run anywhere. As a result, costs, both for purchase and operation were lowered.
In the 1980s and 90s standardization of PC hardware and software resulted in explosive growth of personal computing. Only when IBM and Microsoft created the De Facto standard for PCs were many different organizations able to create applications that could run on any PC no matter whom the manufacturer was.
In the late 1990s and now, standardization of protocols for accessing the web is leading to explosive growth in the Internet. If standards did not exist for HTTP, HTML and SMTP, then the web would probably not exist in the way we know it.
In the present and the near future, standardization of Web services technology should lead to explosive growth in using the web for integrating businesses together as businesses will be able to easily and automatically connect to one another.
But, all standards that are needed to make this happen do not currently exist. However, waiting for them to exist will lead to missed opportunities as just about any Web services and eCommerce vendor will confirm – there are many cases of significant business benefits that have arisen from using Web services.
But if you don’t want to wait for Web services standards to mature, then understanding where Web services and their related standards are heading will help you develop practical plans on what to do now.
The Web services standards that are needed for business are described in Figure 3.
They include:
Complex Web Services Section 4.1, “Complex Web Services” – this covers SOAP extensions and modules for the secure, reliable sending of messages over insecure networks such as the web
Definition Languages Section 4.2, “Definition Languages” – these are languages that are used to define things that are needed to make Web services work including, business documents, business processes, choreographies as well as the Web services themselves
Semantic Definitions Section 4.3, “Semantic Definitions” – these are definitions of actual things e.g. an order or an order management process. They define the structure of the things, e.g. the structure of an order document, as well as what things mean. Semantic Definitions are created using Definition Languages.
Profiles, Policies and Agreements Section 4.4, “Profiles, Policies and Agreements” – these are descriptions of how to use Web services standards in combination or in a specific context, such as a vertical industry or geographic region
Web Services Management Section 4.5, “Web Services Management” – these are techniques that allow Web service implementations to be managed and controlled remotely
Registries Section 4.6, “Registries” – these are stores of information about Web services, their definitions and implementations, and
Program APIs Section 4.7, “Program APIs” – these are the APIs that allow applications to access middleware that provides Web services functionality
Within each of these areas, there are several different items that benefit from having standard ways of defining them as illustrated by Figure 4.
They include:
The business Documents, e.g. an order and the structure of the Messages in which they are transported
Message Delivery, including securing messages to make sure that they are not changed and that their contents are kept private
Choreographies, which define the sequence in which messages are exchanged between the roles involved
Roles – which identify the different types of activity that a business can take when interacting with other businesses, e.g. a buyer or a seller
Business Processes – which describe the way in which systems and users within a business are used together in order to support an internal business process such as handling an order from beginning to end
Services – which are pieces of functionality, often implemented as a Web service, provided by a business that does something useful
Interfaces – which define the types of messages, security, reliable delivery support provided by a service
Transformations (or maps) – these are rules for converting messages and documents from the format generated by the sender into the format required by the receiver of the message
Businesses – definitions of information about a business to provide, for example, information about a contact that can help resolve problems if they occur
Users – often individual users need to get involved in business processes as well as being the target for some of the messages that are sent between businesses
Profiles and Policies – with the choice of standards available, an individual implementation needs to decide which of the alternative standards they will actually follow, for example: must messages that they receive be digitally signed, and will the messages they send be sent using a reliable messaging protocols
Agreements – given that businesses can have different policies, businesses must reach agreements out of all the alternatives they could adopt so that each side knows what the other expects.
Complex Web Services are a set of SOAP features that provide secure reliable delivery of messages. They cover several different areas:
Message Metadata – this includes: message identification and correlation; references to agreements; and, references to the choreography being followed
Message Packaging – this includes: the base SOAP specifications; bindings of SOAP to different transports, e.g. HTTP; handling of attachments and multi-part documents; and message manifests which are table of contents for the message
Message Addressing – this includes: logical addresses that specify who should receive the message; physical addresses that specify where the message should go; return addresses that specify where the response to a message should be sent, e.g. an error; and, fixed routing that specifies a fixed path through a set of SOAP nodes that a message should follow
Message Delivery – this includes: reliable messaging which assures a message is delivered once and only once; delivery receipts which is a receipt that can later be used to prove that the message was actually received; message expiry which tells the message recipient that the message should not be processed after some point in time; message sequence preservation which tells the message recipient that the messages should be processed in the sequence they were sent; and two-phase commit which is a technique for ensuring that the sender and receiver keep the information they keep about a transaction in step
Message Security – this includes: digital signatures which can be used to make sure the message or business document has not changed; encrypted messages which ensure that only people and processes authorized to see the contents of a message or document can do so; authentication which can be used to make sure that the sender of a message is who they say they are; authorization which can be used to verify that the sender of a message is allowed to make the request that sending of the message implies; single sign-on which uses Web services technology to allow a user to sign on once to an application then access many different applications; and, security management which involves managing the digital certificates and other information required to send and receive messages securely
Message Errors – this includes: error classification which provides standard ways of identifying common application-independent errors so that common processing for them can be provided; and test messages which can be used to verify that the connections between businesses, systems and applications are working correctly before going live.
So what standards exist to address Complex Web Services?
ebXML Messaging [ebMS] focuses on the exchange of messages between businesses and provides, in a single specification, standards for most of the topics described above. However, ebXML Messaging was developed before the main Web services standards activities started, which means that it is not completely compatible with the latest set of Web services specifications.
ebXML Messaging is also not universally supported by vendors, for example IBM and Microsoft do not support it although Sun and other vendors do even though ebXML Messaging was a standard developed by OASIS and [UN/CEFACT]that has been adopted by several major vertical industry groups such as the Auto Industry Action Group [AIAG]. The main reason for lack of adoption by some vendors is probably because ebXML Messaging focuses on Business to Business (B2B) integration and the fact that it includes most of the requirements in one specification. This makes ebXML Messaging harder to use for developing applications that are not B2B and don’t need all of ebXML’s functionality.
WS Security [WS-S] is the main activity that is addressing the security of Web services and includes, support for privacy, authentication and encryption. It is also widely supported by all the vendors.
There are two nearly identical specifications that both address the reliable delivery of messages: WS-Reliability [WS-R] which is being developed by Fujitsu, Sun, Oracle, and others in OASIS; and WS-Reliable Messaging [WS-RM] which was developed by IBM, Microsoft and BEA which has not been submitted to any standards organization. They are both similar to each other as well as to the reliable delivery part of ebXML Messaging.
There are also several other specifications that describe how to do correlation, two-phase commit, message metadata, addressing, etc. For more details see the full Business Web Services Scorecard paper [BWSS].
The net of all this is that there is a high degree of confusion and lack of clarity on the standards needed for the secure, reliable delivery of messages. As a result ebXML Messaging will likely coexist with several similar Web services based standards for a number of years. There is also, the slightly crazy situation of some directly competing standards, e.g. WS Reliability and WS Reliable Messaging.
It is interesting to understand why there are competing initiatives such as WS Reliability and WS Reliable Messaging. The main reason is because of the "old" and the "new" ways of developing standards.
The old way of developing standards involved a group of vendors identifying an area that needed standardization. They then created an activity in a standards group, such as the IETF, OASIS or the W3C, which was then followed by a period of up to two years while the standard was developed, published in various draft forms and eventually finalized and approved. Finally, if the standard was useful, vendors would provide support for the standard and their customers would start using it.
The new way of developing standards is different as usually a small group of vendors develop a specification in private and then publish it. The same vendors then set up an activity in a standards group to which they submit their specification so that it can be enhanced with other vendors who join the group. As a result the specification evolves, usually quite rapidly until the specification is finalized and published.
So which approach is best?
The old way is usually slow – typically two years – but thorough as you get more people and companies involved. It also creates a level playing field, as everyone involved understands the specification at the same time and at the same rate.
By comparison, the new way is faster, as there are fewer people involved although less rigorous. However it is very advantageous to the original inventors, in terms of "time-to-market", as they have inside knowledge of what the specification contains and can start developing products that support it in parallel.
Also since, the are submitting a specification developed outside a standards group they can often preserve some of their Intellectual Property rights in the specification.
So the new way is the better way for vendors especially if the most direct competition of the original specification developers is excluded from the activity – which often happens.
Definition Languages are XML based languages used to create definitions of the "things" used by Web services. Standard Definition Languages are useful because the information they define needs to be shared and also because it makes it easier for vendors to develop tools that support the language.
Definition Languages are needed to support most of the information that was discussed earlier – see Figure 4.
So what standards exist?
XML and particularly XML Schema, are the definitive standard for defining Business Documents although some groups, such as the Universal Business Language [UBL] initiative in OASIS, are profiling how to use XML schema when defining Business documents.
XSLT is also a well-established standard for doing transformations of XML documents from one format to another although XSLT implementations usually keep the complete XML document in memory which limits its applicability for handling XML business documents that can sometimes be several Mb in size.
Vertical industry standards groups have created several different standards for the description of businesses although some are beginning to coordinate their activities through UDDI
WSDL is the standard for Web service definitions although it needs to be extended to support the additional SOAP features required to support Complex Web Services.
The Business Process Execution language for Web Services [BPEL] is likely to become the standard for developing a business process definition language with WS Choreography [WS-CHOR] as the leading standard for choreography definition.
The net of all this is that data definition language standards are in good shape in the form of XML, but the others need more work although good progress is being made
Semantic definitions are the actual definitions of business "things", e.g. the definition of an Order or an Invoice, how to place an order, etc. They are created using a Definition Language. Standardized definitions of these objects make interoperability easier since there should be no information loss, as transformations of the documents will not be needed.
There are three main types of semantic definitions that need to be standardized:
Business Documents – as both the sender and receiver of messages must understand what each field in the business documents mean
Choreographies – since the sender and receiver of a message need to know what sequence messages should be exchanged
Service Interfaces – since the sender of a message needs to know which service to send messages to and how the service will behave when the message is received
There are literally hundreds of different vertical industry XML business document definitions. This presents a problem for interoperability since few businesses can afford to support more than a few different document definitions.
For the really big businesses such as Walmart or GM, this is rarely a problem as they can often dictate to their suppliers the format and structure of the documents that they will use. For the next level down in the supply chain this is also not much of a problem as they can probably afford the cost of providing support.
However for smaller suppliers further down the supply chain, it is much harder as they often take part in multiple different industries with several different customers while lacking the financial and technical resources required to support all the different formats they are being asked to.
The net of this is that, without standardization of business documents in particular, big businesses will not realize the financial and operational benefits of a fully electronic supply chain to the degree that they hoped.
However there is some good news in that the Universal Business Language [UBL] activity in OASIS is building XML business document definitions with the support of businesses and people in many different industries.
Many vertical industry groups, such as [RosettaNet] and others, have developed standard choreography definitions for use within their industry and have achieved success. However, these efforts suffer from the same problems as business document definitions as it will be hard for smaller businesses to support a wide variety of different choreographies.
There has also been no standardization of WSDL definitions of service interfaces. This means, for example that a supplier who works with multiple buyers will probably have to build separate interfaces for each buyer they integrate with electronically.
The conclusion from this is that the only significant standardization effort is around the business documents required for B2B. This is, along with lack of widely adopted standards for security and the reliable delivery of messages, probably the main reason why Web services are primarily being used inside a business rather than between businesses where interoperability and reaching agreement on how to interact is less of a problem.
Profiles define standard re-usable definitions of how to use standards in context or in combination. Policies further define how an individual implementation will use profiles, and agreements define how partners work together.
For example a profile could define how the members of the chemical industry would interoperate with each other – see example below.
Policies describe how an individual implementation would use a profile. For example even if a profile existed that described the recommended way in which businesses in the chemical industry would interoperate, individual businesses participating in the industry would have to decide, for example, which variant of a business document they used, to handle different legislative requirements, as well as which digital certificates they used (if any) for signing documents.
Finally, some businesses could support multiple different ways of supporting a business function, such as accepting an order – one that is generic and one that is specific to the chemical industry. In this case the sender and receiver of the message would need to agree on which of the alternatives they would use. However automated agreement, which is quite possible, will require negotiation protocols to make them work.
The different types of profiles needed include:
Basic Profiles, which describe how the basic Web services standards such as SOAP, WSDL and UDDI are used together
Complex Web Service Profiles, which define how SOAP is used with security standards and reliable messaging standards for the secure, reliable delivery of messages
Document Profiles, which define how a business document is used in a particular context, for example, how Invoices, in the chemical industry in Germany should look
Choreography Profiles, which describe how a choreography can vary depending on the context
Message Profiles, that define how business documents and attachments, are combined in a SOAP message with standards for security, reliability etc, and
Service Profiles, that describe how a service should be used in a particular context
An example of these different types of profiles and how they work together is illustrated by Figure 5.
This figure shows an example of how a profile could be built for a specific industry. Most of the profiles are built on earlier profiles, for example the "Complex Web Service" (CWS) profile is built on top of the WS-I Basic Profile [WS-BP], and the "B2B" profile is a combination of several different profiles for security, reliability, etc.
Figure 5. Example of how profile definitions are used in combination
Most work on the development of profiles is being done by the Web Services Interoperability Organization [WS-I] that has published a Basic Profile version 1.0 [WS-BP] specification that describes how SOAP 1.1, WSDL 1.1 and UDDI 2.0 should be used together (the top left hand box in Figure 5). The WS-I is also developing profiles that describe how attachments should be handled as well as a profile for Web Services Security. No other groups are known that are working profiles.
The WS-Policy specification [WS-P] developed by IBM and Microsoft describes a way of defining the policies that apply to the use of a Web service although it is not part of any standards initiative.
The only work on agreements for use when using Web services to connect businesses is the ebXML Collaborative Protocol Agreement [ebCPA] that defines how two businesses can connect using ebXML protocols. However, this specification, like the other ebXML specifications, are designed to work primarily with the other ebXML specifications rather than Web services specifications more generally.
The conclusion is that there is still a long way to go before standard ways of using Web services for Business is established. As a result, interoperability will be harder to achieve because of the wide variety of different standards that have been developed.
Currently Web services are managed locally using well-known systems management software utilities such as OpenView or Tivoli. However they can only manage systems running in the same installation.
With Web services and the idea of composing new applications out of existing services using definition languages such as [BPEL], managing only local applications will not be enough as the Web services involved can be distributed over multiple servers and connectors, in different geographic locations using technologies from different vendors.
However if remote Web services are to be managed effectively then standards are needed so that remote management of a Web service can occur.
Web Services Management requires the following types of functionality:
Connector Management – starting and stopping servers, getting server status information, managing server security remotely
Service Management – starting and stopping individual Web services, getting Web service status information, managing Web service security remotely
Message Management – checking the status of individual messages for diagnostic purposes, tracing the path of a message
Service Level Management – remotely setting and checking the service levels in terms of downtime, response time etc, for Web services and connectors
Change Management – specifying changes to Web services, subscribing to change notification services and publishing changes
Event Management – recording of events, e.g. service down, starting/stopping a service and querying of the resultant data to provide management information about the actual behavior of a service or connector.
A large part of the management of Web services requires interacting with remote servers and services. The best way to do this is to use Web services technology where there are Web service interfaces exposed by each connector and service expressly for the purpose of enabling remote management. If these "management" interfaces are standardized, then you should be able to operate a Web Services Management Console that can provide a consolidated picture of what connectors and Web services are operational irrespective of the technology being used (see Figure 6).
There is a long history of distributed systems management e.g. in the Distributed Management Task Force [DMTF], which means the problem is well understood.
Also, the Web Services Distributed Management [WS-DM]activity that started in OASIS in 2003 is addressing the problems outlined above.
The net of this is that the problem is well understood and is being solved although it will probably be some time before the necessary work is complete.
Registries contain the data used to search for, design, run, manage and interact with Web services. Some information is used at design-time to help build Web services and business processes. Other information is used at run-time, for example to work out where a message should be sent. Also, some of the information needs to be shared, for example, Web service and business document definitions used by business partners.
As information needs to be shared, then the information in the Registry needs to be actively managed and synchronized.
Data that a Registry needs to store includes:
Definition Data – definitions of documents, services, messages, business processes, choreographies
Profiles, Policies And Agreements – so that profiles and policies can be discovered and the agreements that result from negotiation stored
Business and Organization Data – so that information about a business can be discovered when one business is looking for another they could partner with
Registry Management – so that changes to the data in the Registry can be copied to other Registries that hold copies of the data
Registry Search – which provides a general way of searching for information in a Registry.
There are two main standards initiatives that relate to Registries: the Universal Description, Discovery and Implementation [UDDI]and ebXML Registry/Repository [ebRR].
UDDI provides a good model for recording business/organization data as well as good facilities for searching and the retrieval of WSDL definitions as well as replicating copies of the data with other UDDI implementations. On the other hand, the ebXML Registry/Repository specification describes how to store information such as document and process definitions, or any of the other definitions that are required to support the design time and run-time environment for Web services. However it has done less work than UDDI on recording business/organization data and on how the data could be replicated.
However the UDDI and ebXML Registry/Repository activities have been around for some time and, to an extent, predate the development of standards for security and reliability. This means that they have developed their own ways of solving these security and reliability that will need to be updated to the "standard" approach for these areas such as WS-Security [WS-S].
The final area where standardization will be of benefit is in the area of Program APIs. These are APIs that allow an application to interact, in a standard way, with software that provides Web services functionality such as sending and receiving messages, handling XML documents etc.
Without standardization of these APIs, applications will not be portable between different hardware and software environments.
It is also likely that these APIs will need to be profiled to support different needs. For example the APIs required to support the security and reliable messaging demands of B2B would be more extensive than the APIs needed when connecting a PC and a PDA using SOAP.
The APIs that are needed include:
Basic SOAP APIs that provide the basic functionality to send, receive and generally handle SOAP messages. There are number of Java standards that meet this need including JAX RPC and JAXM
Complex Web Services APIs that provide a way of indicating whether a message should be sent reliably and/or securely
Message Access APIs that manipulate the data stored in messages
Web Service Management APIs that allow an application to carry out Web services management functions on a remote Web services, and
Registry APIs that allow the data in a Registry to be accessed via an API rather than a Web service
Really there are only two main APIs that are available for using Web services: Microsoft’s .NET APIs and the JAVA APIs being developed as part of the Java Community Process [JCP]. Microsoft is sole custodian of the .NET APIs so really they are setting their own standard whereas JCP is a more normal standards activity under the overall guidance of Sun Microsystems.
However the APIs are not mature, in fact the APIs are, to a large extent dependent on the development of the associated Web services standards, for example the APIs to access a Registry will be dependent on the Web services protocols used to access a registry.
Given the background described above, the only thing that is certain is that nothing is certain as there are many – sometimes competing – initiatives. In particular, there are multiple different standards for business documents, choreographies and reliable messaging. This means that, in the short term, a business will have to plan on supporting multiple different ways of connecting to their existing systems and partners. However, waiting for standards to mature so that connectivity is easier, will mean missing the real benefits of better lower cost solutions that using Web Services for Business can provide.
The solution to this problem is adopting the "right architectural approach" (see Figure 7) where definitions and rules are stored in a rich and powerful Registry. This means the way integration is implemented can be easily changed and adapted as businesses – and the way you need to connect to them – change. Secondly, the Web Services Middleware should be designed in an extensible way that allows new standards to be plugged in under the control of the Registry. Thirdly there should he high-level, Web-service-neutral APIs that applications can use to access Web services middleware that actually sends and receives the messages. It is also a good idea, as mentioned earlier, to adopt a single "internal" business document standard to simplify transformations of business documents as well as provide a uniform interface.
This approach separates business applications from the changing environment in which they operate. As a result you can relatively independently change: an application, the business process, the business documents and the Web service standards being used. It also means that, when changes occur, they can be handled in one place – in the rules in the Registry – at lower cost and more consistently.
This paper is based on the Business Web Services Scorecard paper [BWSS] which provides much greater detail and analysis. For example Figure 8, which is copied from the paper, provides a "scorecard" that describes the current (August 2003) state of Web services standards from three perspectives:
Scope – the extent to which the problem is understood
Maturity – the extent to which standards in the area are complete, and
Adoption – the extent to which the standards that do exist are being adopted.
Similar, but more detailed "scorecards" are available for each of the main standards areas identified in Figure 3.
The following are the content pages from the paper:
Management Summary, page 5
How the Business Web Services Scorecard helps, page 5
Web Services Standards Framework, page 6
The Current State of Business Web Services Standards, page 7
What should businesses do now?, page 13
What the rest of this paper contains, page 14
How to provide feedback, page 15
What’s Changed, page 16
Web Services Basics, page 19
A Real World Service, page 19
An Equivalent Web Service, page 20
Real World vs. Web Services, page 20
So what are SOAP, WSDL and UDDI?, page 21
Web Services Standards Framework, page 24
Underlying Technology, page 24
The Framework, page 25
Complex Web Services, page 27
How Complex Web Services Work, page 27
What Features Should Complex Web Services Support, page 28
The Current State of Complex Web Services, page 32
The Future of Complex Web Services, page 35
Definition Languages, page 37
What Definition Languages are needed, page 38
The Current State of Definition Languages, page 40
The Future of Definition Languages, page 42
Semantic Definitions, page 43
What Semantic Definitions are needed, page 44
The Current State of Semantic Definitions, page 46
The Future of Semantic Definitions, page 47
Profiles, Policies and Agreements, page 48
What Profile, Policy and Agreement Standards are needed, page 48
The Current State of Profile, Policy and Agreement Standards, page 52
The Future of Profile, Policy and Agreement Standards, page 54
Web Services Management, page 56
What Web Services Management Standards are needed, page 56
Current State of Web Services Management Standards, page 59
The Future of Web Services Management Standards, page 60
Registries, page 61
What Registry Standards are needed, page 62
Current State of Registry Standards, page 65
The Future or Registry Standards, page 66
Program APIs, page 67
What Program API Standards are needed, page 67
Current State of Program API Standards, page 70
The Future of Program API Standards, page 73
Getting Standards Adopted, page 74
What the Scores Mean, page 76
Glossary, page 77
About the Author, page 97
See [BWSS] for information on how to obtain a copy of the paper.
This paper is a much shortened version of the Business Web Services Scorecard [BWSS] by David Burdett, Director of Standards Strategy for Commerce One.
[AIAG] The Automotive Industry Action Group is a US based not-for-profit association of companies involved in the automotive industry. They develop several eCommerce and B2Bi standards for use in their industry. See http://www.aiag.org/
[BPEL] The Business Process Execution Language for Web Services (BPEL4WS) is a specification developed by IBM, BEA, Microsoft, Siebel and SAP. It is a definition language for business processes. It is being developed in the Web Services Business Process Execution Language Technical Committee in OASIS. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
[BWSS] The Business Web Services Scorecard, A Commerce One Whitepaper - published August 2003, Author: David Burdett, mailto:david.burdett@commerceone.com. A 75 page paper that was used as the basis for this paper. See the More Information section of this paper for more details. The paper is updated with new developments in Web services every three months. The paper can be downloaded from http://www.commerceone.com/download/ or by contacting the author.
[DMTF] The Distributed Management Task Force is an industry organization that is developing interoperable standards for managing distributed software and hardware. http://www.dmtf.org/
[ebCPA] The Collaboration Protocol Agreement (CPA) is one of the specifications within ebXML. Its purpose is to define how two businesses will interact when taking part in B2B (see B2Bi). Separate agreements are required for each process being integrated. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-cppa
[ebMS] ebXML Messaging is one of the standards within ebXML. Its purpose is to provide a set of standards to support Complex Web Services. http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-msg
[ebRR] ebXML Registry is one of the standards within ebXML. Its purpose is to define a standard way of manipulating information with Registries. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
[JCP] The Java Community Process is an open organization of Java developers and licensees who develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Originally created by Sun Microsystems. See http://www.jcp.org/en/home/index
[RosettaNet] RosettaNet is an organization that focuses on defining messaging, business document and choreography standards for the High tech Industry. See http://www.rosettanet.org/
[UBL] The Universal Business Language initiative is a Technical Committee within OASIS that is developing standard representations for business documents used in B2B. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl
[UDDI] Universal Description, Discovery and Implementation is a standard for storing, searching and managing information in registries. It is a technical committee within OASIS. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec
[UN/CEFACT] The United Nations Center for Trade Facilitation and Electronic Business is the department of the United Nations historically responsible for defining and maintaining the international version of EDI. More recently it has sponsored several standards activities related to the definition of business documents and business processes including ebXML. See http://www.unece.org/cefact/
[WS-BP] The WS-I Basic Profile is one of the activities of WS-I. It is a specification that provides precise rules on how the basic Web Services specifications of SOAP 1.1, WSDL 1.1 and UDDI 2.0 should be used together in order to maximize interoperability. See http://www.ws-i.org/Profiles/Basic/2003-08/BasicProfile-1.0a.html
[WS-CHOR] WS Choreography is an activity with the W3C. Its purpose is to "create the definition of a choreography language(s) for describing a choreography, as well as the rules for composition of, and interaction among, such choreographed Web services". See http://www.w3.org/2002/ws/chor/
[WS-DM] Web Services Distributed Management is a technical committee within OASIS that is developing standards to support the remote management and monitoring of Web Services. See http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm
[WS-I] The Web Services Interoperability Organization is an "open, industry organization chartered to promote Web services interoperability across platforms, operating systems, and programming languages". See http://www.ws-i.org/
[WS-P] WS Policy is a specification developed by IBM, Microsoft, BEA and SAP that provides "a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service". See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-policy.asp
[WS-R] WS Reliability is a specification published by Sonic, Sun, NEC, Fujitsu, Oracle and Hitachi that defines a protocol "for exchanging SOAP messages with guaranteed delivery, no duplicate s, and guaranteed message ordering". See http://sunonedev.sun.com/platform/technologies/ws-reliability.v1.0.pdf
[WS-RM] The WS Reliable Messaging Protocol is a specification published by BEA, Microsoft, Tibco and IBM. It "describes a protocol that allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures. See http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp
[WS-S] The WS Security specification developed by IBM, Microsoft and RSA describes "enhancements to SOAP messaging to provide quality of protection through message integrity, message confidentiality, and single message authentication". See http://www-106.ibm.com/developerworks/webservices/library/ws-secure/
  |
Design & Development by deepX Ltd. |
