Chapter 1: Introduction to Web Services

Defining Objects and Web Services

The introduction of object-oriented programming promised the reusability of code across multiple systems and architectures. Many predicted that programmers eventually would not need to create their own objects because code repositories would possess all the necessary code in class files.

Some vendors took advantage of this and provided class libraries that took care of basic functionality. For example, many commercial libraries in C++ contain standard ways of dealing with date and time. This saves the developer time because the date and time functionality is already written in a standard way. When newer languages emerged, such as C# and Java, this basic functionality came as part of the language.

However, the concept of a central repository does not work in every situation. For example, because business logic varies from corporation to corporation, it would be impossible for a repository to contain that code. In this case, commercial libraries can only help by providing basic and generic classes that are commonly needed, but these libraries cannot always contain the necessary logic that a corporation needs because its situation is so unique. Certain business situations, such as in the banking industry, allow vendors to create prepackaged libraries because government regulations enforce certain logic.

At first, objects were only available to programs running on the same machine. For example, on the Windows directory of a PC there are several Dynamic Link Libraries (dll) files that contain information for Windows and other programs to operate. If you do a search for *.dll from your Windows Explorer in the Windows directory, your results may look like Figure 1.1.

Figure 1.1: Search Results For *.Dll In The C:\WINNT Directory.

Each of these dlls contains information that several applications use to create objects. The dlls reside in the Windows directory so applications can find them without much work and different applications can then share the same dll. To get a better idea of a library, class, and object, take a look at the C# example in the following section.

Libraries, Classes, and Objects

The best way to understand libraries, classes, and objects is to see them in action. In the first code example, C# is used to define a library. It is a library because it does not contain a main method for the code to execute, and because the type of project chosen is within Visual Studio™.

This library example defines the namespace HelloWorld. This is just a unique identifier that prevents the collision of method and class names, which is helpful in large projects. Next, the code defines the class MyHelloWorld. A class is a container that possesses all the functionality and values that a particular object needs to contain. Finally, the library defines the method, also known as a function, DisplayHelloWorld. This is the only functionality for this class other than the default constructor. Thus, any object instantiated from this class will only be able to call DisplayHelloWorld.

using System; namespace HelloWorld {   //simple class to display Hello   public class MyHelloWorld   {     public void DisplayHelloWorld()     {       Console.WriteLine("Hello World!");      }   } }

In the next C# code example, the code, once compiled into an executable, calls the functionality in the library just created. When you compile the previous code example, it creates a dll. When you start a new project to use the code in the following example, be sure to open the Solution Explorer window and click on “References.” Then browse to the location of the dll created when you compiled the previous library. Figure 1.2 shows the HelloWorld dll added to the “References” in the Solution Explorer.

Figure 1.2: Shows The Helloworld Dll Added To The “References” Of The Project.

Once Visual Studio.NET knows where to find the dll, you need to tell your executable that you want to use the functionality in the library. In the next C# example, the code must first define which namespaces it uses. Remember that the previous code example defined the namespace HelloWorld. By stating using HelloWorld; in the code, the executable knows to use the methods contained in the library example.

The example now defines the class SayHello and defines a main method. The main method is an important difference between a library and an executable. The library only contains code for executables and other libraries to use. The executable actually runs.

Within the main method we actually define the object hi which is of type MyHelloWorld. Remember that MyHelloWorld is the name of the class defined in the library. The object hi now calls the only method available to it, which is DisplayHello().

using System; using HelloWorld; class SayHello {   static void Main()   {     MyHelloWorld hi = new MyHelloWorld();     hi.DisplayHello();   } } 

Figure 1.3 shows the executable displaying the output defined in the library example.

Figure 1.3: Sayhello Executable Displaying The Output Of The Displayhello Method Defined In The Library Example.

Using Remote Objects

Using objects in software is a great way of reusing code at the application level on a local machine. If you’re in a corporation and you’re maintaining several hundred or thousand workstations and the applications on each system, having these libraries on every system becomes a maintenance headache. If an update is needed, every system within a corporation needs the new code installed. Remote objects, which are objects instantiated on a central server and can be accessed throughout a network including the Internet, become critical at this point.

A remote object is available to a program across a network or even the Internet. Common Object Manifest (COM), Common Object Request Brokerage (CORBA), Remote Method Invocation (RMI), and Remote Procedure Call (RPC) all invoke objects remotely and are described in greater detail later in the chapter. The promise of each of these methods allows a developer to change code in one place and then all systems and applications using these objects instantly have access to the new code. The disadvantage here is that if you make a coding error, all the systems now access that error. This causes all the applications using that code to fail. Figure 1.4 illustrates how a remote object can be shared across multiple applications.

Figure 1.4: Remote Objects Can Be Shared By Several Applications In A Business Setting. In This Case, The Remote Object Server Contains Objects For Applications Running On Workstations, Mainframes, Laptops, And Other Servers.

Reaching the promise of remote objects has been difficult. Implementing CORBA takes a great deal of effort and a company incurs great expense to purchase the Object Request Broker (ORB). An ORB is the server needed for applications to use remote objects. Only a small percentage of programmers implement CORBA on a daily basis, so it is also difficult for a manager to hire someone who understands the technology.

COM and COM+ offer a somewhat simpler solution to remote object computing. Most of the software needed, such as Visual Studio and Microsoft Transaction Server, are relatively inexpensive and easily obtainable, but COM and COM+ are typically only available to Windows applications. So these objects are not available to applications running under UNIX or another non-Microsoft operating system. In addition, COM takes a highly skilled programmer who understands everything about this technology. Again, it is difficult to find a programmer at this level.

The quest for remote object technologies that are simpler to use and implement brought RMI and RPC into the forefront briefly. They are simply request and response systems whose function is similar to how a Web page responds to a request from a browser. The problem here lies with the implementation that each vendor decided to pursue, and thus working with RPC software from one vendor wasn’t always compatible with another’s. Again not having cross-platform compatibility prevented remote object technology’s general acceptance.