Middleware

"Computer designers talk a lot about compatibility, but secretly they hate the idea of standardization. It cramps their style." - Charles Platt

Distributed Systems.

In a distributed environment common communication amongst components is important. Subsystems within a distributed environment could be built using diverse technologies. For instance, one subsystem can consist of a Java platform and another subsystem can be a Microsoft platform. Thus a conforming logical layer is needed for diverse components to easily communicate. This logical layer is called middleware. In IEEE Computer magazine, Gorton et. al., provide the following definition: Middleware refers to a broad class of software infrastructure technologies that use high-level abstractions to simplify construction of distributed systems. There are three general and widely accepted logically distributed architectures:

1-Tier Architecture

This local architecture consists of monolithic applications that run on a single processor and not in a truly distributed environment. Most legacy applications are locally structured in that all of the logical layers exist on the client machine including the back-bend database such as MS Access. Small PC-based apps fall into the single-tier architecture as well. Local tier systems are not scalable and usually do not integrate well with enterprise systems. However, if the local tier architecture did have an advantage it would probably be security.

2-Tier Architecture

A 2-tier system is a typical client/server application. Minimally, a 2-Tier architecture consists of a client accessing a remote server, where a database is logically a part of the server component. The front-end tier usually contains the UI, the business and data source access logic. Where as in the back-end the remote server simply provides the database to the client. These clients are usually called fat clients because they contain the bulk of the processing. 2-Tier architectures are difficult to maintain and are definitely not effective in the Web paradigm.

3-Tier Architecture

Ideally, a 3-tier system logically consists of a front-end UI client, a server and a back-end database. Minimally, the business logic and database is located at the server and the UI process resides at the client. In any case, this middle tier is what is referred to as middleware. In this architecture, the front-end client usually does not contain any business rules thus making it a thin client, which helps in front-end performance.

However, some transparent non-UI processes exist on the client to actually help in overall performance that could otherwise be lacking due to network round trip delays. When a 3-tier system contains many client instances it is ideal to hold some state in the client and less state on the server. Thus objects in the middle layer can be stateless, which actually increases coupling, where methods and functions contain very many parameters and the objects do not contain properties or attributes to avoid persistence. Even though this goes against OO principles, this solution is currently necessary for scalability purposes.

Cube: User Interface
Cube: Business Logic
Cube: Database Access
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


     High Level 3-Tier Logical Layout

Communication

Distributed applications can communicate with each other either synchronously or asynchronously. Asynchronous applications can overcome the limitations of low bandwidth. Due to the decoupling of the sender and receiver, asynchronous communication is also more scalable. Synchronous applications require more constraint in that communication needs to be timely. The sender and receiver have to collaborate on the transmission of information. The World Wide Web is an example of synchronous communication.

DCOM Tutorial

The following tutorial sets up a very basic client server application using DCOM (Distributed Component Object Model) in Visual C++ 6.0. The server component will be an out-of-process COM server (which can be easier to work with than an in-process COM server) built with the ATL wizard and the client will simply be a Win32 Console app. Furthermore, the DCOMCNFG (built in) utility will be used as well to update the registry. You will then test the client and server components locally so that you know that any errors at that point will not be due to distribution.

Set up the Server Component:

1. Create a new ATL COM App called TheServer in the dcomtests directory in the EXE mode.

2. Right now you have a skeleton so let's add a COM object. From the Insert menu click on New ATL Object.

3. Select the "Simple Object" (which should already be the default). For the short name entry, enter TheClass then simply click on OK.

