eb Services are a general model for building applications and can be implemented for any operation system that supports communication over the Internet. Web services take advantage of the best of component-based development. Component-based object models like Distributed Component Object Model (DCOM), Remote Method Invocation (RMI), and CORBA's Internet Inter-ORB Protocol (IIOP) have been around for some time. Unfortunately, they depend on an object model–specific protocol. Web services extend these models by communicating with Simple Object Access Protocol (SOAP) and XML to eradicate the barrier posed by the object model–specific protocol.
The evolution of SOAP has expanded the boundaries of the Internet. SOAP and HTTP enable you to log on to external systems and execute remote function calls. Using a Web browser in Melbourne, Australia, for example, you can execute methods on your company's mainframe in Seattle, Washington. This architecture enables Web servers to work in tandem to expose their business logic without compromising security.
Web services work by basically using HTTP and SOAP to make business data available on the Web. Web services expose business objects (COM objects, JavaBeans, etc.) to SOAP calls over HTTP and execute remote function calls. That way, Web service consumers are able to invoke method calls on remote objects by using SOAP and HTTP over the Web.
 |
|
Figure 1. Basic structure of a Web service. (Click to enlarge.)
|
Figure 1 shows you what I'm trying to explain. It's the basic structure of a Web service. The user at Location A uses the Internet as a vehicle to execute remote function calls (RFCs) on Location B's Web server. The communication is done using SOAP and HTTP.
How is the user (consumer) at Location A aware of the semantics of the Web service at Location B? This question is answered by conforming to a common standard. Service Description Language (SDL), SOAP Contract Language (SCL), and Network Accessible Specification Language (NASSL) are some XML-like languages built for this purpose. Recently, IBM and Microsoft came together and agreed on Web Service Description Language (WSDL) as the Web service standard. (Read Edd Dumbill's article "XML Protocol Technology Reference" for more information.)
How Do Clients Communicate with Web Services?
Does Location A's user actually execute methods on Location B's Web servers? That's what I asked myself when I was new to this technology. As you can imagine, that could pose a serious security threat. As Webmasters, we don't want anyone to use our Web resources and do malicious damage to our sensitive data—not to mention chewing up our bandwidth. We also have to remember that this is a distributed application. Therefore we have to be concerned about the marshalling of data.
To get around the security and data marshalling problems, we need to replicate the object behavior locally on the user's Web server. In this example, we will replicate Location B's Web service functionality at Location A. That means creating a proxy object to act on behalf of the original Web service. The proxy object will have all the publicly available data interfaces as the original Web service. But how do we get these interfaces?
The publicly available data interfaces are declared with the "Web Only" directive in the Web service's code; every "Web Only" method will be replicated at the proxy object. This protects us from exposing sensitive business logic to malicious hackers at the Web service end (Location B). The best implementation will be a thin Web proxy object class that delegates sensitive process to a back end. In a way, what we are doing is synchronizing object data exchanges between Locations A and B. This process is known as creating a proxy object at Location A.
 |
|
Figure 2. Communication between Web browser client and Web service. (Click to enlarge.)
|
The code at Location A instructs the proxy object. Then the proxy object associates with Location B's Web service and produces the results to users at Location A. Figure 2 shows the communication between a Web browser client and a Web service over the Internet.
Because the proxy object is the basic concept of the Web service invocation, the first step in creating a Web service client is to create a proxy object (see link below). Then you can use multiple platforms (Web browsers, WAP clients, PDAs, and SOAP clients) to extract data from the proxy object.
What do you think about .NET Web services? How soon will you build them? Join the discussion!
