The Interface Definition Code Comparison
The Interface
Whenever a client needs some service from a remote distributed object, it invokes a method implemented by the remote object. The service that the remote distributed object (Server) provides is encapsulated as an object and the remote object's interface is described in an Interface Definition Language (IDL). The interfaces specified in the IDL file serve as a contract between a remote object server and its clients. Clients can thus interact with these remote object servers by invoking methods defined in the IDL.
MTS - The IDL file shows that our MTS server implements a dual interface. COM supports both static and dynamic invocation of objects. For the static invocation to work, The Microsoft IDL (MIDL) compiler creates the proxy and stub code when run on the IDL file. These are registered in the systems registry to allow greater flexibility of their use. This is the vtable method of invoking objects. For dynamic invocation to work, COM objects implement an interface called IDispatch. As with CORBA or Java/RMI, to allow for dynamic invocation, there has to be some way to describe the object methods and their parameters. Type libraries are files that describe the object, and COM provides interfaces, obtained through the IDispatch interface, to query an Object's type library. In COM, an object whose methods are dynamically invoked must be written to support IDispatch. The MTS IDL file also associates the IChecking interface with an object class Checking as shown in the coclass block. Also notice that in MTS, each interface is assigned a Universally Unique IDentifier (UUID) called the Interface ID (IID). Similarly, each object class is assigned a unique UUID called a CLasS ID (CLSID). COM gives up on multiple inheritance to provide a binary standard for object implementations. Instead of supporting multiple inheritance, COM uses the notion of an object having multiple interfaces to achieve the same purpose. This also allows for some flexible forms of programming.
The Checking Account Server component has methods for managing a typical Bank Checking Account. Consequently, it has methods to create an account, and credit & debit money from the Account. Consequently, we define different methods like createAccount(), credit(), debit(), getBalance() and getCustomerName().
EJB - Notice that unlike MTS, EJB uses a .java file to define it's remote interface. This interface will ensure type consistency between the EJB client and the EJB Server Object. Every remotable server object in EJB has to extend the javax.ejb.EJBObject class. Similarly, any method that can be remotely invoked in EJB may throw a java.rmi.RemoteException. java.rmi.RemoteException is the superclass of many more RMI specific exception classes. We define an interface called Checking which extends the javax.ejb.EJBObject class. Also notice that all the remote methods like createAccount(), credit(), debit(), getBalance() and getCustomerName() throw a java.rmi.RemoteException.
MTS - IDL Definition |
EJB - Home and Remote Interfaces | |
[ uuid (6B6EBD40-01C0-11d3-97EE-006097A7D34F), version (1.0) ] library Bank { importlib ("stdole32.tlb"); /*
/* |
package Bank; import javax.ejb.*;
public interface
CheckingHome extends EJBHome { |
|
package Bank; import javax.ejb.*; public interface
Checking extends EJBObject { |
||
Bank.idl |
CheckingHome.java & Checking.java |
click here to go
to My Advanced Java / J2EE Tutorial HomePage... |
This site was developed and is maintained by Gopalan Suresh Raj This page has been visited times since May 04,1999. |
Last Updated : May 04,'99 |
Copyright (c) 1997-2000, Gopalan Suresh Raj - All rights reserved. Terms of use. |
All products and companies mentioned at this site are trademarks of their respective owners. |