To this point in time, Web Services have been largely focused on the B2B problem domain, which has certain salient characteristics:

• There is an emphasis of low overhead
• There is an emphasis on "ubiquitous" environments in which businesses can find each other (the Web, http)
• The scenarios tend to be smaller scale, without rigorous performance requirements

Many of the same problems being addressed by Web Services, however, also appear in domains such as Enterprise Application Integration. These involve publishing services, finding them and binding to them in an efficient manner. There are, of course, some differences as well, such as:

• While there’s always a desire to keep overhead low, but this can be traded off if there’s an advantage from sharing additional infrastructure
• The requirement for a ubiquitous infrastructure is loosened, since developing shared infrastructure is possible
• Applications tend to have tight performance requirements, and a need to scale to very large numbers (thousands, even millions of users)

An example might illustrate the difficulties: while stock trading functions can in fact be published as a web service, they are frequently back-ended by large complex mainframe applications. When a brokerage firm wishes to integrate with a new partner – domestic or international, systems will most likely not be integrated by having the partner use the web front-end. Rather it is likely that a bridge or gateway directly to the back-end service would be developed or exploited. In this environment some rather interesting problems can arise, other than the normal perplexing systems integration issues. For example, there is the issue of understanding service availability across international boundaries. For example, what’s the last time during the day it makes sense to take a day order for execution on the New York Stock Exchange from a brokerage in Japan?

Schwab is interested in seeing the Web Service paradigm extend into other realms. Some of the issues we are concerned about are already listed in the agenda – security, reliability, confidentiality, and transactionality. Some additional items of interest to Schwab include:

• Performance. For example, we may want to be able to use the Web Service definitions statically at write, compile or build time, so that an optimized static binding can be used, instead of a more costly dynamic binding.
• Support for multiple forms of service integration. So far, most of the focus seems to be on distributed object style callable interfaces. We would like to see support for event-based interaction. (What events does a service raise? what events can it handle?) We also need to be able to support bulk data processing/transfer: many of our clients send us large files composed of orders for multiple accounts. Bulk/data processing needs to support functionality such as checkpoint/restart (we do not want to get 2/3 of the way through a file of thousands of orders, run into a problem, and have to start again from the beginning).