Matthew Fuchs

Web Sservices are an integral part of the eMarketplace vision that drives Commerce One. The first generation view of marketplaces was simply as a means of connecting buyers and sellers - essentially automating existing and new procurement relationships in from the "bricks and mortar" world. However, Commerce One has always been looking beyond that to an environment where the marketplace can offer a rich set of services to all the market participants. These services are essentially Web Services. In pursuit of realizing this vision, Commerce One has expended considerable effort in developing technologies covering many of its aspects of this, either on our own, with partners, or with consortia and standards bodies.

At this early stage, a position paper is more appropriately a statement of concerns than a statement of solutions. Commerce One sees two essential sets of issues needing to be resolved for Web Services to work. They break down, not surprisingly, into the social and the technical.

There are several different communities of developers for Web Services: e-commerce, academia, intelligent agents, etc. The requirements for web services across these communities may be very divergent. The call for participation listed a number of topics, such as security and reliability. Commerce One, being in the ecommerce business, has a particular set of requirements with regards to these topics - probably on the maximalist side. However, while we might be happy to force the same requirements on everyone, we recognize it would seriously inconvenience many - including our customers in other aspects of their business. This will inevitably lead to a tension between these different sets of requirements. How much convergence can/should we enforce across these communities? If we do want convergence, what should we do to make it happen?

Even within a particular community there is likely to be more than one voice - under the general rubric of eBbusiness one can already find a multitude of groups building a plethora of standards. How will the work in Web Services under the W3C interact with the fine (but not always compatible) work being done by others? How will we be able to limit chaos without recourse to coercion (or is coercion acceptable)?

But the most daunting social issue for Web Services may be getting users to use them. This means that we must consider, not just the technology, but also how it will get used and deployed.

We believe that exploiting Web Services may require new development methodologies and application architectures. People will need to invest in rewriting existing applications to either work with, or work as, Web Services. When applications need to work together in complex transactions, the traditional kind of Interface Definition Language - COM/CORBA- is insufficient, as they do not convey dependencies among operations. The notion of an interface must be extended to include this information. Do we know yet what are the best practices for doing so? It is clear that the answer is not widely known in the potential Web Services development community. Developers may find themselves required to depend more heavily on formal methods than they’ve needed to in the past.

On a more strictly technical aspect, Commerce One is very interested in discussing the role of XML Schema in the development of Web Services. We have extensive experience using a schema language very similar to the current Proposed Recommendation and would like to make sure that the next generation of Web Services - the first "official" generation - exploits the Schema Language’s potential.

There are is a set of concerns fitting under the general rubric of service heterogeneity. An area of extreme concern is support for the evolution of Web Services over time. Extending and versioning of services is inevitable. It will be important that our technology be able to support the evolution of Web. Even if Web Servicesour 1.0 technology doesn’t support versioning, it is essential we do nothing to make it harder to add in the future.

Closely related is the issue of integrating different, but related services. Our decisions must enable the development of easy to use tools (or entirely automated systems) for handling many of the heterogeneity issues. Just as straight-line projections once showed that every American would soon need to be a telephone operator to handle the increasing traffic at the turn of the century, throwing more programmers at this problem would eventually require every human to be a full time programmer.

Technological aspects - hardware - bandwidth of comm and capacity of devices

Another issue is the variety of hardware that will be used to deploy the web services. For example wireless technology is currently much more limited in terms of bandwidth than Internet technology. Therefore does the same technology and approach apply equally well to both environments?. Similarly, the messaging technology you used in a real time manufacturing process control solution has different demands in terms of response time, security, reliability, etc, to the needs of sending a Purchase Order over the net.

We need to make sure that we clearly understand the target environments on which the the results of this effort will work and regcognize that, maybe, "one size perhaps does not fit all".

Discovery mechanisms

Another area to consider is the need for registries of web services so that other organizations can discover and then use them. Discovery on its own, though may not be sufficient. For example, if organizations use different, perhaps incompatible, versions of a web service, then how will they interoperate? Businesses will also migrate to different versions of web services at different rates so the registries may be out of date.

Integration

Finally, there are the technical challenges associated with integration. Developing an HTML interface to access a web service is probably quite straightforward. However, the real challenge is to integrate web services together to create larger more powerful, and useful, services. In the short to medium term, at least, this will mean that web services will frequently need to integrate with existing legacy systems. This integration is unlikely to occur without significant manual effort during a period when, initially, changes to web services will occur rapidly.

So in conclusion, the Commerce One considersperspective on this is that the Web Services initiative to be extremelyis important and valuable, but we all need to make sure that we recognize and address the challenges that facinges us for this initiative to succeed.