[MUSIC] Hello again, and welcome to the second module. In the first module, we introduced systems based on services. And discussed various web standards using web-based systems. Now we're ready to move into talking about service-oriented architecture based on first generation web services. So what is a web service? How do you use it? These are questions that you will be able to answer by the end of this module. You'll be looking at the standards for how web services are invoked, described, published, discovered, and composed. These notions for services are actually common in other sorts of service-oriented architectures, even based on different standards and technologies. So, let's get into it. A service is some functionality that is exposed for use by other processes. In other words a service has an interface that can be used by some service requester. A web service then is functionality that is exposed and accessible using web technologies. To best understand the driving forces behind web services and the needs they address, it may be helpful to discuss what came before. Imagine that you own a business and you have various software solutions for different parts of your business. Building an integrated system out of six different pieces of software is a difficult task. First of all, each pairwise connection may involve a different combination of languages and platforms. Even with only six different nodes there are up to 15 pairwise interactions. Most of these will need wrappers in order to interact. This is not only work-intensive to implement, but difficult to maintain and extend. Enterprise Application Integration or EAI is an enterprise-level solution for this integration problem. The exact architecture varies, but it uses a form of middleware. Middleware is a software that is located between other software and facilitates communications between them. This approach helps to manage complexity in one organization. There are far fewer interfaces to implement and maintain, however it is not clear how this would be implemented in business to business or B2B interactions, where the interactions are between businesses instead of within them. In particular which business implements the middleware? Is it hosted by a third party? How is security managed? How does the business protect its data from outside influence? These questions are not impossible to solve, but in practice EAI is not used for B2B interactions. Instead interactions between businesses are better implemented as web services. Although this term sounds very general, a web service is usually implemented with a specific set of standards and protocols for implementing services over the web. The World Wide Web Consortium or W3C defines a web service as a software system designed to support interoperable machine-to-machine interaction over a network. Let's first take a quick tour of the technologies and standards that make up web services. Web services are built on top of the web infrastructure that you learned about in the last module. You can review the lessons that covered layered web architecture, HTTP, and XML if you need a more in depth refresher. Web services start with TCP, the networking protocol responsible for reliable, ordered connection-oriented communication. On top of that it's HTTP, the Hypertext Transfer Protocol. In our lessons we will show you that web services use HTTP to send information and interact with their clients. Web services can also be built on top of other transfer protocols. But we will focus on HTTP. This web infrastructure is compatible with nearly every machine, and thus provides a strong foundation for platform independence and interoperability. That's why it is the basis for the web services we are discussing in this module. As well as for RESTful web services, which are covered in the next module. The way web services will interact in this module will be through the use of XML formatted documents, usually in a request response messaging design. XML is a markup language, and allows web services to send each other documents with structured information that is both machine readable and human readable. XML is used for many facets of web services, as you will see. Web services need to have certain functions and behaviors. Lets look at what web services must do and the standards that enable those activities. In order for a service requester to use a particular service it must invoke it. Invoking is like a method call in an object-oriented language, except that it must be done through a request in XML. Invocation will include which operation is requested, since a service may offer several along with the parameters in Data. In web services invocation is done with SOAP, a protocol specification that is based on XML and allows services to send information to one another. SOAP at one time stood for Simple Object Access Protocol. Though this meaning has since been dropped. Service requesters and service providers use these SOAP messages to send each other information. Since the messages are based on XML and sent over universally accepted web infrastructure, systems coded in different language and on different platform can easily communicate. In order for services to interact they must know how to interact. Web service description languages or WSDL is the standard protocol for describing the interface of a service. Like SOAP, WSDL descriptions are written in XML. A WSDL description will describe the interface of a service in a machine-readable fashion so that a service requester can bind itself to this interface. Binding is the act of generating the necessary code to interact with a service so that a service requester can begin invoking it. If a service interface is described unambiguously with WSDL, binding can be done by generating the necessary code automatically. The internet is a big place, service requesters and service providers need ways to come into contact. Service providers can publish descriptions of their services using UDDI, universal description, discovery and integration. UDDI is used to build public or private registries of web services. Service requesters looking for a service can search by the WSDL descriptions or other aspects of the service. This is called Discovery, together SOAP, WSDL and UDDI are the three foundational standards of web services. They allow for web services to be invoked by service requesters, to describe themselves, and to be published registries where they can be discovered. All of them rely on web infrastructure. Various standards are built on top of these three, often with a prefix WS, for example there is WS security to add security functions and WS coordination to coordinate the activities of many surfaces. We will learn about one of these standards in this module called WS-BPEL or simply BPEL, which stands for Business Process Execution Language. BPEL allows developers to combine existing services into new composite services. Composite services are services that are built with other services, which can either be composites themselves, or basic. A basic service does not rely on other services. The act of combining services into new services is called service composition. Because web services are invoked, described, and published in standardized ways, their internal implementation does not matter. A service requester and service can be on different platforms and in different languages and still effectively interact. That's not to say that these standards are enough on their own, both platforms may understand SOAP, but the SOAP message must still contain commands and parameters that are supported by the service provider. Nevertheless using web services means that building interfaces is easier because the standardised communication between services and service requester. Although the interactions are pair-wise they're implemented with web services standards. Applications can be developed in any language and on any platform that supports standard web technology. In business to business interactions, the ambiguity of who hosts the middleware, and how interactions are mediated become simpler. The role of middleware, to facilitate interactions between processes, is instead covered by web service standards. The businesses can control how they interact by choosing how to expose their services. They also don't need to provide a different interface for each outside company. As we dig deeper, keep in mind the advantages of web services, within businesses, between businesses, and in other contexts. As you learn, think about how these technologies enable platform independence and a service-oriented architecture.
