Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

WHAT IS A LANGUAGE MAPPING?

CORBA IDL is used to describe application and system interfaces in a manner that is independent of programming language and computer platform. A language mapping is a standard to convert the IDL to a particular programming language, like C, C++ or Java.

WHAT ARE THE CURRENT LANGUAGE MAPPINGS FOR CORBA?

The OMG has standardized the following language mappings for IDL:

1. C
2. C++
3. Smalltalk
4. Java
5. Ada
6. Cobol
7. COM-based language bridge, e.g., Visual Basic

There is also a standardized reverse mapping from Java to IDL.

There are other language mappings that are available from various vendors:

1. Tcl
2. PL/1
3. LISP
4. Python. Information can be found at Python language mapping
5. Perl

WHAT IS THE PURPOSE OF IDL?

IDL stands for Interface Definition Language. Its purpose is to define the capabilities of a distributed service along with a common set of data types for interacting with those distributed services. IDL meets a number of objectives:

1. Language Independence:
2. Distributed service specification:
3. Definition of complex data types:
4. Hardware Independence

DO I PROGRAM IN IDL?

No, it is an interface language. Applications are not programmed in IDL. IDL is used to define two basic types of entities:

1. Complex Data types shared between clients and servers: IDL supports 8 basic data types and allows complex data types to be composed of the basic types.
2. Capabilities of Distributed Objects (CORBA Interfaces)

IS IDL A SPECIFICATION LANGUAGE, AN IMPLEMENTATION LANGUAGE, OR BOTH?

A specification language.

IDL makes a strong separation between the specification of an object and the implementation of that object. Programmers who use the interface of an object have no idea whatsoever how that object is implemented. For example, the object doesn’t even need to be implemented using an OO programming language.

This is called “Separation of Interface from Implementation,” and is a very important concept in OO in general and in CORBA in particular.

DOES MY IMPLEMENTATION NEED TO USE INHERITANCE JUST BECAUSE MY IDL INTRERFACE USES INHERITANCE?

Nope.

Even though a CORBA interface might utilize inheritance, the object implementation is not required to utilize inheritance. For example, given the following two IDL interfaces:

    interface Base           { void f(); };

    interface Derived : Base { void g(); };

Suppose interface Base is implemented by class Base_impl and interface Derived is implemented by class Derived_impl. The key insight of this FAQ is that class Derived_impl does not need to inherit from class Base_impl. For example, Derived_impl could implement method f() directly, or it could contain a pointer to a Base_impl object and delegate f() to that object, or it could use some other technique.

This is an example of the separation of interface from implementation.

HOW DO I EXPRESS AGGREGATION IN IDL?

The aggregation of two objects is a very common OO design concept. Aggregation is also known as has-a and contains.

Since IDL doesn’t support “public data,” a programmer that is using an IDL interface cannot tell whether an aggregation is actually implemented using aggregation or by some other technique. In other words, IDL is a specification language that separates interface from implementation. In particular, IDL does not support implementation constructs such as aggregation.

However logical aggregation is supported by IDL: IDL lets you specify an operation that returns another interface, and this second interface could represent an object that is logically contained within the first object. Whether it’s actually implemented using aggregation or not is an implementation issue, not a specification issue, and the implementer can do it either way without requiring any changes to the IDL interface.

Note that DCOM directly supports aggregation since DCOM combines implementation issues with specification issues. The COM<->CORBA interworking specification actually maps aggregation to and from inheritance (CORBA IDL supports inheritance directly, and DCOM supports aggregation directly).

DOES CORBA HAVE SUPPORT FOR C++ VIRTUAL FUNCTIONS?

Yes.

CORBA IDL is a technology that lets you specify (“describe”) interfaces. It happens that each method of each CORBA interface is implicitly virtual, in the sense that the method will employ dynamic binding at runtime. However the implementation technique doesn’t have to have anything to do with the typical C++ technique (virtual pointers and virtual tables).