4. Next, add a method to the the class. In the Class View, right click on the ITheClass interface and select Add Method (note you'll see 2 ITheClass in the ClassView either one is fine).

5. HRESULT is the default and only return type. In the Method Name entry, enter GetFileContents. In the parameters entry, type in [out] BSTR *pVal and then click OK.

6. Now you can implement this method with the following code by double clicking GetFileValue (BSTR *pVal) method underneath the ITheClass interface:

int value = 0;
ifstream inFile;

inFile.open("c:\\dcomtests\\sample.txt");
inFile >> value; inFile.close();
char buf[32];

_itoa(value, buf, 10);

*pVal = _com_util::ConvertStringToBSTR(buf);

return S_OK;

7. Make sure to include the following headers #include Üfstream.hÝ #include Ücomutil.hÝ. Also include the comsupp.lib library by right clicking on the "TheServer files" title in the FileView tab. Click settings and then the link tab and the put it in the Object/library modules entry then click on OK.

8. Save everything and then build your project. Upon success you should see the following in the output window:

----------Configuration: TheServer - Win32 Debug-----------
Compiling...
StdAfx.cpp
Compiling...
TheServer.cpp
TheClass.cpp
Generating Code...
Linking...
Performing registration
Server registration done!
TheServer.exe - 0 error(s), 0 warning(s)

9. The process automatically registers the server component and creates a TLB (Type Library) file for the client to use.

10. Finally, create a file called sample.txt with the value 1234 and place this file in the dcomtests directory. The probability that your client machine will have the same directory, file and file contents would be highly unlikely therefore confirming that you're communicating across a network from machine to machine.

 

 

Set up the Client Component:

1. On the same machine that you built your server, in Visual C++ 6.0 in the file menu click on the new item. Highlight the Win32 Console Application and for the project name type in TheClient all in the same directory as the server was built in, dcomtest and then click on OK.

2. Select the "A Simple Application" radio button and then click on finish and OK.

3. Open up StdAfx.h and insert the following line underneath where it says // TODO: reference additional headers your program requires here:

#import "..\TheServer\TheServer.tlb" no_namespace named_guids

4. Next add the following smart pointer

ITheClassPtr pTheClass;

so that your TheClient.cpp file looks like the following:

// TheClient.cpp : Defines the entry point for the console application.
// 

#include "stdafx.h"
 
ITheClassPtr pTheClass;
 
int main(int argc, char* argv[])
{
  return 0;
}

5. Now add the following code in the body of the main method in TheClient.cpp file:

        HRESULT hr;
        CoInitialize(NULL);
        hr = pTheClass.CreateInstance(CLSID_TheClass);
 
        if (FAILED(hr))
        {
               printf("Failed");
        }
        else
        {
               char *buf = "";
               BSTR strVal;
               hr = pTheClass->GetFileContents(&strVal);
 
                if (FAILED(hr))
               {
                       _tprintf(_T("Error: (%08x)\n"), hr);
               }
               else
               {
                       buf = _com_util::ConvertBSTRToString(strVal);
                       printf("%s\n", buf);
               }
        }
 
        CoUninitialize();

6. Make sure you include #include Üstdio.hÝ and #include Ütchar.hÝ in stdafx.h.

7. Now build and run this. You should get a console result of:

1234
Press any key to continue

Let's Now Make it Distributed

1. Copy the client app to the remote computer.

2. Now you need to register the server on the client machine. Click on Start and run on the Windows taskbar. Type in the following:

\\ServerComputerName\debug\TheServer.exe /regserver

Make sure that this path (or rather the debug directory) is shared out.

3. Now it is time to open the DCOMCNFG utility by simply going to start, run and type in dcomcnfg.

4. Select the TheServer entry and then click on the Properties button at the bottom left.

5. Click the Location tab and then check "Run application on the following computer:" and type in the server computer name such as ServerComputerName.

6. Also, uncheck the Run application on this computer.

7. Click OK to close the Properties dialog box and then click OK to close the DCOMCNFG utility. You're done.

Now run the client and view the file contents and pat yourself on the back for a job well done. Ideally, one can set up a VB client talking to a C++ server. Furthermore, if you're ambitious, then instead of reading a file try reading contents from a database such as SQL Server.

Summary.

The greater the number of potential clients, the more processes can be cached on the client side where possible to aid in performance. For instance, a web system ought to have some sort of object model for its clients and stateless objects remote on the server component. For smaller systems, for instance, in a more esoteric LAN, more objects on the server side ought to maintain state.

There are three major existing middleware technologies: (1) DCOM (2) RMI and (3) CORBA. DCOM is Microsoft's answer to distributed OO development. RMI stands for remote method invocation, which uses the JVM as a platform for executing object methods and is Java's version to distributed computing. CORBA, which stands for common object request broker architecture, is yet another kind that is an open standards solution.

One common theme amongst all of these technologies is referencing a remote interface instead of the object and its implementation. There are many references online that explain these competing distributed technologies. Middleware, such as DCOM, provides transparency to both the server and client applications. Comparing with other methods such as sockets or pipes entails differences in data representations between computers. For instance, a 32-bit integer on one computer could be stored big-endian and the opposite on another computer. This leads to too much implementation dependence. Distributed applications can become complex because of security, administration and installation purposes.

Links

http://middleware.internet2.edu/

http://www.middleware-company.com/

http://www.nsf-middleware.org/

http://www.eecg.toronto.edu/middleware2004/

http://www.sei.cmu.edu/str/descriptions/middleware.html

http://www.middleware.org/

http://dsonline.computer.org/middleware/