The WebEAI Advisor: Web Services, XML and the Enterprise
What are web services?
The introduction of the Internet promised to provide connections between people, businesses, and organizations throughout the world. In order to exchange data and information, however, a standard was needed – that standard is XML, a language toolkit that allows industries and infrastructure providers to create common business and technical vocabularies, understandable by any computer, and any programming language.
Web services use an XML technical vocabulary to exchange information messages. That information is in turn expressed in XML industry-specific business vocabularies. Web Service Applications use Web Services XML-based standards to advertise their availability, to provide interfaces to callers, and to wrap the business information provided to and returned by the application. The services can be consumed within an enterprise or between enterprises, to enable Enterprise Application Integration (EAI) or Inter-Enterprise Integration (IEI).
This means that application functionality will be available over the Internet through standardized programmatic interfaces. Applications that used proprietary protocols in the facts can now be accessed over the existing Internet infrastructure. And what is more interesting is these applications can communicate regardless of their development language, platform, object model, or internal protocols. Web Services provide a universal interface that is revolutionizing application integration technology the way that the web browser, using the same infrastructure, revolutionized the idea of the universal client.
Because all future major development projects will use this paradigm, vendors are making huge investments in development tools, middleware, and software platforms. Microsoft, IBM, BEA, Sun, and many others are adopting XML web services standards such as SOAP (Simple Object Access Protocol), WSDL (Web Services Definition Language), and UDDI (Universal Description, Discovery, and Integration). Toolkits from these vendors build interface code so that, in theory at least, applications from one environment can talk to applications in another without modification.
What are the business drivers for web services?
Enterprises are attracted to web services because they can make the application development process faster, cheaper, and better. The services are exposed at the business level, using XML business vocabularies for various industries, rather than at the object component level. For instances, an accounting application might represent its web services in the XBRL accounting language, which is a standard set of accounting transactions, rather than in the component interfaces specified by the developer. This has an immediate effect of the speed of development, and gives business an opportunity to quickly exploit and penetrate new channels by aggregating and exposing business-level services needed by those channels.
Web services use the existing communication infrastructure – the same one that supports browser connection to HTTP Web servers. Because web service communication and information is expressed in XML, any ASCII-tolerant computer (and its business applications) can be used. Legacy programs can be wrapped with standard toolkits from all major vendors. These same vendors – IBM, Microsoft, Sun, Oracle, etc. – all support the basic standards for web services to provide global interoperability. This ability to leverage current investments in infrastructure and applications reduces capital costs drastically.
In the past, interoperation between enterprises (and usually within them, as well) required a tight integration of applications, with many weak spots, and with a number of exposures, such as the impact of maintaining a specific data format or application program. The most prominent characteristic of XML is that it is flexible, and non-invasive to applications. Combining this with the web service philosophy of hiding technical interfaces behind business interfaces provides a better quality of business value chain integration by the simple exposure of internal processes to trusted business partners.
How do web services work?
A web service has three major components: a business application, a toolkit, and an application or Web server (see figure 1). Together, these components allow an application in one environment (or company), such as an accounting application, to access another application anywhere else on the intranet or Internet (within or between companies).
The business application provides services for organizations internal or external to the enterprise. An accounting application, for example, keeps track of company income and expenditures. This application can provide a web service that answers queries about the way that the company spends and receives money. This application probably exists within the enterprise, or it could be developed using a Web services toolkit.
A toolkit exposes the business service in a standard, web-accessible format, rather than in specific component format, such as RMI. The IBM Web services development environment, Microsoft Visual Studio .NET, or other toolkits from Oracle, WebMethods, Symantic, and others, can be used to expose an account service, such as an expenditure query, as a Web service to be accessed over the Internet by any other program. It is not important which language was used for the application itself – most programming languages can have stubs generated automatically by the toolkit to make the exposure process simple.
An application server or Web server provides the communication protocol, HTTP, and provides the run-time environment for the part of the application that makes it a Web service – the interface, not necessarily the business logic. (It is possible, of course for the business logic also to execute in the application server for a new application, but it is not necessary).This component could be Microsoft IIS, BEA WebLogic, IBM WebSphere, Apache Tomcat, IPlanet, Silverstream, etc.
The operating system (or in some cases the Application Server), runs the business application. The business application provides a service, such as query of expenditures. The Toolkit generates a language-based stub to connect the application to the Application Server or Web Server. The Toolkit also generates a Web Services Interface to represent the business server as a Web Service.
Beyond this, a number of standard XML protocols take over. To express the accounting business information – transaction type, input, and output – an accounting XML standard is needed, such as XBRL. The protocol to communicate between services in general is SOAP, and at a lower lever, HTTP, HTTP-S (Secure HTTP), or HTTP-R (Reliable HTTP) is used for general connectivity above the TCP/IP level. Web Service producers advertise these services inside and outside the enterprise using public and private UDDI directories. Additional XML protocols such as WSIL (Web Services Inspection Language), WSFL (Web Services Flow Language) and XAML (an XA-conformant transaction language) provide enterprise system services to handle enterprise application requirements.
The result is that with the Accounting Web Service used in our example can be used internally or by a partner, e.g. the enterprise’s accounting firm or supply-chain partner. As an alternative, new applications will be developed as sets of distinct web services, with interoperability within the application system, and between application systems.
How do web services provide value?
Adoption of XML and web services has been swift, and has been spared the usual plummet in popularity experienced by newly arrived technologies. The reason is that enterprises have seen a number of tactical and strategic advantages provided by these technologies.
Web services function as easy-to-use software components, independent of languages used to write business applications, and free of the limitations of earlier software component architectures, such as CORBA, COM, and EJB. Of course, these component models will remain very popular for application development, but as web services, their interfaces will remain hidden by web services interfaces for external interoperability. This allows an enterprise to expose its core business functionality so that third-party application developers can build value-added applications using the resources of the core value provider. For example, the American auction site eBay exposes its interfaces as web services which are then used by third-party auctions services providers to link to and add value to the services provided by eBay.
Enterprises have invested more than money in legacy systems; they have invested time. The web services model provides a way to wrap legacy applications in standard and universal XML business and technical formats, such as XBRL and SOAP. This means that these applications can be leveraged more quickly (and at lower cost) than replacing them. It also reduces the risk of wrapping them in specific platform or language formats, such as CORBA, COM, or EJB.
The need to integrate systems has inspired a number of EAI solutions using messaging, RPCs, and other technologies within the enterprise, usually at high cost, and often with a limited audience. The concept of developing new applications or wrapping legacy systems as web services could eliminate one level of integration, although there is a great deal of technical and feasibility research to do in this area. Potentially, the applications would use web services to expose functionality directly from the machine on which that application exists. Currently, enterprises add additional infrastructure to integrate these applications, such as those required by EAI solutions. In the near term, at least, web services will become a part of the EAI solution, rather than a replacement.
Why will web services dominate application development?
The difference between web services, and previous attempts to standardize component computing is that web services do not require the wholesale replacement of enterprise architecture. Instead, they can be implemented incrementally, using existing hardware, software, networks, and application programs. Business does not like risk – but it does like to respond to the market quickly with supporting applications, save money, and improve quality. XML and Web Services combine to provide a common set of business and technical protocols that have the potential to leverage current enterprise assets into a global set of systems and subsystems – a Web of services and information.