A Model for Enterprise Computing
Given that an n-tier, component-based, Web-friendly environment is needed, what about the detail—what specific functionality is needed to support such applications? The Object Management Group (OMG online at http://www.omg.org) has been working with key industry players 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
One key requirement is that 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 signaling their redundancy.
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).
Naming
Distributed applications are 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. Therefore, a directory service is needed, 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 information and services within an enterprise. Further information on Active Directory can be found online at http://www.microsoft.com/windows2000/technologies/directory/default.asp.
Transactions
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, invalidating 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 manager 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 typically provide the following:
Authorization— Are you permitted to do the things you are requesting to do?
Confidentiality— Can only you, or other authorized staff access your data?
Integrity— Is the data you see actually the data you stored, and are any changes you make retained (not lost due to system crashes)?
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's container.