Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Web Services in the Large
The concerns about using Web Services between organizations are an extension of those within enterprises. Security is a requirement for most cross-organization interactions. As mentioned earlier, SSL can provide a point-to-point solution, but for loosely coupled interactions, end-to-end authentication and privacy are required. To provide this, we need the ubiquitous, loosely coupled security infrastructure that has evaded us for so long. Without verifiable authentication, you can't keep track of who is using the service. Without this information, you can't charge for the service. In a commercial environment, without a revenue stream, there is no service...
When looking to wider Web Services, we need to adapt our thinking. Across organizations, you generally won't want to have a tightly coupled transaction. (I won't let you hold locks in my database for too long, however much synergy our companies have. <g>) We'll have to consider loosely coupled transactions and compensating operations in the place of 2-phase commit. There are other Quality of Service requirements for ongoing, distributed interactions, such as message identifiers or conversation IDs, client bandwidth limitations, and lots of other context. As you may expect, work is ongoing in these areas, but as yet there's no single solution.
As you specify your application, an aspect that should concern your technical architecture people is the systemic qualities of the system, otherwise known as the "ilities." When the hardware, software, and network bandwidth are all under your control, you can reasonably determine whether your application will meet performance or scalability targets. If you decide to use a third-party Web Service for part of your application, what guarantees do you have? If the Web Service is critical to your application, you'll need a service-level agreement with the Web Service provider that specifies performance, scalability, and availability of the service. This applies as much to Web Services within your organization as external ones. As part of the definition of your technical architecture, you have to decide whether to build your functionality, buy it as a component, or rent it as a Web Service. This will have a major impact on the risk assessment for your project. Also think about the testing phase: Will you have to pay for every use of the Web Service during testing?
All of this brings into question the viability of the grand vision of Web Services. Will the real-time, dynamic lookup of services really happen, or will we just use Web Services as a better way of building bridges between organizations? Everyone agrees that we need more and better infrastructure for Web Services. There will be a shakeout as different initiatives are launched to provide this infrastructure, from ebXML to Microsoft's Global XML Web Services Architecture (GXA). However, we also need a shift in global infrastructure and business models to make the grand vision happen.