View source for The Merging of Object-Oriented and Distributed Systems

''by [[Rob High]]''

The System Object Model (SOM) with the Distributed SOM (DSOM) framework is IBM's implementation of the Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA). This framework provides you with transparent communication between distributed objects. That is, you can now invoke a method on an object irrespective of whether that object is located in the same process, in another process on the same machine, or on another machine across the network.

If you're familiar with distributed systems, then you probably know that the three major inhibitors to achieving a scalable solution are:
* Naming (How do you figure out what resources are available to you and how to get to them?)
* Security (How do you prevent people (you don't necessarily know) from abusing resources that belong to you?)
* Interoperability (How do you deal with various resources on various platforms from various vendors?)
In addition, many robust distributed applications must be multithreaded to perform properly. The SOMobjects product will address each of these concerns.

==Naming==
OMG has adopted an object-oriented standard for Naming Services. Basically, this service partitions the name space into contexts - each context is an instance of the NamingContext interface. Within a context, you can bind a name-component to an object - including other NamingContext objects. As such, you can organize the name space into a hierarchy, which you can then traverse. You can resolve a compound name by resolving the first-name component within a context, and recursively resolving the rest of the name with the bound (context) object.

Knowing this, it's not hard to see how you can map the OMG Naming Service interface to the DCE Cell Directory Service (CDS). Contexts, in this case, represent specific directories; the path to a directory represents the context traversal needed to resolve that directory.

We expect that SOMobjects will provide an implementation of the OMG Naming Service, based on DCE/CDS. This will let DSOM applications register objects. You will then be able to locate the objects by name and access them from anywhere in the network. Additionally, you will be able to take advantage of the benefits that CDS already offers: a reliable, consistent, location-independent method for naming and using resources inside a cell. And if the CDS in your institution already contains objects, such as RPC bindings to a server, you can still access those non-object-oriented objects through the object-oriented services provided by SOMobjects.

Additionally, we expect that the OMG Naming Services will be implemented on top of a number of directory services. At that point, you will be able to link multiple directories into a single name space. We think that several vendors will have implementations of the OMG Naming Service. Therefore, even though no implementations exist today, you should begin now to understand this interface and prepare to use it in your applications.

See Common Object Services Submission; Volume 1, 01-Mar-1994, John Wiley and Sons, Inc., NY, for more information on OMG Naming Services. This and other OMG documents can be obtained from OMG at:
:Object Management Group, Inc.
:Headquarters
:492 Old Connecticut Path
:Framingham, MA 01701
:Tel: (508) 820-4300
:Fax: (508) 820-4303

==Security==
Another concern is security. You can consider security to be Authentication, Authorization, Secrecy, Integrity, Auditing, and Administration. Authorization is subtly different between procedural systems and object-oriented systems. For example, in procedural systems you use access control to constrain users to accessing resources in certain ways; in object-oriented systems you use it to constrain users from performing particular operations on certain objects. This will drive the need for further research to determine the best approach to dealing with authorization in object-oriented systems.

However, much of the rest of security is essentially the same for procedural and object-oriented systems. Object orientation does lend the ability to create abstractions for security that enhance the interoperability of different security solutions. For instance, CORBA defines a get_principal operation that returns a PRINCIPAL object.

This object is an abstraction of the user. As such, you can load it with credentials of different types, some of which might be unique to one security system or another.

DSOM will integrate DCE's Kerberos-based security services to support authenticated method-requests. The get_principal operation will reliably and securely identify who made the request. If the user cannot be authenticated, the method request will not be passed to the object. Because DSOM will use the DCE registry, you only need to define users to the system once. Users only have to sign-on once to use both RPC requests as well as DSOM requests. And, because DSOM will handle authentication under the covers, you don't have to change your application to run it securely.

==Interoperability==
Version 2.0 of the SOMobjects product implements remote method calls using a native protocol that includes simple data translation and object location services. The native protocol implementation is sufficient for the workgroup environments for which SOMobjects 2.0 was intended: small- to medium-size LANs of AIX, OS/2, and Windows systems.

Future versions of DSOM will use DCE Remote Procedure Call (RPC) to achieve a higher degree of scalability and interoperability. In fact, IBM and a number of other companies (Hewlett-Packard, DEC, NEC, HyperDesk, and OSF) have proposed a standard protocol for interoperability among CORBA-compliant Object Request Brokers based on DCE RPC.

See Joint Submission on Interoperability and Initialization (Document 94.3.5), Object Management Group (OMG), for more information on this proposal.

==Threads==
The SOM kernel and the other SOMobjects frameworks (DSOM, Persistence, Replication, and Event Manager), have been made thread safe concerning multithreaded processes. By thread safe, we mean that the SOMobjects runtime code has been implemented using critical sections. These critical sections protect those pieces of code that must be executed serially in a multithreaded application.

Only the OS/2 for SOMobjects Release 2.0 contains this multithread enabling because neither AIX nor Windows provides any native threading. Since then, however, thread support has become available in the DCE runtime (for both AIX and OS/2), and is available natively in the AIX 4.1 operating system.

Consequently, we are developing a flexible mechanism that will let an application use SOMobjects with any thread package it chooses. Support for native threading (for example, on OS/2 and AIX) will be enabled by default and you can easily select DCE threads. This does not provide an object-oriented threads service, but it does allow you to configure the SOM runtime to use the same threads package that you are using in your application.

==Conclusion==
DCE provides a robust set of services that address the problems of large distributed systems. DSOM will integrate key DCE services to enable you both to build and use mission-critical enterprise applications.

However, SOMobjects will not require DCE. All the services described above will also be available in a future version of SOMobjects without DCE. However, if you want to enable your environment for scalability and interoperability, DSOM will exploit the presence of DCE to achieve the desired quality of service.

{{IBM-Reprint}}
[[Category:Developer Connection News Volume 6]][[Category:SOM Articles]]