What are Web Services?
- Web services are small units of code
- Web services are designed to handle a limited set of tasks
- Web services use XML based communicating protocols
- Web services are independent of operating systems
- Web services are independent of programming languages
- Web services connect people, systems and devices
Small Units of Code
Web services are small units of code designed to handle a limited set of tasks.An example of a web service can be a small program designed to supply other applications with the latest stock exchange prices. Another example can be a small program designed to handle credit card payment.
XML Based Web Protocols
Web services use the standard web protocols HTTP, XML, SOAP, WSDL, and UDDI.HTTP
HTTP (Hypertext Transfer Protocol) is the World Wide Web standard for communication over the Internet. HTTP is standardized by the World Wide Web Consortium (W3C).XML
XML (eXtensible Markup Language) is a well known standard for storing, carrying, and exchanging data. XML is standardized by the W3C.SOAP
SOAP (Simple Object Access Protocol) is a lightweight platform and language neutral communication protocol that allows programs to communicate via standard Internet HTTP. SOAP is standardized by the W3C.WSDL
WSDL (Web Services Description Language) is an XML-based language used to define web services and to describe how to access them. WSDL is a suggestion by Ariba, IBM and Microsoft for describing services for the W3C XML Activity on XML Protocols.UDDI
UDDI (Universal Description, Discovery and Integration) is a directory service where businesses can register and search for web services.UDDI is a public registry, where one can publish and inquire about web services.
Independent of Operating Systems
Since web services use XML based protocols to communicate with other systems, web services are independent of both operating systems and programming languages.An application calling a web service will always send its requests using XML, and get its answer returned as XML. The calling application will never be concerned about the operating system or the programming language running on the other computer.
Benefits of Web Services
- Easier to communicate between applications
- Easier to reuse existing services
- Easier to distribute information to more consumers
- Rapid development
Web services can create new possibilities for many businesses because it provides an easy way to distribute information to a large number of consumers. One example could be flight schedules and ticket reservation systems.
Client and Server Standards
Executables, C++ (and Java too) must die
Neither C++ nor Java can ever create standard components that can run on all computers. There is no room for these languages in future distributed applications. Executables are not standard. COM objects are not standard, DLL-files are not standard. Registry settings are not standard. INI-files are not standard. None of these components must be allowed to destroy your dream of a standard distributed application that will run on almost any computer in the world.Clients must be Standard Internet Browsers
Application clients must be standard clients without any additional components. No part of the applications must be stored on client computers. The application must never use, or rely on, any components, dll- or ini-files, registry settings or any other non standard settings or files stored on the client computer. (Then you can start calling it a Thin Client). Our best suggestion is to let all clients use standard Internet browsers like Internet Explorer, Netscape, or Firefox running on Windows or Mac computers.Servers must be Standard Internet Servers
Application servers must be standard Internet servers running standard software without any additional components. The application must never use, or rely on, any components, dll- or ini-files, registry settings or any other non standard settings or files stored on the server. Our best suggestion is to use a standard Internet server like Internet Information Services (IIS), with a standard request-handler like Active Server Pages (ASP), and a standard database connector like Active Data Objects (ADO). As your data-store you should use a standard SQL based database like Oracle or Microsoft's SQL Server.Applications must use Internet Communication
Application clients and servers must not be allowed to communicate via any proprietary protocol. Clients must request servers via a standard Internet protocol and servers must respond via the same protocol. Clients must be able to use any service without having to maintain a permanent connection to the server. Our best suggestion is to let servers be requested with standard stateless Internet HTTP requests. Servers should respond with a standard stateless Internet HTTP response.NET Services
Applications must be Services
Applications must be a Set of Services
Applications can no longer be allowed to contain large masses of compiled executable code. Applications must be broken down into a number of smaller individual services that are easier to create and easier to maintain. Individual services should be developed and maintained by smaller groups of people. Services are not the same as executables, or components, or DLL's. Services should be answers to submitted requests. Services should be returned as data. Our best suggestion is to develop services as a number of server-side HTML and/or XML pages.Services must not be Purpose Built
Our history is full of applications that were purpose built for a single task. Many of these applications died before they were introduced, because they could not manage new changes in the requirements. This is a terrible waste of money and time. We (and the people that pay for our applications) want to create flexible applications that are so generalized that they can gracefully support future changes. Future - not even thought about - changes should easily hook into our application without crumbling or destroying it. Our best suggestion is to create flexible standard services that can be used to serve a lot of different requests.Services must be easy to Create and Edit
Services should not be coded if it can be avoided. If a service has to be coded, our best suggestion is to use scripts. Services should never be compiled into executables. That makes services too hard to access and to edit. Any pre-compiled component used in an application will threaten the possibility of creating an application that can move, scale and gracefully support future extensions or changes. Services should be created and modified by editing their properties and methods, not by changing their executable code. Our best suggestion is to use an XML editor to create and edit services, and to use a standard service engine to provide services by executing the service description. The service descriptions should be stored in a data store like a database or in an XML/HTML file.Services and data must be Self Describing
Application clients must be able to query a server for a service and to ask for the current server functions. Clients and servers must also be able to exchange data in a way so that both understand each element in the data. Our best suggestion is to use an XML based information vocabulary with a DTD (Document Type Definition) to exchange server functions, and to use XML to exchange data..NET Proof
