web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
Getting information about an enterprise bean UserTransaction.rollback() to rollback and end the transaction). In between, the client does its queries and updates. This code sample shows the code that a client would implement to manage its own transactions. The parts that pertain specifically to client-managed transactions are highlighted in bold. ... import javax.naming.InitialContext; import javax.transaction.UserTransaction; ... public class clientTransaction { public static void main (String[] argv) { UserTransaction ut = null; InitialContext initContext = new InitialContext(); ... ut = (UserTransaction)initContext.lookup("java:comp/UserTransaction"); // start a transaction ut.begin(); // do some transaction work ... // commit or rollback the transaction ut.commit(); // or ut.rollback(); ... ] ] Getting information about an enterprise bean Information about an enterprise bean is referred to as metadata. A client can obtain metadata about a bean using the enterprise bean's home interface getMetaData() method. The getMetaData() method is most often used by development environments and tool builders that need to discover information about an enterprise bean, such as for linking together beans that have already been installed. Scripting clients might also want to obtain metadata on the bean. Once the client retrieves the home interface reference, it can call the getEJBMetaData() method on the home interface. Then, the client can call the EJBMetaData interface methods to extract such information as: ■ ■ ■ ■ ■ ■ The bean's EJBHome home interface, using EJBMetaData.getEJBHome(). The bean's home interface class object, including its interfaces, classes, fields, and methods, using EJBMetaData.getHomeInterfaceClass(). The bean's remote interface class object, including all class information, using EJBMetaData.getRemoteInterfaceClass(). The bean's primary key class object, using EJBMetaData.getPrimaryKeyClass(). Whether the bean is a session bean or an entity bean, using EJBMetaData.isSession(). The method returns true if this is a session bean. Whether a session bean is stateless or stateful, using EJBMetaData.isStatelessSession(). The method returns true if the session bean is stateless. Chapter 11: Writing enterprise bean clients 91
Support for JNDI Support for JNDI The EJB specification defines the JNDI API for locating home interfaces. JNDI is implemented on top of other services, including CORBA's Naming Service, LDAP/ X.500, flat files, and proprietary directory services. The diagram below illustrates the different implementation choices. Typically, the EJB server provider selects a particular implementation of JNDI. Figure 11.1 JNDI implementation EJB to CORBA mapping The technology implemented beneath JNDI is of no concern to the client. The client needs to use only the JNDI API. There are a number of aspects to the relationship between CORBA and Enterprise JavaBeans. Three important ones are the implementation of an EJB container/server with an ORB, the integration of legacy systems into an EJB middle tier, and the access of enterprise beans from non-Java components, specifically clients. The EJB specification is currently only concerned with the third aspect. CORBA is a very suitable and natural platform on which to implement an EJB infrastructure. CORBA addresses all of the concerns of the EJB specification with the CORBA Core specification or the CORBA Services: ■ ■ Support for distribution. CORBA Core and CORBA Naming Service Support for transactions. CORBA Object Transaction Service ■ Support for security. CORBA Security Specification, including IIOP-over-SSL Additionally, CORBA allows the integration of non-Java components into an application. These components can be legacy systems and applications, plus different kinds of clients. Back-end systems can be easily integrated using OTS and any programming language for which an IDL mapping exists. This requires an EJB container to provide OTS and IIOP APIs. The EJB specification is concerned with the accessibility of enterprise beans from non- Java clients and provides an EJB to CORBA mapping. The goals of the EJB/CORBA mapping are: ■ ■ ■ Supporting interoperability between clients written in any CORBA-supported programming language and enterprise beans running on a CORBA-based EJB server. Enabling client programs to mix and match calls to CORBA objects and enterprise beans within the same transaction. Supporting distributed transactions involving multiple enterprise beans running on CORBA-based EJB servers provided by different vendors. 92 BES Developer’s Guide
- Page 51 and 52: 40 BES Developer’s Guide
- Page 53 and 54: Apache web server to Borland web co
- Page 55 and 56: Apache web server to Borland web co
- Page 57 and 58: Apache web server to Borland web co
- Page 59 and 60: Large data transfer Downloading lar
- Page 61 and 62: Large data transfer Uploading large
- Page 63 and 64: IIS web server to Borland web conta
- Page 65 and 66: IIS web server to Borland web conta
- Page 67 and 68: IIS web server to Borland web conta
- Page 69 and 70: Session management with JSS If an i
- Page 71 and 72: Managing and configuring the JSS Co
- Page 73 and 74: The Borland IIOP connector BES supp
- Page 75 and 76: Setting up your web container with
- Page 77 and 78: 66 BES Developer’s Guide
- Page 79 and 80: Web-enabling your CORBA server Impo
- Page 81 and 82: Configuring your Apache web server
- Page 83 and 84: Configuring your Apache web server
- Page 85 and 86: Web Services and Partitions ■ ■
- Page 87 and 88: Web Service providers Java:RPC prov
- Page 89 and 90: How Borland Web Services work
- Page 91 and 92: Packaging Web Service Application A
- Page 93 and 94: Tools Overview Java2WSDL tool Note
- Page 95 and 96: 84 BES Developer’s Guide
- Page 97 and 98: Client view of an enterprise bean L
- Page 99 and 100: Client view of an enterprise bean E
- Page 101: Managing transactions Managing tran
- Page 105 and 106: EJB to CORBA mapping A CORBA progra
- Page 107 and 108: 96 BES Developer’s Guide
- Page 109 and 110: Application Client architecture Pac
- Page 111 and 112: Document Type Definitions (DTDs) my
- Page 113 and 114: Support of references and links The
- Page 115 and 116: Use of Manifest files Use of Manife
- Page 117 and 118: 106 BES Developer’s Guide
- Page 119 and 120: Sessions in secondary storage If yo
- Page 121 and 122: 110 BES Developer’s Guide
- Page 123 and 124: Container-managed persistence and R
- Page 125 and 126: Implementing an entity bean Generat
- Page 127 and 128: Container-Managed Persistence in Bo
- Page 129 and 130: Container-Managed Persistence in Bo
- Page 131 and 132: Setting Properties Setting Properti
- Page 133 and 134: Setting Properties into a BLOB. The
- Page 135 and 136: Setting Properties Automatic table
- Page 137 and 138: 126 BES Developer’s Guide
- Page 139 and 140: Container-managed persistence and R
- Page 141 and 142: Container-Managed Persistence in Bo
- Page 143 and 144: Container-Managed Persistence in Bo
- Page 145 and 146: Container-Managed Persistence in Bo
- Page 147 and 148: Container-Managed Persistence in Bo
- Page 149 and 150: Container-Managed Persistence in Bo
- Page 151 and 152: Container-Managed Persistence in Bo
Support for JNDI<br />
Support for JNDI<br />
The EJB specification defines the JNDI API for locating home interfaces. JNDI is<br />
implemented on top of other services, including CORBA's Naming Service, LDAP/<br />
X.500, flat files, and proprietary directory services. The diagram below illustrates the<br />
different implementation choices. Typically, the EJB <strong>server</strong> provider selects a particular<br />
implementation of JNDI.<br />
Figure 11.1<br />
JNDI implementation<br />
EJB to CORBA mapping<br />
The technology implemented beneath JNDI is of no concern to the client. The client<br />
needs to use only the JNDI API.<br />
There are a number of aspects to the relationship between CORBA and Enterprise<br />
JavaBeans. Three important ones are the implementation of an EJB container/<strong>server</strong><br />
with an ORB, the integration of legacy systems into an EJB middle tier, and the access<br />
of enterprise beans from non-Java components, specifically clients. The EJB<br />
specification is currently only concerned with the third aspect.<br />
CORBA is a very suitable and natural platform on which to implement an EJB<br />
infrastructure. CORBA addresses all of the concerns of the EJB specification with the<br />
CORBA Core specification or the CORBA Services:<br />
■<br />
■<br />
Support for distribution. CORBA Core and CORBA Naming Service<br />
Support for transactions. CORBA Object Transaction Service<br />
■<br />
Support for security. CORBA Security Specification, including IIOP-over-SSL<br />
Additionally, CORBA allows the integration of non-Java components into an<br />
application. These components can be legacy systems and applications, plus different<br />
kinds of clients. Back-end systems can be easily integrated using OTS and any<br />
programming language for which an IDL mapping exists. This requires an EJB<br />
container to provide OTS and IIOP APIs.<br />
The EJB specification is concerned with the accessibility of enterprise beans from non-<br />
Java clients and provides an EJB to CORBA mapping. The goals of the EJB/CORBA<br />
mapping are:<br />
■<br />
■<br />
■<br />
Supporting interoperability between clients written in any CORBA-supported<br />
programming language and enterprise beans running on a CORBA-based EJB<br />
<strong>server</strong>.<br />
Enabling client programs to mix and match calls to CORBA objects and enterprise<br />
beans within the same transaction.<br />
Supporting distributed transactions involving multiple enterprise beans running on<br />
CORBA-based EJB <strong>server</strong>s provided by different vendors.<br />
92 BES Developer’s Guide
Change language