Distributed Component Object Model (DCOM) By Deepak Goel & Mukesh Punhani

Component Software Problem Interoperability Versioning Language Independence Transparency

Why Distributed Applications ? Inherently Distributed Flexibility Scalability

COM Architecture COM Components in the same process COM components in different processes

DCOM : COM components on different machines DCOM Architecture DCOM : COM components on different machines

Components Reusability Using Existing Components to Reduce Development Cost Future Reusability of Components being Developed

Language Neutrality Virtually all languages such as Java, Visual C++, Visual Basic, Delphi, PowerBuilder, COBOL interact well with DCOM Enables Rapid Prototyping

Location Independence Components that interact more should be closer to each other Some components can only be run on specific machines Small Components : Easy to Deploy - Increased Network Traffic Large Components : Difficult to Deploy - Reduced Network Traffic

Scalability Parallel Deployment

Isolating Critical Components Scalability Isolating Critical Components

Scalability Pipelining

Security Provides Security at Component Level and Method Level Uses Access Control Lists (ACL) similar to Windows NT File System

Per Interface Security using Registry Keys

Load Balancing Static Load Balancing Dynamic Load Balancing

Platforms UNIX/Mainframe Apple Macintosh Windows Java

Comparison with CORBA and RMI DCOM fits best with Microsoft Platform i.e. Windows 98 and Windows NT while CORBA is quite general. RMI works only with Java but is quite suitable when application wants to exploit features of Java

Performance Parameter Size 4 Bytes 50 Bytes In-Process 0.00031 0.00031 Cross Process 0.42 0.49 Remote Call 2.7 3.27