IS IT TRUE THAT CORBA IDL CAN SPECIFY INHERITANCE BUT NOT “VIRTUAL” METHODS?

Not really.

Technically speaking, you can’t specify “virtual” in CORBA IDL since “virtual” isn’t a CORBA IDL keyword. However the effect of the C++ keyword “virtual” is to cause dynamic binding to occur, and since all CORBA IDL methods are implicitly dynamically bound, CORBA IDL actually does support the “virtual” concept.

WHAT IS A GOOD IDL INTERFACE?

Obviously, there are a lot of application specifics that need to be considered. But there are also some rules of thumb:

• Recognize that the interface to an in-memory object and an interface to a distributed object are likely very different.
• Remote calls include network overhead. This puts a remote call in the “at least milliseconds” category, versus an in-memory call, which is in the “at least microseconds” category.
• As much as possible, a single IDL operation should coorespond to a single unit of work in the business system.
• IDL interfaces tend to be overly generous on the amount of information returned. This is because you don’t want a situation where clients have to make follow up calls to get supporting data.
• There are many different types of interfaces and design patterns. Some of the more common include:
  • Manipulation Interface – This is the interface used to manipulate a single object. E.g., a BankAccount.
  • Factory Interface – this is the interface used to create and delete objects. E.g., a Bank that creates and deletes BankAccounts. Or more explicitly, the interface could be named BankAccountFactory.
  • Search-To-Select Interface – This is the interface used to try to identify which object to manipulate. E.g., a BankAccountFinder that supports operations that take search data and return 0, 1, or more BankAccount object references or secondary keys.
  • Manager Interface – This is more a singleton, RPC style interface, whereby the object to manipulate is an argument in the operation rather than the object the call is made on. This style of interface can also be used to manipulate several objects in one call, and hence is used more in batch clients. E.g., BankAccountManager that has an operation taking a sequence of BankAccounts to run credit checks on.
• Distinguish conversational interfaces that are used by a client to represent a client-specific context versus entity interfaces that are used to represent a shared business object. The classic example is an order processing system, wherein the shopping cart is a conversational interface and the items being bought are entity interfaces.
• Consider where the transactions are in the system and how these map to the interface operations.
• Consider using the concept of idempotency. This helps with determining transaction completion status and recovery when asynchronous transactions are used or if the client is not a resource in the transaction.

There are some books on CORBA and IDL design patterns. Effective IDL design is probably one of the largest influences on the success of the system.

WHAT IS A FACTORY?

A factory is a CORBA Object that returns another CORBA object via one of its CORBA operations. There are many different types of factories with many different purposes. In fact, the OMG has defined several services that are actually factories.

WHAT ARE SOME TYPICAL TYPES OF FACTORIES?

There are several types of factories:

1. Generic: A generic factory is a factory (CORBA Object) that is capable of returning other CORBA Objects. These CORBA Objects are generic. This means that they can be of any type, rather than a specific type. The SomeFactory::GenericCreate() operation causes the SomeFactory interface to be a generic factory. The NamingContext object defined as part of the CORBA Naming Service is a classic example of a generic factory.
2. Specific: A specific factory is a factory (CORBA Object) that is capable of returning a specific type of pre-defined CORBA Object. The SomeFactory::SpecificCreate() operation causes the SomeFactory interface to be a specific (or typed) factory.
3. In-process: An in-process factory is a factory which is implemented in the same process as the object which is created or managed by it.
4. Out-process: An out-process factory is a factory which is implemented in a process different from the one of the object which is created or managed by it.

    interface AnObject
    {
      boolean ping();
    };

    interface SomeFactory
    {
      CORBA::Object GenericCreate();
      AnObject SpecificCreate();
    };

DOES THE CORBA SPECIFICATION DEFINE ANY SPECIFIC CAPABILITIES FOR A FACTORY OBJECT?

