| Standards based Implementation | The JBoss implementation is based on standards such as Java, J2ee, and JCA. | Y |
| 100% Pure Java | Deploy on any platform with a JVM. | Y |
| Complete implementation of JCA 1.0 | For details visit the Connector
page. | Y |
| JCA |
| Full support for JCA 1.0 | JBoss provides full support for the JCA 1 specifications within its revolutionary JMX-based management system. Resource adapters and ConnectionFactories may be deployed, undeployed, and reconfigured on the fly while the server is running. Configuration is provided via an easy-to-use XML-based MBean configuration system
| Y |
| Resource Adapter. | A Resource Adapter is a standard interface to an EIS, providing the ability for the application server to manage connection pooling and transaction management for the EIS while allowing EIS specific operations to be handled by client programs. The RA maps its standard interfaces to the interfaces of the underlying EIS.
| Y |
| Service Provider Interface (SPI) | The SPI is the standard way to integrate the Connection, Transaction, and Security management facilities of an AppServer with a Transaction Manager. | Y |
| Common Client Interface (CCI) | The CCI is a standard client API presenting a generic model of EIS interaction, enabling a consistent format for client interaction with an EIS while preserving the application server managed transaction, pooling, and security aspects of the SPI. | Y |
| Use of CCI in CMP | Use arbitrary CCI connections in CMP so that entity beans may be mapped to arbitrary EIS systems declaratively rather than requiring the use of relational databases to use CMP. | Under active development |
| Use of CCI in the JMS Resource Adapter for JMS | JBoss features the first JCA adapter to provide an interface to a JMS implementation. We may modify this to use the CCI API in the future. | To do |
| Use of CCI in a Rules Engine Adapter | In combination with the completely modular and extensible EJB container architecture featured by JBoss, a prototype rules engine adapter was developed, allowing completely transparent declarative interaction with a RETE-based rules engine. The rules engine adapter implements the JCA SPI and CCI APIs to provide for possible pluggable rules engines. | Under development |
| Managed Application Clients (3-Tier) | Access to EISs from Managed Application Clients is the "normal" scenario. 3-Tier Thin clients use the CCI to interact with the EIS. The J2EE Server uses the SPI to manage Configuration, Connections, Transactions, and Security. | Y |
| Non-Managed Application Clients (2-Tier) | Access to EISs from Non-Managed Application Clients
2-Tier Fat clients can directly use the Resource Adapter. The Client uses the CCI and SPI interfaces and takes responsibility for managing Transactions and Security. Connections are still managed by the Resource Adapter.
The non-managed application client scenario is not particularly relevant to an application server, which after all is an application manager. However, it may sometimes be useful to supply connections that are not under transaction manager control, for instance for "read only" access from a servlet. Although this may be a questionable design choice, it is possible to set up a ConnectionFactory with pooling and, security management, but no transaction management, provided that the Connection supports the getLocalTransaction() method. | Y |
| Connection Management |
| Consistent model for Connections. | Provides a consistent application development model for connection acquisition for Managed and Non-Managed application clients. | Y |
| Choice of ConnectionManagers. | The ConnectionManager is the primary application server-side interface between the application server (as opposed to the managed client) and a (external) resource adapter. JBoss ships with three ConnectionManagers, all providing connection pool management, and providing different levels of transaction support (XA transaction, LocalTransaction, and No transaction). As with most JBoss components, these are completely pluggable, allowing you to add your own ConnectionManager should you have more specific needs.
| Y |
| ConnectionFactories. | Of course, the whole point of the JCA architecture is to provide connections from connection factories so your application can do some useful work. Enable theA Resource Adapter to provides a Connection Factory and Connection iInterfaces: these may be based on the CCI specification, based on JDBC, or based on the CCI specific to the EIS. JBoss supports dynamic deployment and undeployment of connection factories through a ConnectionFactoryLoader MBean. The configuration for a ConnectionFactoryLoader MBean contains all the information necessary to set up a ManagedConnectionFactory, configured to connect to an EIS instance, a ConnectionManager to manage pooling, transactions, and security, and the JNDI binding of the ConnectionFactory itself. The configuration of a ManagedConnectionFactory, ConnectionManager, or ConnectionFactory can be changed at any time through the html JMX interface or programmatically through the MBean server.
| Y |
| Connection Pooling. | Typically physical connections to an EIS are time consuming to set up and tear down and tie up significant resources. In an application server environment, it is essential to share connections between clients, and maintain a pool of connections available for use. JBoss comes with several ConnectionManagers that implement different policies on the circumstances under which a connection may be shared or reused. If none of these are suitable for a particular resource adapter, a custom ConnectionManager may be written and plugged seamlessly into the JBoss framework.
| Y |
| Transaction Management |
| Transactions (JTA) | Full support for JTA. JBoss comes configured with a JTA based transaction manager that implements all needed functionality for a single server, including 2PC and 1PC optimization. All transaction management is done within the JTA framework.
| Y |
| Integration with external DTM (Tyrex). | JBoss includes a configuration and integration for the Tyrex DTM for use when transactions need to span more than one jboss instance. | Y |
| XA-Transactions | An XA-Transaction is managed outside the EIS by the help of an external Transaction Manager. For resource adapters supporting XA transactions, all transaction management will beis done from the JBoss transaction manager using the XAResource interface. | Y |
| Local-Transactions | A Local-Transaction is managed internally by the EIS without the use of any external Transaction Manager. For resource adapters not supporting XA transactions, the transaction manager uses the LocalTransaction interface, intended for use in transactions encompassing only one resource manager. | Y |
| 2PC using XA-Transactions | Two Phase Commit is required if multiple EISs need to participate in a transaction. The J2EE Server uses a Transaction Manager to coordinate the steps involved in a two phase commit of the Transaction using the XAResource interface. | Y |
| 1PC using XA-Transactions | One Phase Commit is sufficient for transactions within a single EIS. The Transaction Manager uses 1PC optimizations to manage the transactions for this single EIS, using the XAResource interface.
| Y |
| 1PC using Local-Transactions | One Phase Commit is sufficient for transactions within a single EIS. If a resource adapter for an EIS supports only local transactions, the jboss transaction manager can manage transactions in the EIS through the use of the local-transaction ConnectionManager. | Y |
| Compatibility Features with other Subsystems |
| JCA Wrappers for JDBC Drivers. | JBoss provides connection to RDBMSs that have not yet implemented JCA-JDBC drivers through JCA wrappers for JDBC drivers. Currently there are wrappers for JDBC Type-1 Drivers and JDBC Type-2 extension XADataSource based drivers. This architecture makes it simple to work around the peculiarities of a driver for a particular database by writing a specific JCA wrapper for that driver, without modifying core JBoss code. | Y |
| Messaging (JMS) | TBD based on JCA 2.0 (JSR 112).
For details on JCA 2.0, see:
http://www.jcp.org/jsr/detail/112.jsp
| To do |
| Resource Adapter for JMS. | JCA resource adapter for a JMS system, allowing JMS activity to participate in declarative container managed transactions. We believe this is the first such product available anywhere. | Y |
| MetaData | TBD based on JCA 2.0 (JSR 112).
For details on JCA 2.0, see:
http://www.jcp.org/jsr/detail/112.jsp | To do |
| WebServices, SOAP, XML | In a project named Jboss.net, development is proceeding rapidly on a SOAP/ webservices implementation based on Apache Axis. | Y |
| Security |
| Security | JBossCX uses JBossSX for standards based security.
JBossSX provides a Pluggable Security Framework based on JAAS. | Y |
| JaasSecurityManager | JBossSX uses the JaasSecurityManager by default. The LoginModules implement the Authentication and RoleMapping behavior for the security Domain.
For server-side login: Included are ProxyLoginModule, LdapLoginModule, DatabaseServerLoginModule, and SRPLoginModule.
For client-side login: Included are ClientLoginModule, SRPLoginModule
| Y |
| Credentials. | Security information that can be used to authenticate a Principal. | Y |
| Principal. | An entity that can be authenticated by an authentication mechanism.
"Caller Principal" is the Application Security Domain.
"Resource Principal" is the EIS Security Domain.
When a Caller Principal requests an EIS connection, the Resource Principal has 4 choices for propagating the credentials: Configured Identity; Principal Mapping; Caller Impersonation; Credential Mapping. | Y |
| Resource Principal using Configured Identity. | This Resource Principal has its own configured identity and security attributes independent of the Caller Principal. This configured identity can be specified either during deployment or dynamically by the application when creating the connection. | Y |
| Resource Principal using Principal Mapping. | The Resource Principal is determined by a mapping in the J2EE server between the Caller Principal and the Resource Principal. The RP does not inherit any attributes from the CP. | Y |
| Resource Principal using Caller Impersonation. | The Resource Principal acts on behalf of a Caller Principal - i.e. The Callers credentials are delegated to the EIS. This requires an end-to-end security domain (e.g. Kerberos V5.). | Y |
| Container Managed Sign-On. | The Application provides no security information when requesting a Connection. The J2EE Server is configured to manage EIS sign-on. The J2EE Server provides the required security information for the Resource Principal through its configured security policies and mechanisms. The J2EE Server itself requests the authentication of the Resource Principal to the EIS, or it passes authentication responsibility to the Resource Adapter.JBoss currently provides an implementation of a simple policy and additional methods can easily be implemented. | Y |
| Component Managed Sign-On. | The Application provides explicit security information when requesting a Connection. The J2EE Server does not see the security information, and so must rely on the Application and Resource Adapter to manage the EIS sign-on. | Y |
| Authentication based on UserName/Password. | JBossSX can be used to provide UserName/Password authentication. | Y |
| Authentication based on Digital Certificates. | JBossSX can be used to provide client-to-server and server-to-server authentication using Digital Certificates. | Y |
| Re-Authentication of Physical Connection. | If a resource adapter supports reauthentication, the jboss ConnectionManagers can be configured to use it to change the Principal for a connection with each Connection request. A Resource Adapter has to Re-Authenticate when the J2EE Server attempts to allocate a connection with a security context different from the context previously associated with the physical connection. This assumes that the underlying EIS supports re-authentication of existing physical connections. | Y |
| Logging |
| Logging | Comprehensive logging capabilities using Log4J.
JBossCX is fully instrumented for logging with Log4J so you can detect and resolve errors faster. Each component can be configured for different levels of logging. | Y |
| Persist logs to various data stores. | Log4J can persist to File or any popular RDBMS. | Y |
| Deployment |
| Dynamic Resource Adapter Deployment. | JBoss offers on-the-fly resource adapter deployment and undeployment. You can deploy and undeploy a resource adapter archive by adding it or removing it from a watched directory, by executing deploy/undeploy actions from the JMX console, or by programmatic interaction (inter or intra-vm) with the JMX server. Using the jboss dynamic dependency mechanisms, undeploying a resource adapter currently being used by one or more ConnectionFactories will suspend the ConnectionFactories until the resource adapter is redeployed: when it is, the dependent ConnectionFactories will be automatically restarted. | Y |
| Dynamic ConnectionFactory Deployment. | In keeping with the JBoss philosophy of dynamic deployment and configuration, ConnectionFactories may be, at any time, loaded and unloaded with the associated ManagedConnectionFactory, security and ConnectionManager configurations. The configuration of these components may be changed at any time, while the server is running. | Y |
| RAR deployment as part of an EAR | JBoss supports deployment of resource adapters contained in an EAR. | Available Real Soon Now! |
| RAR deployment using accessible classloaders. | By using the jboss dynamically extensible classloader for deployment and redeployment of resource adapters while the server is running, JBoss allows applications to access the actual classes implementing the CCI interfaces, thus avoiding the reflection-based approaches necessary with certain other application servers. | Y |
| Appropriate binding of ConnectionFactories in JNDI | In JBoss, ConnectionFactories are bound in JNDI using the referencable interface, so the exact instance bound is returned on lookup. This is in contrast to certain commercial implementations that mistakenly use the serialization mechanism to bind ConnectionFactories, resulting in the creation of duplicate components on every lookup. | Y |
| Management and Administration |
| Management, Administration, Configuration Fully instrumented for management using JMX MBeans. | Consistent with the JMX based management structure of JBoss, all JBoss JCA related components are implemented as MBeans, allowing consistent and fine-grained control. Behavior can be set at Startup and can be dynamically/programmatically modified while the application is in production. | Y |
| Remote Administration. | Administrators can create, delete, modify and set properties for all administered objects. | Y |
| Remote Monitoring. | JBoss features the reference implementation of the JSR-77 management framework, providing comprehensive statistics and management capabilities. The JBossCX components fully participate in this framework. | Under active development |
| Documentation |
| Documentation | Comprehensive written documentation with examples.
The JBoss manual contains extensive discussion of all configuration parameters for JCA components. Examples are provided for popular RDBMSs and EISs. | Y |
| Comprehensive FAQ. | | To do |
