Implementing Component Objects

The implementation side is more complicated. Along with the client proxy, the IDL compilation process produces a class whose form is derived from в section of the CORBA specification that describes the Basic Object Adapter (ВОЛ) a sot of services that connect an implementation to the ОНИ and help it handle requests. The BOA's most prominent feature is the implementation parent class (the BOAImpl class in Orbix, for instance), which is similar to the client proxy from which it is derived. However, each virtual function in this class is pure virtual, so the class is not instantiable. Rather, it is meant to be used as a derivation point for the implementation class. To provide an implementation of an IDL interface, you derive a class from BOAImpl and implement each of the virtual functions. These functions might simply return a value, or they might call down to an SQL-database access layer such as DBLibrary or connect to another remote resource. Because the object server is a process, it needs a main() (or WinMain(), as the case may be) in which calls can be made to initialize the server and the ORB run-time libraries linked into it.

The run-time libraries, which are different for the client and server, provide support for the proxy and implementation classes. On the client side, they marshal the parameters to a call, establish a TCP/IP connection to a server, and transmit the call and parameters. The server library receives the call, unmarshals the arguments, and uses a dispatch class to match the name of the method to an entry point in the implementation class. This entry is then called; when it returns, any return value follows a similar route back to the client.

Two other components of the system need to be visited. The first is a set of services – including server startup and termination – that form the

ORB core within the CORBA specification. How they are provided is up to the implementor. Iona's Orbix provides a daemon process that runs on server and name-lookup hosts, but is not needed on client machines.

The second component is the locator facility, CORBA defines interfaces by name, just as C++ defines classes by name. Interfaces are implemented in servers that run on hosts. Hosts have unique names within a network, and servers are uniquely named within a host The locator service takes the name of a server and returns a list of hosts than run if. It, is up to the client to decide which host to request в server binding; them. Clients can be hardwired to a specific host, but use of the locator facility grants clients complete independence from the back-end host/server structure.

Designing the Virtual Bookshop

You can approach the architectural design of the virtual bookshop at three levels: the distributed-object model, the composition of the objects into server processes and the client/server architecture, and the host architecture on which the servers run

A CORBA object server may implement any number of interfaces. In this method one server process per object type is used. In reality, you might group related objects into one server for efficiency. The architecture of the servers is more or less set by the CORBA implementation: a main entry point, the interface implementation classes, the ORB run-time libraries, the socket DLL, the TCP/IP stack, and potentially connection layers for other resources such as databases. On the other side, proxy wrapper layering – one proxy and one wrapper for each object in the model are used. The client will also contain user-interface code and controlling logic. The HTTP server for the Web interface is simply a special-case client of the ORB.

Realizing this architecture would be a matter of implementing each of the servers, as well as the client libraries. There is a lot of potential and attendant flexibility for the design of supporting services that rely on the ORB but are outside the scope of its specification. Servers will benefit from object garbage collection, remote-event reporting and server control, centralized security, and so on. These services can be provided at the ORB interface level, without resorting to specialized network programming. The clients offer perhaps the greatest potential and challenge for achieving object independence. The layering concept can be expanded to allow clients to load object definitions dynamically, and objects can supply their own user-interface constructs, which helps tremendously when dealing with versioning

issues. Once the clients and servers have been designed, it remains only to outline a strategy for structuring the physical resources on the back end.

That strategy involves answering many questions:

1. What platform should the server run on? CORBA implementations are available for all major platforms, from Windows NT and Windows 95 to flavors of UNIX, AS400, and the like.

2. How many servers are needed for a given object type? Connections to servers are limited by the TCP/IP stack-connection limits, efficiency and performance concerns, and the number of clients exposed if a given server goes down.

3. How many servers should run on a given host, and of what types? You may choose to run one type of server on a host, or to roll out a suite of servers duplicated on every host.

4. What, database systems will be used, on what platforms, and how will the object servers communicate with the databases? Systems involving TCP/IP connectivity between clients and object servers, and NETBEUI connectivity between object servers and Microsoft SQL Server databases have been built. Many other models are possible.

Each question may be answered differently for a given app, but you can determine which back-end components are necessary and propose an organization for this example.

The bookshop will need one object server for each type of object in the model. Each server will run on a separate host with a daemon to start it, stop it, manage it, and provide information about it to clients. Initially (until the customers roll in) you'll have one host per type. If business booms and the Order server host is overwhelmed, you can roll out, another by simply adding a line to the locator database. You'll also need at least one fat database server. You could get a very good start using SQL Server on a fast Pentium and grow from there. The other components needed are a name host and a Web server. The name host is a specialized host that runs the ORB daemon and maintains the locator database. It is the only host that clients need to know the name of. At run time, a client will specify this host as the lookup server for bind requests. It will see a lot of traffic, but each connection will last just a few milliseconds under normal circumstances. The Web server is a specialized client of the ORB, which queries distributed objects and formats the results into HTML documents for return to a browser. The completed system architecture for the book shop you can see at the figure.

How did you like it?