The CORBA Lifecycle specification defines a GenericFactory interface from which all factories should inherit, but this is not required. The CORBA specification also defines a factory for factories, known as a factory finder. The factory finder is a just a CORBA factory which act as a factory for other factory interfaces.

CAN CORBA APPLICATIONS BE MULTI-THREADED?

The CORBA specification does not currently address multi-threaded architectures. Provided that the CORBA product is thread safe, threaded CORBA applications can be developed. CORBA clients and servers can both be multi-threaded. Daemon processes provided with CORBA products may be implemented as multi-threaded servers by the CORBA vendor. Different multi-threaded models or multi-threaded architectures may be supported by a particular CORBA product. A particular ORB may provide frameworks to simplify the development of multi-threaded CORBA applications.

WHY WOULD I DECIDE TO IMPLEMENT A CORBA CLIENT APPLICATION WITH MULTI-THREADING?

Client-side CORBA applications might require multi-threading to allow it to perform other tasks while it is waiting for a synchronous remote invocation to return. It might desire this functionality for several different reasons.

1. A client application might wish to leverage the static request/response style of invocation but achieve some degree of asynchronous communication. Perhaps the client wishes to perform several synchronous invocations within their own application threads. This would allow a client to obtain results from several remote servers more quickly. There are several reasons the use of multi-threading might be preferred over the use of DII. DII might be complicate application source code. Application polling associated with the deferred synchronous invocation might result in a performance bottleneck.
2. A client-side CORBA application might need to respond to events such as incoming invocations, connect requests, or GUI events (mouse clicks, etc.) CORBA products that support only blocking style remote invocations will be unable to process any of these events. This would mean that a client-side application would be unable to respond to GUI events for the duration of any remote CORBA invocations. This is not an issue for short duration invocations but becomes a problem for longer invocations or in failure or time-out situations. Performing remote invocations within dedicated threads can avoid this issue.

WHY WOULD I DECIDE TO IMPLEMENT A CORBA SERVER APPLICATION WITH MULTI-THREADING?

CORBA server applications may be multi-threaded for serveral reasons.

1. A particular CORBA object may support an operation whose implementation performs some blocking routine. This may be a disk read or database query. Let us assume that the server application processes all CORBA events within a single main thread. This means that the server will be unable to respond to incoming connection requests or invocation requests while the blocking operation is in progress. Multi-threading can be used to avoid these sorts of situations. The server can be more accessible if multiple threads are allowed to process (an block during) incoming CORBA events.
2. A single multi-threaded server process supporting many (>25) clients is much more efficient that many (>25) single-threaded server processes each supporting its own client. Running a single application with multiple threads requires less machine resources than running multiple applications. This advantage can be seen even if the operation invocations are of short duration and non-blocking.

ARE THERE DIFFERENT THREADING MODELS THAT CAN BE USED WITHIN CORBA SERVERS?

There are several different common architectures that can be used within multi-threaded CORBA servers. A server process needs the ability to process CORBA messages. These messages are processed by one or more threads, as determined by the application architecture. The CORBA specification does not specifically address threading capabilities within CORBA compliant ORBs.

An ORB vendor is free to support only single-threaded application or to support multi-threaded applications. If the ORB does support the development of multi-threaded applications, the ORB might only support a subset of the threading models listed below. Significant threading code might still need to be developed to achieve one of the models. For example, the ORB vendor might support a set of application hooks (i.e., interceptors or filters) and allow you to implement threading code with the native OS thread API. On the other hand, the ORB product might provide a built-in feature so no custom thread development needs to be done. The CORBA specification does not address this issue.

When you consider different threading models, it is important to consider what kind of concurrency is desired. While it may be advantageous that two or more threads can be concurrent, it may also be disadvantageous. Also, the resources consumed by idle or active threads, and also the resources consumed for thread creation and deletion, need to be considered.

