 | |||
|
Wednesday August 1 2001 Business Architecture for a Web Services Brokerage Understanding the Business Context of Web Services SOAP and Web Services may hold center stage of the developing Web industry, as attention focuses on toolkits and multi-platforms; however, this area of the industry is merely the tip of an iceberg, which reaches much further than merely selling utility software. Yet, rather than considering the overall architecture of a Web Services business model, the present trend seems to be for companies to produce development tools for the sake of it, in a market that is still maturing. For the Web Services industry to succeed, it needs a solid architecture of support and sales services. Both developers and customers need to know what niche they fall into, and how they can interact with other parts of the industry. To fully comprehend the Web Services industry, we need to understand the demarcations between sales, development and hosting of Web Services. A main concern, in this early stage of the development process of Web Services, is that there is no benchmark industry to learn from. The Web Services industry is, possibly, most closely related to that of ASPs (Application Service Providers). However, as developers get the tools to publish functional Web Services as easily as one can create a HTML Web page, it is likely that the Web Services market will soon overflow. Once Web Services get widely adopted, the large number of RAD (Rapid Application Development) developers, using tools such as VB, Delphi, C++ and the forthcoming .NET platform, will, literally, swamp the market with Web Services. This article serves as a first stepping-stone for the Web Services brokerage architecture. In it, I bring together the result of my past eighteen months of research in Web Services, and practical knowledge of building a brokerage (http://www.salcentral.com/). The term brokerage is used within many contexts; however, in the context of Web Services, a brokerage is best defined as an organization, or individual, whose primary activities include the commercial ability to publish, promote and sell SOAP-based Web Services. Below are eleven distinct parts of the development process of a Web Service, grouped under four categories: Creation, Publication, Promotion and Selling.
In reality, many of these roles are performed by one organization; however, for the purposes of understanding, we will consider them as distinct parts of the development and business process of Web Services. Creation The creation of a Web Service will stay in the design, development, and documentation stages (explained in the table above) until its functionality and design are checked, reviewed and proved satisfactory. The same will happen in most other technical development processes. However, already at this early stage in the development process of a Web Service, we seem to move away from inherited methodologies and start to tread on new territory. A Web Service provider can create a client front-end to a Web Service, so that other companies will be able to use the Web Service he has produced. However, inter-operability within a Web Service is defined in two distinct layers. The organization that consumes a Web Service is responsible for the one layer that controls the user interface. This organization does not have to be the Web Service provider. The second layer is the Web Service which, when separated from the client front-end, allows the Web Service provider testing its Web Service to concentrate on business functionality rather than aesthetics or developing a user interface. This testing process, however, can be performed outside the developing organization. An immediate advantage of this is that third party organizations, outside the development team of a particular Web Service, can independently test that Web Service. As an organization?s Web Service can be made available to other organizations over the Internet, there will be organizations specializing in testing unit functionality and inter-operability. External testing, as well as internal, secures high functionality of Web Services. The external organizations, testing inter-operability, will be able to pass a Web Service through a pre-defined series of tests such as data-typing, response analysis, and high traffic, at the end of which they will be able to produce a certificate of assurance which can be fed into a Service Level Agreement (SLA). Without this type of pre-determined testing, the customer has to rely only on the developer?s skill and judgment. However, the customer will, in future, have a choice. There will be a definite connection between the most successful and most widely used Web Services and their choice of methods of functionality testing. The distributor has the most important role in the Creation stage; all information, constituted of code and data, developed in the first parts of the development process, needs to be collated into a single package. This package can then be fed into a Service Level Agreement, which contractually declares that this Web Service performs a certain task. It should be said that not all Web Services need an SLA - it's all about consumer demand. Customers need to distinguish between many similar Web Services. Quality Assurance and Service Level Agreement help customers choose the right Web Services. With such quality management, customers can trust the functionality of available Web Services, before trying them out. Furthermore, the distributor is most suited to make choices about the hosting and warehousing of specific Web Services. Publication In conversations I?ve had with organizations and venture capitalists, looking at the Web Services industry, the one word most consistently raised is ?trust?. For the Web Services development and publication system to work, one must be able to trust other organizations? which will very probably be situated in a completely different country ? in order to let them administer and back up one?s own organization?s Web site. It?s all very well creating an SLA, but what is it really worth if we know that the cost of international litigation far outweighs the cost of hurriedly obtaining another Web Service provider and adjusting our code. Although some larger corporations may not have a problem with this, the majority of organizations find international litigation an extremely risky venture, even if an organization is in the right. We can expect some extremely detailed Service Level Agreements to be enforced for critical Web Services, but this might not be enough. One way of solving the problem is to take the original code, compiled Web Service, and data storage, away from the publisher, and place it with trusted intermediaries whose only business function is to administer Web Services. An intermediate organization holds the latest copies of different aspects of a Web Service. However, it is independent from the original developer. It offers its customer a secure and safe repository to store a snapshot of the Web Service code, documentation and all associated files. What makes this model work is that the intermediaries are:
This type of arrangement is similar to the legal and technical binding most Web site owners have today when other companies host their Web sites. There is, usually, a Service Level Agreement in place, indicating the type of service expected within the terms of your use of that Web hosting service. We would expect that Web hosting organizations which host such services, for instance, http://www.brinkster.com/, would only take on Web Services that have been run through favored inter-operability organizations. This would, in fact, serve to decrease the risk of downtime and potential problems, such as those we have foreseen above, and create a close and essential liaison between inter-operability and Web site hosting. Another potential solution to the problem of enforcing a Service Level Agreement is to use the services of a Web Service Auditor. A Web Service Auditor checks that organizations? Web Services match their SLAs, and advise them of any changes in the standard of the service as agreed within the original SLA. Promotion Searching for Web Services will become paramount over the next few years. It will be important to have an appropriate method of tracking down the Web Services that we need, out of the potentially hundreds of thousands of available Web Services. Searching for Web Services includes two sections, which, although they can act independently are stronger when working collaboratively: The Web Service directory (UDDI, http://www.xmethods.com/, http://www.salcentral.com/) allows customers to track down a Web Service by using selection criteria. The directory works like a search engine. It enables us you to either enter search criteria, or to browse categorized lists, to find a specific Web Service. In addition to the Web Service directory, there seems to be place for dynamic Web Service searching tools, to interrogate and locate new Web Services. These would use a similar technique to the current Web site spiders, by moving along series of linked XML discovery files, each one describing the location of various Web Services, and any further XML discovery files. These tools would find new and changed Web Services, so that they can be displayed within a specialist search engine or Web Service open directory. VAS (Value Added Services), for example, at http://www.salcentral.com/, allow us to select Web Services not only by categorized lists or searching tools, but also by giving additional analysis or general information that would normally not be available. If we, for instance, find two Web Services that perform similar tasks, we can, with VAS, get information about the response rate of each Web Service, and availability over the last six months. This information allows a customer to make an informed judgment as to which Web Service to choose. Accreditation will, undoubtedly, serve to create a layered approach to Web Services. Customers will make selections based on criteria such as who hosts a Web Service, and whether the hosting company has any accreditation. Selling A major problem that the industry will face is the potential abundance of free Web Services. Free Web Services, although providing excellent value for customers, undermine the commercial prospects for the Web Services industry. It is clear that to enable a Web Service provider to sell their services, they need to differentiate their Web Services from free ones. To do this, an organization needs to use ascertained information such as accreditation and Value Added Services to show that its Web Service is trustworthy. It must, of course, also keep its charges down. Costumers would know that this Web Service has been checked by independent organizations (as described above). A third party organization operates as Web Services Auditor. It makes sure that a Web Service functions in accordance with its Service Level Agreement. The Web Services Auditor, constantly, checks and re-checks the Web Services it is looking after. If a Web Service fails to reach the standard established in the SLA, the Web Services Auditor notifies its customer, allowing him to take immediate action. The Web Services Auditor look out for new versions of the Web Service being made available, and makes sure that response rates are, consistently, in line with what is defined in the SLA. Accounts are simply the money collectors of the Web Services world. They collect monthly or per call, allowing the Web Service developer to use a technical layer to call into accounts, and validate whether the user of a Web Service is allowed to use that Web Service. This technical layer, that validates a user?s use of a Web Service on behalf of the Web Service developer, has many advantages:
Even though this area is technically challenging, it seems that the major problems would be those associated with the legal aspects of such transactions; for instance, whether the organization that debits an account is liable for the Web Service?s availability. The clearest type of scenario would be one in which the organization dealing with the accounts is simply an intermediary, and the Service Level Agreement is agreed between the customer and the organizations previously identified as the code warehouse, hosting and data warehouse. Conclusion As the use of Web Services becomes increasingly prevalent, the Web Services industry needs to define its structure, and quickly. I hope that this article serves to raise discussions and questions concerning a type of architecture beyond the current focus on Web Services utilities and tools. Once the overall architecture is defined in more detail, we will be able to understand the direction in which the industry is moving, and will be well placed to understand the ways in which the mature industry will eventually be structured. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Readers of this article may also be interested in reading Web Services and Collaborative Commerce, Web Services and the Insurance Business and Versioning of Web Services. Keep up to date with all the new articles and features on
Web Services Architect: | ||||||||||||||||||||||||||||||||||||||||||||
