Web Services Pitfalls
The latest hot ticket for vendors to sell and journalists to write about is web services. The appeal is natural: web services promise users and developers greater choice of components and services. This article examines perhaps the most futuristic of web services, those offered by a standalone service provider. In particular, it focuses on the infancy of the standards and technology in standalone web services.
What Are Web Services?
Web services is an umbrella term used to describe components and services that are addressable and available using web technology. The kinds of web services are typically user-oriented and browser-based, API-accessible, or system services functionality. A web service could be a browser-based e-mail program, an XML-based interface to an HR system, a SOAP service offered by a machine, a SOAP monitoring service, XML-based integration with an EAI or legacy system, and so on. The standards for the way components in a web service exchange data is crucial. Some of the infrastructure standards that are being created include SOAP, WSDL, UDDI, SAML, ebXML, as well as many vertical standards being created as well.
There are at least three common web service deployment types. In the first place, one can add a web service interface onto an existing product; examples of this approach include application servers, databases, messaging systems, enterprise resource planning tools, and so on. Generally software vendors are taking this approach. In the second place, customers deploy vendor products to solve current integration needs. The customer then uses the new web services functionality to integrate internally or with external partners more easily.
In the third place, an application service provider offers a web service interface, and its customers access and use the service using web service standards. An interesting difference between these deployment types is the different economic model they imply. Vendors gain make money from product sales; customers gain a return on their investment from increased efficiency and expanded customer revenue; and application service providers make money from recurring or rental revenue of the web service itself.
Nothing New
|
Related Reading
|
Web services are not especially new. Application service providers (ASPs) have been providing end-user based web services for many years. While some have struggled, the majority of ASPs — particularly the focused ones — have continued to grow in customers and revenues over the past few years. In fact, many ASPs have provided APIs for parts of their service for a long time. Many provide APIs for provisioning, security, billing, and aspects of the business process. If you believe in the web services provider model, then you also have to believe in ASPs as there is little difference between them.
So where’s the rub? Many of the business and technical issues for service providers and consumers are incomplete. Consider one of the standard web service examples, a travel reservation service. The scenario usually goes something like this: an airline reservation service is currently available via a browser, then a web service API is added to allow applications to communicate directly. The ASP would provide the interface in a SOAP format, define the interface using WSDL, and register the service provider and service in a UDDI repository. A developer discovers the service and creates software that invokes the service.
Contracts and Billing
In reality it's not that simple, How many service providers offer a free service? Very few. The service provider will clearly want to earn revenue based upon service consumption. This typically involves a negotiated contract between the consumer and provider. In our example, the developer would have to know that a contract had already been reached with the service provider. Every time the service provider has a new consumer, and every time the consumer uses a different service provider, a new contract is required. If a service provider wants to reach one hundred different consumers, potentially one hundred contracts are needed.
The problem is harder if the consumer and producer want different pricing models based upon different characteristics. I'm skipping over the issue of how the consumer and producer actually exchange usage and billing information; suffice it to say that there are no widely deployed standards for usage and billing.
The service provider and consumer need a contract in place just as with any other non-technical customer-provider arrangement. As contract negotiation has many facets, this can be a difficult task to scale for either side.
Security
  Comments or questions on this article? Share them with the author and other readers by using our forum. | |
The service's security model is crucial, of course. It is doubtful that a travel reservation service would allow any arbitrary user to book tickets. The ASP must know who is allowed to use which service, and it must know who is allowed to tell it who can use which service. One model is that the ASP will have a list of trusted users. From an API perspective, this becomes a little trickier than the web browser sign-on case. The service provider will specify how the authentication information will be encoded in the message. There are currently no standards widely deployed for encoding security credentials in a SOAP or B2B Message. Some are emerging, but they aren’t standardized yet.
How does the service know what are valid authentication credentials? A typical existing model is that the service provider manually enters a new username and password for each consumer when the contract is signed. It’s crucial that the credential be changed frequently.
Again, a key point is that the service provider and consumer need a mechanism in place to exchange security credentials, and typically a contract must be in place before the credential is exchanged.
Pages: 1, 2 |