1. Thread-Per-Request: With this architecture, the CORBA server ensures that each incoming message is processed in its own thread. This means that multiple requests will be processed concurrently. There are concurrency issues. If two or more requests (threads) are using the same object, then some form of concurrency control (locking) is needed. Also, if two or more requests (threads) are from the same client, then perhaps the requests should be serialized instead of allowed to execute concurrently.
2. Thread-Per-Client: With this architecture, the CORBA server ensures that each incoming message from a distinct client is processed in its own thread. This is similar to Thread-Per-Request except multiple requests from the same client are serialized. Requests from distinct clients are concurrent. The way that one client is distinguished from another is an interesting problem. Typically, this is done by looking a the network connection and determining that the clients are the same or different. The server needs the ability to monitor client connections and the inception and termination of this connections (typically at a network level, not an application level).
3. Thread-Per-Server-Object: With this architecture, the CORBA server ensures that each object in the server gets it own thread of execution. This means that multiple requests will be processed concurrently provided they are using different objects. Multiple requests using the same object are serialized. There are concurrency issues, and some locking strategy is needed. Also, deadlock is very possible. It may be that threading or locking at each object is too fine a grain, and a more appropriate choice is putting the thread/lock boundary around a group of coordinating objects.

For each of the above threading architectures, the required server threads can be either created on demand or recycled through a thread pool. The advantage of creating threads on demand is that an arbitrary number of threads can be supported. A thread is created, used, and then reaped. The Thread-Per-Request model would create/reap a thread for each request; the Thread-Per-Client model would create/reap a thread for each client connection; the Thread-Per-Server-Object model would create/reap a thread for each CORBA object instantiated in the server. Thread creation and reaping has some cost, which may be large or small depending on the operating system thread support.

A thread pool is an alternative to creating threads on demand. In this approach, a fixed number of threads are created and cycled in turn to meet the demand for threads. If the demand for threads exceeds the pool size, then further requests for threads are blocked until one of the existing threads is recycled. This approach has the advantage of capping the server resources.

ARE THERE REASONS TO AVOID THE DEVELOPMENT OF MULTI-THREADED CORBA APPLICATIONS ?

Building multi-threaded applications requires an additional efforts in the area of design, development and testing. Issues like concurrency and synchronization become more critical. Difficult to find software bugs are unfortunately easy to introduce. A specific set of application requirements can often be met without resorting to the use of threaded clients or servers. This is not true with all applications. Some do require multi-threading to achieve their desired level of concurrency, performance or scalability.

Yes.

There is a number of ways that CORBA objects can be accessed from web based applications.

1. Java applets can be downloaded via web based applications. These Java applets are capable of directly accessing CORBA objects via IIOP. There are a number of Java based ORBs available on the market. By introducing CORBA communication into a Java applet, arbitrary CORBA services can be accessed directly. These services can be developed in any language supported by CORBA or on top of any CORBA product that supports IIOP.
2. Pure HTML based application are capable of accessing CORBA objects via CGI gateways. Arbitrary unknown CORBA objects can be accessed by a single pre-compiled client application via Dynamic Invocation. A pre-compiled application can dynamically generate HTML pages based upon results obtained from arbitrary invocation of operations. This solution has the advantage of being based only upon HTML, it is not specific to a particular web browser.
3. A refinement of the above approach includes the various Web server extension technologies, such as servlets, ASPs, JSPs, etc.
4. A similar approach to the CGI CORBA gateway described above, can allow CORBA objects to be accessed without the performance impact associated with process spawning. A plug-in can be developed for a particular browser which enables it to speak directly to any CORBA object through IIOP.
5. Web servers from Netscape and Oracle are beginning to support IIOP directly. This means that in addition to supporting HTTP, FTP access and news group access, they will be capable of accessing any CORBA object capable of supporting IIOP.

HOW CAN CORBA ENABLE CLIENT/SERVER COMMUNICATION?

