 | |||
|
Wednesday August 15 2001 Internal or External Web Services? Which One Will Dominate? Web Services are clearly in the minds of most technical architects and developers, and as general issues about the use of uniform protocols and contracts are being settled, more specific questions arise. In this article, we will consider differences between internal and external Web Services, and attempt to suggest answers to questions, such as: What are the respective effects of implementing internal and external Web Services? And which type of Web Services will dominate in the future? Definition of Different Kinds of Web Services Before discussing the respective effects of using internal and external Web Services, we need to define some differences between them. The diagram, below, points to the most important ones.
External Web Services enable different organizations to exchange services over the Internet. An organization looking for a specific service can go to a Web Services directory, such as UDDI, http://www.xmethods.com/ or http://www.salcentral.com/, and search for this particular service. A Service Level Agreement (SLA) then has to be closed between the organization providing the service and the one wanting to use it before it can be consumed. Internal Web Services are owned by the organization that uses them. They can be connected to different parts of an organization?s internal information system, such as sales, human resources, finance and production. A finance application can, for instance, call a real-time EuroToUSD converter within the organization; and a management Web Service can be used to retrieve particular sales clients from an internal database. SOAP ? a Key Technology Simple Object Access Protocol (SOAP) is the glue that a lot of organizations have dreamt of in order to make their systems inter-operate with other organizations?. SOAP is a technology based on well-established standards (XML and, especially, HTTP), that everyone can own and use. SOAP is the technology expected to enable inter-operability on the Internet. SOAP has solid support from industry vendors, such as Microsoft, IBM, Sun Microsystems and Borland. Most of the products from these vendors offer SOAP as the universal connector; this is, of course, because all vendors know that if a product is not yet XML or SOAP compliant, it won?t be sufficiently competitive. Some suggest that ASP developers will suffer when SOAP and other Web Services technologies become more prevalent, as they have been slow at picking up these new technologies and instead spent time and money on other infrastructure. Web Services are based on eXtensible Markup Language (XML), an independent and open language that acts as an intermediate in Web-based communication. Web Services providers and consumers can maintain their existing development languages and operating systems, as they can communicate via XML. Using XML as a ?go-between? serves to overcome common problems associated with the use of disparate languages and operating systems; issues that have plagued the IT industry for decades. For organizations that want to keep their existing computer systems or for organizations with many different information systems, SOAP can work as an internal communicator and as a connector between internal Web Services. SOAP is also the ideal tool for external communication between suppliers, clients and partners with different platforms and service environments, providing inter-operability between external Web Services. It is, currently, used more in this external context than in the communication between internal Web Services and applications. Internal Web Services As SOAP is not dependent on any single technology, it can serve as the basis for organizations? Enterprise Application Integration (EAI) solutions. An organization might use different internal databases (for instance, Oracle, SQLServer and mySQL), which cannot communicate with each other in the information system environments they are in. However, SOAP serves to enable these different databases to inter-operate. It is, thus, easy to create an Enterprise Information Portal (EIP) based on SOAP. EPIs can be composed of elements that are requested by Web Services and, with the use of SOAP, common problems related to the use of disparate languages and standards can be avoided. Moreover, SOAP enables reuse of applications within an organization; that is, when modularity is applicable. Instead of creating new versions in other languages or environments from scratch, developers can simply SOAP-enable their applications. These modules can then be integrated into any other applications: a process which can reduce the development stage and facilitate management by centralizing application maintenance. If the creation of a Web Service is as easy as to add in one line to your code (WebMethod is the code line that turns a class into a Web Service in Visual Studio .Net), developers will be more likely to make use of them. The call itself is very straight-forward and there are no difficult integration issues. Web Services improve application architecture opportunities by enabling component reuse or code sharing. They can centralize core functionality that can be reused, or accessed by different applications. Internal Web Services will primarily be used by larger organizations that already have an established Web infrastructure. It can be a costly process, and smaller organizations might not find the advantages worth the costs. They are also likely to use only one kind of system environment. Larger organizations, however, can use them at once and widely. They are likely to do so, as time and money are gained by automating internal business processes. As Web Services technology becomes more prevalent and cheaper, also smaller organizations may find ways of speeding up their internal processes by the use of internal Web Services. External Web Services External Web Services enable organizations to exchange services on the Internet. They are created and published by one organization and consumed by another. There are many reasons to deploy Web Services, some more important than others. One reason is that the target group has no bounds. Suppliers, clients, partners can all use the same applications. In addition, Web Services can be read in many different kinds of ways; Internet browsers, mobile phones and handhelds can receive Web Services. With the help of easily implemented security layers (access filter and secure communication), it is possible to create new business by renting or selling Web Services. A useful and competitive Web Service must, of course, incorporate at least one of the following two features:
Even for organizations that don?t develop their own Web Services, the use of other organizations? services provide many advantages. Specialized information can be obtained from expert centres. GetWeather and GetStockQuote, for instance, provide real-time information that is, currently, hard to get elsewhere. In addition to public versions of a Web Service, an organization can integrate private data clients through secure Web Services access, provided by the supplier. By integrating these new Web Services resources, applications can, in the future, be much richer than they are today in terms of what they provide and do. With bi-directional services, organizations can automate business processes and strengthen relationships with other businesses, as shown by the diagram below. Integration of internal and external Web Services Start with Web Services There are two other aspects of the Web Services implementation process that need to be considered: training skills and configuration of system environment. These can be expensive outposts in the implementation, but they don?t have to be. If we choose a simple update of a system environment (making Windows 2000 SOAP-compliant, for instance), we can add utilities such as MS SOAP Toolkit 2. Although it might not be necessary to give developers a lot of training, some induction is needed; as well as knowing SOAP, developers must be able to utilize the SOAP Toolkit within their programming language. They must, for instance, know how to use SOAP with Visual Basic. Another option is to use brand new technology, entirely dedicated to support SOAP and to create Web Services, such as Visual Studio .Net and .Net Framework for Microsoft or CapeClear and Glue, which attempt to cross platforms. Choosing this option, we will benefit from new functionalities that simplify creation of Web Services. We will, however, discover a new API and programming environment that demand a new way of programming. Conclusion In the near future, we can expect to see an increased use of Web Services, external as well as internal. Internal Web Services will, however, be a solution primarily for larger companies that use a variety of system environments and languages. Simple Object Access Protocol (SOAP) will be used as glue in connecting a Web Service with the internal application calling it. SOAP can solve most inter-operability problems connected with Web Services. Internally, it provides a way of working at the same layer with different technologies and alleviates maintenance and internal communication. An organization can, in this way, gain time in their business processes by using SOAP to communicate between internal Web Services. Externally, SOAP enables companies to reach potentially anyone with a device that can receive Web Services, such as an Internet browser or a mobile phone. External Web Services also help automating business processes. Furthermore, increased publication and use of external Web Services enable organizations to obtain specialized information. With the wide market that external Web Services face and the specialized information and functionality they provide, external Web Services are likely to dominate the Web Services market in the foreseeable future. However, the useful aspects of using internal Web Services will assure an increasing market for them as well. Readers of this article may also be interested in reading: Business Architecture for a Web Services Brokerage. Keep up to date with all the new articles and features on
Web Services Architect: |
