A Model for Enterprise Computing
So, an n-tier, component-based, Web-friendly environment is needed, but what about the detail—what specific functionality is needed to support such applications? When considering what is needed for a distributed environment, we can turn to an organization that has been involved in this area for a long time. Since its inauguration in 1989, the OMG has been working with key industry players (such as 3Com Corporation, American Airlines, Canon, Inc., Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems, and Unisys Corporation) to produce a component-based software market by hastening the introduction of standardized object software. Many of the OMG's specifications have become a standard part of the Distributed Object Computing landscape, such as the Common Object Request Broker Architecture (CORBA), the Internet Inter-Orb Protocol (IIOP), and the Unified Modeling Language (UML).
By examining some of the key requirements outlined in the OMG's Enterprise Computing Model, it is possible to explore what is required from a modern distributed computing environment.
Lifecycle
There must be a safe mechanism for creating, copying, moving, and deleting distributed objects. A distributed component environment must provide containers to manage the lifetime of components and assist in their deployment. There are also other lifecycle issues that must be addressed in a distributed environment. For example, distributed garbage collection (getting rid of unused objects) can be handled in different ways according to the operating environment. With Java's Remote Method Invocation (RMI), a distributed leasing mechanism is used. With CORBA, there are lifecycle management services. Microsoft's Distributed COM (DCOM), on the other hand, relies on objects controlling their own lifetimes.
Persistence
In an enterprise application, you need to be able to store data permanently for later retrieval. Object Database Management Systems (ODBMS) and Relational Database Management Systems (RDBMS) commonly support this requirement. A distributed application environment must provide a way of accessing and updating persistent data in a simple yet flexible way. It is also important to support different types of data persistence (different databases, legacy systems, and so on) and different ways of accessing this data (locally or across a network). Any help that can be given to the developer for data persistence is generally very welcome.
Naming
Distributed applications will be formed from components that reside on different machines. The parts of the application that use components on other machines must be able to locate and invoke such components. What is needed is a directory service in which components or services can register themselves. Any part of the application that wants to use such a service can look up the location of the service and retrieve information about how to contact it.
Common directory services and protocols include the following:
CORBA Common Object Services (COS) Naming Service— This allows you to store object references in a namespace. The COS naming service is widely used in Java-based distributed environments as a way of storing information about the location of remote objects. Further information on COS Naming can be found online at http://www.omg.org.
X.500— This defines an information model for storing hierarchical information and an access protocol called the Directory Access Protocol (DAP). Further information about X.500 can be found online at http://java.sun.com/products/jndi/tutorial/ldap/models/x500.html.
Lightweight Directory Access Protocol (LDAP)— This is a lightweight version of the X.500 protocol that runs over TCP/IP. Further information on LDAP can be found online at http://www.openldap.org.
Domain Name System— This is an Internet protocol that allows translation between host names and Internet addresses. DNS is used by all Internet clients, such as Web browsers. More information on DNS can be found at http://www.dns.net/dnsrd/rfc/.
Microsoft Active Directory— The Active Directory service allows organizations to store central information on data and services within an enterprise. Further information on Active Directory can be found online at http://www.microsoft.com/windows2000/technologies/directory/default.asp.
Transaction
In a distributed enterprise application, certain business processes will involve multiple steps. For example, a typical exchange of goods or services for payment will need to take payment details, verify those payment details, allocate the goods to be shipped, arrange the shipping, and take the payment. At any stage, the customer might be interrupted or the server could crash, not completing the entire transaction. If that happens, the enterprise application must be able to retrieve the previous state to continue with the transaction at a later time or to roll back the transaction so that the system is restored to its original state.
Transaction services provide a way of grouping updates to data so that either all of the updates are performed or none of them are performed. A transaction coordinator will be responsible for ensuring this. Transaction information is persisted so that the state of a transaction can survive a system crash. Transactions can be propagated across distributed method calls and even across message-based systems.
Security
A secure enterprise application environment will provide the following:
In addition to this, many enterprise application environments will support both programmatic and declarative security. Programmatic security is enforced within the enterprise application itself, while declarative security is enforced by the enterprise application environment within which the application runs. The enterprise application environment will consult configuration information to decide which security restrictions to enforce for a particular application. Changes to this information would not necessitate recompilation of the application itself.