A server is defined as an Interface in CORBA IDL. Data passing between the client and the server is defined as IDL structures, sequences, etc. The IDL is compiled with an IDL compiler and the generated code is included within the client and server processes. The server implements a particular interface. The implementation is the distributed object. Clients communicate with the object through an object reference. When an operation is performed on the object reference, network communication occurs, operation parameters are sent to the server and the actual distributed object executes the operation. It then returns any appropriate data to the client.

DO ANY CLIENT/SERVER LIMITATIONS EXIST WITH CORBA?

Depends on the specific vendor and product offering, but there is nothing in the standard that you will find terribly onerous.

Some applications want to make distributed requests, but not wait for the response. Ideally, they want to be notified when the response is available. Threads can be used to allow applications to make more than one request or to continue performing other tasks while waiting for a response, but the thread making a request is blocked until the response is available. CORBA communication is basically a synchronous request/response. This is true for all static invocations. Dynamic invocations do support a deferred request response. This means that an application can issue a request and poll for the response. CORBA communication can be used to notify applications when responses associated with earlier requests are available. This can lead to a more complex application architecture.

I NEED A CORBA ORB? WHERE CAN I GET ONE?

Before you can use CORBA to client/server communication you must either implement your own request broker that supports portions of the CORBA specification including IIOP (not suggested) or you can obtain an object request broker that implements the CORBA specification. Many companies sell object request brokers that implement all or some of the CORBA specification, including various parts of the CORBA 2.x and 3.x specification, CORBA services, and other third-party integrations. Links to their company web sites are included (alphabetically) below:

• ATT omniORB.
• BEA M3.
• DSTC fnorb.
• Expersoft CORBAplus.
• Franz Orblink.
• IBM ComponentBroker.
• Inprise VisiBroker.
• Iona Orbix.
• MICO.
• Object Oriented Concepts ORBacus.
• Objective Interface ORBacus.
• ObjectSpace Voyager.
• PeerLogic DAIS.
• RogueWave Nouveau.
• Xerox ILU.
• Washington University TAO.

Additional information can be found at: * OMG List of free stuff.

• List of ORB vendors maintained by CETUS Links.
• List of free ORBs.

ARE REMOTE INVOCATIONS BLOCKING OPERATIONS?

The CORBA specification makes no specific statement regarding the blocking behavior of remote invocations. It does require that static invocations be synchronous. This means that an application will not proceed to the next line of code following a remote invocation until the remote invocation returns, either normally or abnormally. A non-blocking, or dispatching remote invocation will allow event processing for the duration of the remote invocation. This means that ORB or non-ORB events can be processed while an application is “waiting” for an invocation to return. ORB events could be object connection requests or object invocation requests. Non-ORB events might be GUI events such as mouse clicks, signal handling, or raw file descriptor activity. The CORBA specifications allows the CORBA vendor to decide on the blocking or dispatching behavior for remote invocations. CORBA products that use blocking transports such as the DCE RPC are un-able to support non-blocking remote invocations.

CAN DEAD LOCKS OCCUR BETWEEN CORBA SERVERS?

Dead-locks can occur between two or more CORBA servers. Dead-locks can only occur under certain conditions. First of all, a cyclic or looping relationship must exist between the servers. For example: one server must make invocations on the second server which is in turn implemented to make an invocation upon the first server. This situation is referred to by some as nested call-backs. While cyclic relationship between servers might seem easy to avoid, it often arises, if CORBA is being used to support the combination of client/server request/response and server/client notification. If a cyclic relationship exists and a remote invocation blocks a process, a dead-lock will occur. Blocking can occur upon remote invocation if multiple threads are not used and the CORBA product does not dispatch events while remote invocations are being performed.

I USE MICROSOFT PRODUCTS; WHY SHOULD I USE CORBA AND NOT DCOM?

