web server - Borland Technical Publications
web server - Borland Technical Publications web server - Borland Technical Publications
Chapter 27 27Using VisiConnect Chapter Important The Java 2 Enterprise Edition (J2EE) Connector Architecture enables EIS vendors and third-party application developers to develop Resource Adapters that can be deployed to any application server supporting the J2EE 1.3 Platform Specification. The Resource Adapter provides platform-specific integration between the J2EE component and the EIS. When a Resource Adapter is deployed to the Borland Enterprise Server, it enables the development of robust J2EE applications which can access a wide variety of heterogeneous EISs. Resource Adapters encapsulate the Java components, and if necessary, the native components required to interact with the EIS. Before using VisiConnect, Borland recommends that you read the Connectors 1.0 specification. For documentation updates, go to www.borland.com/techpubs/bes. VisiConnect service Resource adapters are hosted by Partitions with the VisiConnect Partition Service enabled. Multiple Resource Adapters can be deployed in the same Partition. VisiConnect is responsible for making the connection factories of its deployed Resource Adapters available to the client through JNDI. Thus, the client can look up the connection factory for a specific Resource Adapter using JNDI. Service overview The VisiConnect Service is a complete implementation of the Connectors 1.0 specification, including all optional functionality. Every Resource Adapter object in the deployed Connector is simultaneously both a Resource Adapter object and a CORBA object. Unlike other Connectors implementations, VisiConnect has no restrictions on partitioning. Any number of Resource Adapters can go into any number of Partitions running on any number of machines. Plus, support for distributed transactions protocol allows Resource Adapters to be partitioned arbitrarily. Partitioning enables you to configure the application during deployment to optimize its overall performance. Chapter 27: Using VisiConnect 257
Connection management Connection management VisiConnect built on top of VisiBroker and RMI-IIOP VisiConnect is built on top of Borland VisiBroker. Communication between clients and Resource Adapters, among Resource Adapters, and between Resource Adapters and other CORBA-based applications is all done using IIOP by way of VisiBroker. VisiBroker is fully compliant with the CORBA 2.3 specification which specifies that RMIover-IIOP must be implemented in terms of objects-by-value. RMI-over-IIOP must be implemented in terms of objects-by-value for true interoperability. As such, VisiConnect is interoperable with any other server supporting RMI-over-IIOP. Security credentials are propagated by VisiBroker. This ensures that a client's credentials are propagated from the client to the server. Transactional context is propagated by VisiBroker. This ensures that when a CORBA client begins a transaction and then accesses the Partition, transactional context is propagated in the call to the server and the server uses this transaction context when making calls to various resources in its environment. Two-phased commit transactions are managed by Borland VisiTransact Transaction Manager. Two-phase commit is supported if the Resource Adapter supports it. If the Resource Adapter in use does not support it, then two-phase commit cannot be done. Important The ra.xml deployment descriptor file contains a config-property element to declare a single configuration setting for a ManagedConnectionFactory instance. The resource adapter provider typically sets these configuration properties. However, if a configuration property is not set, the resource adapter deployer is responsible for providing a value for the property. Borland provides its own deployment descriptor for defining connectors and their connection factory properties: ra-borland.xml. See Borland DTDs for more information on using the ra-borland.xml descriptor. In previous versions of BES, you configured the connection pool using the initialcapacity, capacity-delta, cleanup-enabled, and cleanup-delta properties in raborland.xml. They are replaced in BES 6.5 by the pool properties busy-timeout, idletimeout, and wait-timeout, listed in the table below. You do not have to delete the oldstyle properties from ra-borland.xml, but they will no longer have any effect. 258 BES Developer’s Guide
- Page 217 and 218: Advanced Topics for Defining JDBC D
- Page 219 and 220: Connecting to JDBC Resources from J
- Page 221 and 222: Configuring JMS Connection Factorie
- Page 223 and 224: Defining Connection Pool Properties
- Page 225 and 226: Obtaining JMS Connection Factories
- Page 227 and 228: JMS and Transactions and its accomp
- Page 229 and 230: JMS and Transactions For instance:
- Page 231 and 232: 220 BES Developer’s Guide
- Page 233 and 234: Configuring JMS administered object
- Page 235 and 236: Tibco Creating Clustered JMS Servic
- Page 237 and 238: Sonic serverUrl String localhost:72
- Page 239 and 240: Sonic Creating Clustered JMS Servic
- Page 241 and 242: OpenJMS Even though OpenJMS can be
- Page 243 and 244: OpenJMS Important If you use OpenJM
- Page 245 and 246: OpenJMS openjms.clean_messages_on_s
- Page 247 and 248: OpenJMS Table 24.1 Property Name De
- Page 249 and 250: Other JMS providers The following a
- Page 251 and 252: 240 BES Developer’s Guide
- Page 253 and 254: Creating the Interceptor Class For
- Page 255 and 256: Creating the JAR file Creating the
- Page 257 and 258: Components Components The Connector
- Page 259 and 260: System Contracts Connection Managem
- Page 261 and 262: System Contracts Security Managemen
- Page 263 and 264: Common Client Interface (CCI) Conne
- Page 265 and 266: Packaging and Deployment Figure 26.
- Page 267: Resource Adapters Resource Adapters
- Page 271 and 272: Security management with the Securi
- Page 273 and 274: Security management with the Securi
- Page 275 and 276: Resource Adapter overview Note Reso
- Page 277 and 278: Deployment Descriptors for the Reso
- Page 279 and 280: Developing the Resource Adapter Con
- Page 281 and 282: Deploying the Resource Adapter Pack
- Page 283 and 284: Application development overview 8
- Page 285 and 286: Application development overview //
- Page 287 and 288: Application development overview
- Page 289 and 290: Other Considerations Other Consider
- Page 291 and 292: Other Considerations To illustrate,
- Page 293 and 294: Other Considerations } } { cf = new
- Page 295 and 296: General syntax and usage General sy
- Page 297 and 298: Syntax and usage for iastool Table
- Page 299 and 300: Syntax and usage for java2iiop Exam
- Page 301 and 302: Syntax and usage for appclient Tabl
- Page 303 and 304: Building and running the BES exampl
- Page 305 and 306: Using the iastool command-line tool
- Page 307 and 308: Using the iastool command-line tool
- Page 309 and 310: Using the iastool command-line tool
- Page 311 and 312: Using the iastool command-line tool
- Page 313 and 314: Using the iastool command-line tool
- Page 315 and 316: Using the iastool command-line tool
- Page 317 and 318: Using the iastool command-line tool
Connection management<br />
Connection management<br />
VisiConnect built on top of VisiBroker and RMI-IIOP<br />
VisiConnect is built on top of <strong>Borland</strong> VisiBroker. Communication between clients and<br />
Resource Adapters, among Resource Adapters, and between Resource Adapters and<br />
other CORBA-based applications is all done using IIOP by way of VisiBroker.<br />
VisiBroker is fully compliant with the CORBA 2.3 specification which specifies that RMIover-IIOP<br />
must be implemented in terms of objects-by-value. RMI-over-IIOP must be<br />
implemented in terms of objects-by-value for true interoperability. As such, VisiConnect<br />
is interoperable with any other <strong>server</strong> supporting RMI-over-IIOP.<br />
Security credentials are propagated by VisiBroker. This ensures that a client's<br />
credentials are propagated from the client to the <strong>server</strong>.<br />
Transactional context is propagated by VisiBroker. This ensures that when a CORBA<br />
client begins a transaction and then accesses the Partition, transactional context is<br />
propagated in the call to the <strong>server</strong> and the <strong>server</strong> uses this transaction context when<br />
making calls to various resources in its environment.<br />
Two-phased commit transactions are managed by <strong>Borland</strong> VisiTransact Transaction<br />
Manager. Two-phase commit is supported if the Resource Adapter supports it. If the<br />
Resource Adapter in use does not support it, then two-phase commit cannot be done.<br />
Important<br />
The ra.xml deployment descriptor file contains a config-property element to declare a<br />
single configuration setting for a ManagedConnectionFactory instance. The resource<br />
adapter provider typically sets these configuration properties. However, if a<br />
configuration property is not set, the resource adapter deployer is responsible for<br />
providing a value for the property.<br />
<strong>Borland</strong> provides its own deployment descriptor for defining connectors and their<br />
connection factory properties: ra-borland.xml. See <strong>Borland</strong> DTDs for more information<br />
on using the ra-borland.xml descriptor.<br />
In previous versions of BES, you configured the connection pool using the initialcapacity,<br />
capacity-delta, cleanup-enabled, and cleanup-delta properties in raborland.xml.<br />
They are replaced in BES 6.5 by the pool properties busy-timeout, idletimeout,<br />
and wait-timeout, listed in the table below. You do not have to delete the oldstyle<br />
properties from ra-borland.xml, but they will no longer have any effect.<br />
258 BES Developer’s Guide
Change language