DCOM is a Microsoft specific distribution solution. CORBA products are available from over 20 different vendors. CORBA products support Microsoft and non Microsoft operating systems. CORBA is an excellent mechanism to bridge between Microsoft desk tops and UNIX servers.

MUST I CHOOSE BETWEEN DCOM AND CORBA?

No. Distributed applications can be developed using both CORBA and DCOM. For example, a client application might be developed to access a set of OLE automation objects, and OLE automation objects might in turn access CORBA objects running on a non-Microsoft platform such a UNIX. The OMG has defined a COM<->CORBA interworking specification which standardizes this sort of bridging.

IS CORBA MORE MATURE THAN DCOM?

CORBA has existed since 1990. Commercial implementations have been available since 1992. DCOM was made available in beta form in 1996. CORBA has had more time to mature. There are also a large number of different companies developing CORBA ORBs. This level of competition increases the robustness of CORBA solutions on the whole.

WHAT ADVANTAGES DOES DCOM HAVE OVER CORBA?

DCOM is well suited to front-end application development. If entire distributed application runs under Microsoft platforms, DCOM might be a good choice. DCOM can also be used with CORBA.

WHAT IS THE BASIC FUNCTIONALITY PROVIDED BY CORBA?

At the most basic level, CORBA is a standard for distributed objects. CORBA allows an application to request an operation to be performed by a distributed object and for the results of the operation to be returned back to the application making the request. The application communicates with the distributed object that is actually performing the operation. This is basic client/server functionality, where a client issues a request to a server and the server responds back to the client. Data can pass from the client to the server and is associated with a particular operation on a particular object. Data is then returned back to the client in the form of a response.

WHAT ADVANTAGES DOES CORBA PROVIDE?

1. CORBA supports many existing languages. CORBA also supports mixing these languages within a single distributed application.
2. CORBA supports both distribution and Object Orientation.
3. CORBA is an industry standard. This creates competition among vendors and ensures that quality implementations exist. The use of the CORBA standard also provides the developer with a certain degree of portability between implementations. Note: application source is not 100% portable between different CORBA products.
4. CORBA provides a high degree of interoperability. This insures that distributed objects built on top of different CORBA products can communicate. Large companies do not need to mandate a single CORBA product for all development.
5. Over 600 companies back CORBA, including hardware companies, software companies, and cable companies, phone companies, banks, etc.

WHAT OTHER TYPES OF DISTRIBUTED SYSTEMS DOES CORBA COMPETE WITH?

• DCE
• DCOM
• EJB
• RPC (remote procedure calls)
• Shared memory based interaction
• Named Pipe communication
• Socket level programming
• Message Queuing
• Other IPC (inter-process communication) mechanisms
• Database tables, triggers and polling

IS CORBA {BETTER,WORSE} THAN {DCOM,COM+,JAVA RMI,DCE,ETC}?

This is not a wise question, and is an invitation to a flame war. Please don’t ask this question on the newsgroup since it will produce a lot more heat than light. Plus it’s nonsensical since the answer of whether you should use CORBA or Java RMI or … will depend mostly on peculiarities business and/or technical constraints of your particular team, organization, project, etc.

In any event, please don’t ask this sort of question on comp.object.corba. It’s an invitation to a flame war, since no answer can ever, ever contain enough if’s and’s and but’s to be precisely correct for all situations. For example, to properly answer the question you’d have to factor in many business considerations such as the following:

• what skill sets does your team already have?
• what is your management willing to pay for up-front costs?
• what is your management willing to pay for ongoing maintenance?
• how likely is cross-platform networking in the future? near-term? long-term?
• what happens if your company goes global?
• what happens if your company wants to be acquired by someone else?
• what if your company wants to acquire someone else?
• etc., etc., etc.

Here’s the truth: Business issues normally dominate technical issues.

In other words, there’s no way to answer the question without knowing the business considerations of the organization that is deciding to use these technologies. There’s no universal notion of better and worse in these things. The vast majority of these decisions are dominated by business considerations, not by technical considerations.

The issues that really end up mattering are things like availability and maturity of a development environment for the development machine, availability of runtime environment(s) for the deployment machine(s), licensing/legal issues of the runtime and/or development environments, availability of trained developers, availability of consulting services, corporate culture/politics, what your company’s customers are using, what your company’s vendors are using, any CEO-level aliances your company has, who is sitting on the Board, etc. These business considerations generally play a much greater role than milliseconds per remote invocation, space overhead per object, etc.

People who argue in favor of one technology over another in a purely technical manner (i.e., who ignore the dominant business issues) damage their own careers. Their management often regards them as techie weenies, and as a result doesn’t listen to them. So do yourself and your company a favor: don’t be a technology bigot. Use the right tool for the job. Recognize that no tool is perfect, and instead figure out what is practical and what your people can be expected to succeed with.

Please note: the issue is not whether life ought to be this way. The issue is merely to recognize and accept that it is this way.

WHAT IS A DISTRIBUTED OBJECT?

A distributed object is an object that can be accessed remotely. This means that a distributed object can be used like a regular object, but from anywhere on the network. An object is typically considered to encapsulate data and behavior. The location of the distributed object is not critical to the user of the object. A distributed object might provide its user with a set of related capabilities. The application that provides a set of capabilities is often referred to as a service. A Business Object might be a local object or a distributed object. The term business object refers to an object that performs a set of tasks associated with a particular business process.

ARE ALL DISTRIBUTED OBJECTS CORBA OBJECTS?

No.

A CORBA object is an object that obeys certain rules and which can be accessed via a particular protocol. A CORBA object is frequently also a distributed object, but it doesn’t have to be.

A distributed object is not necessarily a CORBA object. A distributed object might be a C++ object that can be accessed via a socket, RPC, or telephony. In order for a distributed object to be a CORBA object, it must be declared in IDL. The object can be implemented in a variety of programming languages.

WHY SHOULD I DEVELOP APPLICATIONS WITH DISTRIBUTED OBJECTS?

For lots of reasons:

1. Distributed objects might be used to share information across applications or users.
2. Distributed objects might be used to synchronize activity across several machines.
3. Distributed objects might be used to increase performance associated with a particular task.
4. Distributed objects might be used to connect applications running on PCs with information managed by UNIX processes or mainframes databases.
5. Distributed objects might be used to allow people in different cities to contributed to a particular business process.
6. Distributed objects can allow business processes to be modified or re- implemented without altering applications that use the distributed objects.
7. Distributed objects are a way to distribute computing horsepower across a network of computers, which makes it easier to accommodate unpredictable growth. Centralized approaches frequently fail in such environments.

HOW ARE DISTRIBUTED OBJECTS ACTUALLY IMPLEMENTED?

Typically a company will start by modeling their business processes. Next, the company will determine which business processes should be implemented as local objects and which should be implemented as distributed objects. Usually, the company will leverage a tool-kit that simplifies the distribution of those objects. There are many issues associated with simplifying distribution of objects. The tool-kit might also enhance the distribution with a robust set of communication features. A company might select a particular CORBA implementation, and build their distributed objects on top of the third party package. The CORBA vendor simplifies distribution by implementing all low-level network development. An IDL compiler will process interface definition files into client and server side base classes. These base classes use low level network APIs (such as TCP/IP) to communicate. The vendor will most likely provide daemon processes that facilitate communication, the spawning of processes, the spawning of objects, and the storage of IDL used by a running system. A number of other utilities might also be provided. These could include debuggers, interface browsers or communication monitors.

SHOULD ALL MY OBJECTS BE DISTRIBUTED?

Nope.

Not every business object should be distributed. Distribution implies network overhead and management overhead. Distribution of all business objects can lead to severe performance problems. Distribution can provide many benefits, but should only be used where specific goals are achieved. You must first ask why you need to do distributed objects.