JavaBeat

  • Home
  • Java
    • Java 7
    • Java 8
    • Java EE
    • Servlets
  • Spring Framework
    • Spring Tutorials
    • Spring 4 Tutorials
    • Spring Boot
  • JSF Tutorials
  • Most Popular
    • Binary Search Tree Traversal
    • Spring Batch Tutorial
    • AngularJS + Spring MVC
    • Spring Data JPA Tutorial
    • Packaging and Deploying Node.js
  • About Us
    • Join Us (JBC)
  • Privacy

Java Security Packages using JCA/JCE

May 23, 2008 by Krishna Srinivasan Leave a Comment

In this tutorial, the author explains the cryptography-related concepts and packages in JDK,with code examples.Many of the concepts and technical terms thus learnt will be useful in understanding the Cryptography API in MFCalso.

There are three security-related packages in JDK1.4, as follows:

  1. JCA/JCE(Java Cryptography
    Architecture & JavaCryptography
    Extensions)
  2. JSSE( Java
    Secure-Sockets Extension).
  3. JAAS( Java Authentication &AuhorizationService)

also read:

  • Java EE Tutorials
  • Java EE 7 Tutorials
  • Java EE Interview Questions

Prior to JDK1.4, many of these packages were not available within the JDK and had to be separately installed and used. But, JDK1.4 has incorporated all these within JDK itself).

Understanding the terminology of these important packages requires that we havesome familiarity with the technical terms used inthe field of Network Security. We can begin by saying thatsecure communication ,should ensure the following.

  1. a)Integrity
  2. b)Confidentiality
  3. c)Authentication
  4. d)Non-repudiation

[There is also another requirement (ie) Authorization and it is more to protect resources and programs from users, than with communicating the data. JAAS deals with that].

These are all standard terms used in Security. Whena person, say, Sam,wants to send some information toTom, it must be ensured that the information thus sent, is not tampered with oraltered on the way. This is known as Data Integrity.

Secondly, the information is meant only for Tom and so no one else should be able to understand the message. This is known as Confidentiality. There should be some indication that the message came from Sam andthere should be some proof for that. This is Identification.Authentication,that the message came from Sam is provided byDigitalSignature.There should preferably be a trusted third party to vouchsafe for the identity and signature of Sam. This is achieved by Digital Certificate,which authenticates the signature of Sam. Besides these, sometimesit is equally important thatSam should not be able to say later that he did not send the message to Tom and the message was actually sent by someone else ,in his name. This isensuring Non-repudiation. This purpose also is served byDigital signature. We will now see step-by-step development of these concepts. Except ‘Authorization’, other things can be understood in the context ofeveryday exchange of information.

Confidentiality is achieved byusingCryptography techniques. For the sake of simple illustration, let us assume that Sam wants to send a message to Tom.( By convention, two persons Alice & Bob are chosen for illustration, because the original thesis made use of these names. Let us use Sam and Tom instead).Sam does not want his message to be understood by anybody else except Tom. So, he encrypts it. When Tom receives the encrypted message, he ‘decrypts‘ it, so that he can read the original message. The original message is known as ‘plaintext‘. After Encryption, it becomes ‘ciphertext’. The process of convertingtheciphertextinto the original plaintext is known as Decryption. A ‘key’is used for controllingEncryption and Decryption.

There are two types of key-based encryption algorithms, namely, Symmetric algorithm and Asymmetric Algorithm.

a) SymmetricAlgorithm:This algorithmuses the same key for encryption and decryption.This is also known as ‘Secret key’. In this scheme, when Sam wants to send a message to Tom, he encrypts the message by the mutually agreed secret-key and then sends the ciphertext to Tom. Tom uses the same secret key and decrypts the message and reads it.

Symmetric key system is faster than the Asymmetric system but the problem of agreeing on mutual secret keyand preserving the secrecy of thekey while communicating it over the network, led to the development ofAsymmetric key systems.

Some of the Symmetric key Algorithms are as follows: (Mostof them are implementedin JCA/JCE).

  • DES( Data-Encryption-Standard).. developed in 1970 and recommended by US government. Though it is not fool-proof, it is considered to be sufficiently safe and is in wide use. It has different modes of operation.
    1. Electronic Cook book ( ECB)
    2. Cipher Block Chaining ( CBC)
    3. Output Feedback Mode (OFB)
    4. Cipher Feedback Mode ( CFB)
  • TripleDES( also known as DESede). An improved and very safe method of DES.
  • IDEA (International Data Encryption Algorithm). This is used in PGP ( Pretty-Good-Privacymethod of secure Email).

    An important advantage of Secret-key algorithm is that a hardware-approach is possible. This results in very high speed encryption. The hardware implementation by a VLSI chip can be about 20 times faster than the corresponding software implementation!IDEA has been implemented in hardware.

  • Blowfish…This algorithm was designed by Bruce Schneier. It is not patented and he has placed the implementation in public domain.
  • v) There is also a method known as Password-Based Encryption(PBE). We will have a brief description of this method ,with code example,shortly. Ready-madeimplementations for many of these algorithms are available in SunJCA/JCE and the programmer just chooses the desired algorithm and uses it. No deep knowledge of the mathematical theory of the algorithms or how these algorithms are implemented ,is required .Such topics are highly mathematical and aredealt with inbooks on Cryptography .

b)Asymmetric Algorithms

This algorithm is also known as ‘Public Key’ algorithm. There are two keys in this scheme. One key is known as ‘public key’ and the other key is known as ‘private key’.(It should be noted that ‘secret key’ does not mean ‘private key’.)

The basic theory of Public key Cryptography was developed by two research workers at StanfordUniversityDiffie&Hellman in 1976. TheDH algorithm is known as Key-Agreement method. RSA algorithm is an implementation , named after the initials of the three academics who invented it. ( Rivest,Shamir & Adleman).RSA is the defacto standard.Another Asymmetric algorithm isDSA

( Digital Signature Algorithm). Yet another algorithm is known as ECC(Elliptic-Curve Cryptography). It is reputed to be very efficient and fast.[ However, SunJCA/JCE does not provide ready-made implementation for ECC.]

The public key and private key are known as ‘keypair’.The public key and private key are mathematically related in the sense that if a message is encrypted by using a particular public key, it can be decrypted by the corresponding private key and vice-versa(ie) the data can
also be encrypted by using a private key and can be decrypted by the corresponding public key, and not by any other public key.But
the problem is thatany person who knows Sam’s public keycan decrypt the message.So,RSA system uses public key of the recipient to encrypt the data.( But, the private key cannot be derived from public key.Similarly, the public key cannot be derived from private key).

RSA method is the most widely used scheme. When Sam wants to send a secret message to Tom, he should know the public key of Tom to begin with.( Just as we should know the mail-id of our friend first, if we want to send email to him). Samencrypts the message by using Tom’spublic keyand sends it to Tom.At the receiving end, Tom uses his (Tom’s)private key and decrypts the letter and reads it.The advantage of this scheme is that it ensures that only Tom will be able to read the message, as only his private-key can decrypt the message encrypted with his public key.A person’s private key need never be known to anyone else and there is no sharing the key with another person.Only the public key needs to be informed to others. ( like the difference in sharing our mail-id and sharing our password!).Thus key-administration problem is less.

DigitalSignature&MessageDigest

The Asymmetric system has another use as well. It can be used for creating the Digital Signature, to ensure that the message came from Sam.Though the message itself can be signed without creating a digest, the usual method is to sign the messagedigest,so that Integrity of
data also can be ensured.

A ‘Message Digest’ isa digital fingerprint.It isoften referred to simply as a digest ( summary) or hash. It is an one-way process ( ie) it is impossible to reconstruct the original from the hash.

MD5(MessageDigest-5) andSHA-1( Secure Hash Algorithm) are two examples of such Digesting algorithms.These two are provided in Sun security package.MD5 accepts some input and produces a 128-bit message digest.SHA-1 is more secure and produces a 160-bit
message digest.

When Sam wants to send a secure message, he passes the message through a MessageDigest engine. The result is a hash.

He then encrypts thehashby using Sam’sprivate key.( This encryption is done on the hash and not on the data). Thus we get the Digital Signature.

Finally, Sam encryptsthe original message usingTom’s Public key. After this, Sam sends the package to Tom.

At the receiving end, Tom uses his(Tom’s) private key to decrypt the message.By using Sam’s public key, hedecrypts the digital signature and so gets the originalhash( hash1).Using the same oneway hash algorithm on the text message,Tom creates another hash( hash2).If hash2exactly matches hash1, it means that the data has not been altered in transit. Thus, we get assurance of Confidentiality and DataIntegrity.It also ensures the identity of the sender,because the the hash1 was obtained by using the public key of Sam to decrypt the package.

If the public key of Sam, used by Tom, has the added assurance from a certificate authority that it really belongs to Sam,this is aclear-cut method with no problems except that it is not suitable if the message being encrypted is of large size. Besides satisfying the requirements of Authentication, Confidentiality, Integrity and Non-Repudiation, we should also ensure that the process is fast, in Enterprise level. The method outlined above is slow and so may not be suitable for large messages.Otherwise, it is a satisfactory method.

(We will describe a hybrid method used for large messages, shortly).

Sometimes, it may be enough if there is Authentication and Non-Repudiation,without confidentiality. In such cases, it is enough if Sam sends the message-digest encrypted by Sam’s privatekey ,along with the plaintext.

Digital Certificate

Just now , we saw that Tommade use of Sam’s public key to verify his Digital Signature. How does Tom getto know the public key of Sam?Sam could have published his public key in the internet or could have sent it to Tom, personally. A person’s public key can be freely published and shared and for this reason, anybody can use it , not necessarily Sam. A Digital signature of Sam can be verified only if Sam’s public key is available to Tombut as it is a public key, impersonation is possible. A trusted third-party is required to certify that the said key is really Sam’s public key.This is known as Digital Certificate and the authorities who issue such certifictes are Certifying Authority.

Public Key Infrastructure( PKI)

When Sam wants his public key to be certified by a CA, he generates a keypair and sends the public key to an appropriate CAwith some proof of his identification. The CA checks the identification and then after satisfying that the key has not been modified in transit, issues a certificate relating the public key of Sam with his identity,by signing the public key of Sam with the private key of the CA. The standard formatof issuing the certificate is known as X509.

Who is to attest the CA themselves? The CAare self-attested.

The PKI standard has been developed by RSA Security Systems in collaboration with Industry leaders like SUN, IBM and Microsoft and is the industry standard.

Certficate-Revocation

Acertificate becomes invalid after the expiry of validation period. Sometimes, the private key associated with a public key gets compromised ( ie) exposed, and in that case also, the cerificate should be withdrawn( revoked).The owner of the privatekey also may like to change it.The CA publishes a list of such defunct certificates and Tom should verify that Sam’scertificate is still valid, before important transactions.

Message-Authentication-Code ( MAC)

Digital Signature makes use of Sam’s private key to sign the hash. An alternative to Digital Signature is to use a secret key to encrypt the hash. By its very definition, secret key is common to both Sam & Tom. So Tom can use the secret key at his end and get back the hash.
The code thus generated by mixing the hash and the secret key is known as MAC. Digital Signature is better than MAC because it does not need any ‘secret’ key. In the context of E-Commerce, where there are thousands of parties , secret key administration is always very difficult.

The scheme outlined above is suitable for most purposes. However, for very large amounts of data, encryption and decryption of databy public-key systems becomestime consuming and requires large resources.

In such cases, it is preferred to use Symmetric Encryption systems with some modifications. Hybrid Systems make use ofAsymmetric method for agreeing upon a secret key and the actual encryption and decryption of data is done by this secretkey.Some such methodis the usual Industrial practice. The Secret keyused here is valid only for a particular instance of transmission of message and so is usually called ‘session-key’. ( This is not the ‘session’ as usually understood in servlets, because this is an one-time operation).

Digital Envelope

An illustration of Hybrid method is a Digital Envelope. In this scheme, Sam encrypts the message by a random Secret key, ( known as DEK i.e.Data-Encryption-keyor session key).Next Sam encrypts this session key with Tom’s public key. At this stage, Sam sends both the encrypted message and the encrypted session key to Tom.

At the receiving end, Tom uses his private key to get the session key. Using this session key, Tom decrypts the message.As Symmetric method is about 1000 times faster thanAsymmetric method , this is a good combination. Though public key method also has been used here, it is only for encrypting the session key and not the message.This can be further improved by creating a hash of the message and sigining it. Also, there is no permanent Secret key betweenSam & Tom,and the required secret key is produced just as required and then discarded after the job. Thus, the method is fast and secure.

With this background information, let us now see some simple code examples,specific to JDK.

There are a number ofCryptographic Engines in SunJCA & SunJCE. They are listed below. It will be immediately evident that the names will beGreek & Latin to us , unless we have a background in Crypto terminology. That is why, a broad outline was given. The function of some of the engines will be evident from the earlier discussion. A few more of the remaining items will be clear when we deal with code examples.

Cryptographic Engines

  1. KeyGenerator( symmetric) (Blowfish, DES,TripleDES,HmacMD5, HmacSHA1,RC5)
  2. KeyPairGenerator( asymmetric) (DiffieHellman, DSA, RSA)
  3. Mac ( message authentication code) HmacMD5, HmacSHA1)
  4. MessageDigest (MD5,SHA1)
  5. Signature (MD5withRSA, SHA1withRSA, SHA1withDSA)
  6. Cipher ( Blowfish, DES, TripleDES etc)
  7. CertificateFactory ( X509)
  8. KeyAgreement( DiffieHellman)
  9. KeyFactory
  10. SecretKeyFactory
  11. SecureRandom ( SHA1PRNG) (ie) ( SHA1 ..pseudo-random-number-generator)
  12. TrustManagerFactory
  13. KeyManagerFactory
  14. KeySore ( JKS, PHCS12)
  15. SSLContext
  16. AlgorithmParameterGenerator
  17. AlgorithmParameters

Let us now see a series of code-examples to get familiarity with some of the above engines. For all the examples, we are using JDK1.4.2. Our working directory is
[code]
g:securitydemos.

cd to g:securitydemos

We should set <b>path </b>as :

c:windowscommand;d:<b>jdk1.4.2</b>bin
[/code]
The easiest to understand is the MessageDigest. demo1.java”creates the messagedigest of the string s1, by SHA method(Secure Hash Algorithm) . The given string is first converted into a byte array, because the function md.digest(), accepts only a bytearray.md.update() simply adds the array to existing arrays,if any. The digest object thus created is simply saved as object to the file.
[code lang=”java”]
*******************************************

// demo1.java

//
creation of message-digest

//
storing the string &amp; digest in file

importjava.io.*;[/code]

Filed Under: Java EE Tagged With: JCA, JCE

J2EE Connector Architecture(JCA), An Introduction

July 16, 2007 by Krishna Srinivasan Leave a Comment

Introduction

JCA, the J2EE Connector Architecture, is an initiative towards EAI, Enterprise Application Integration. It is a standardized architecture providing the J2EE Components to have plug and play access to heterogeneous EIS, Enterprise Information Systems. Examples of EIS are ERP (Enterprise Resource Planning), Transaction Processing Systems, Legacy Database Systems etc. In the following section we will discuss about the major problems that the programmers had to face for the EIS Integration and the role of JCA.

also read:

  • Java EE Tutorials
  • Java EE 7 Tutorials
  • Java EE Interview Questions

EIS Integration

An Enterprise Information System provides the information infrastructure for an enterprise. This information may be in the form of records in the database, business objects in an ERP, a workflow object in a Customer Relationship Management (CRM) System or a transaction program in a transaction processing application. Prior to the Internet economy, many companies had heavily invested in Business and Management Information Applications Systems.

Examples of such systems can be:-

  • ERP, Enterprise Resource Planning applications, such as SAP, BAAN etc.
  • CRM, Customer Relationship Management applications, such as Seibel and Clarify.
  • Database applications such as DB2 and Sybase.
  • Main Transaction processing applications, such as CICS.
  • Legacy Database Systems such as IBM’s IMS.

Before the JCA, most vendors supported a variety of custom adapters for integrating their EIS. Basically these adapters provided custom native interfaces, which were complex to incorporate and limited to only one EIS. Because of this the application programmers had to deal with as many adapters as the number of EIS their application communicates to. Some of the limitations are listed below:-

  1. Application programming for the EIS was proprietary in nature, because there was no generic platform for integration with the open architectures.
  2. Custom adapters lacked support for Connection Management, which is very crucial for large scale Web Applications, where thousands of customers interact every second. Because of which programmers had to implement connection pooling in their code which is a shear waste of time and money of the enterprises.
  3. There was no standard infrastructure solution available to provide a vendor-neutral Security Mechanism and Generic Transaction Mechanism support to multiple EIS resource managers.

In order to address the above problems Sun Microsystems released the J2EE Connector Architecture, JCA that provides a standard architecture for integration of J2EE Servers with heterogeneous EIS resources. It provides a common API and a common set of services within a consistent J2EE Environment.

The following diagram shows the J2EE application server with the JCA Components and some Enterprise Information Systems:-

In the above diagram, there is a Web Container and an EJB Container in the J2EE Application Server. There are also some blocks for Resource Adapters. Resource adapters play the role of intermediaries between the J2EE Application / Web Components and the EIS. The programmers communicate with the Resource Adapters using the CCI API, Common Client Interface API. This is very similar to the JDBC API where the J2EE Components communicate with the relational database drivers using the JDBC API.

In this architecture, the J2EE Application Server implements the JCA Services like Connection Management, Transaction Management and Security Management etc. Whereas the EIS vendors implements the Resource Adapters specific to their products. This way the programmers need to code their programs in vendor neutral manner to communicate with heterogeneous EIS resources from different vendors.

Elements of the J2EE Connector Architecture

The JCA is implemented by J2EE compliant Application Servers and the Resource Adapters are provided by the EIS vendors.
The Resource Adapter is an EIS specific, pluggable J2EE Component in the Application Server, which provides an interface for the J2EE Components to communicate with the underlying EIS.

There are the following elements and Services in a JCA implementation:-

  1. System-level Services: – It defines the standard interface between the J2EE Components and the J2EE Aplication Server provider and the EIS Vendor. This contract specifies the roles and responsibilities of the Resource Adapter and the Application Server, so that they can co-ordinate with each other for the System level services like Connection Pooling, Security and Transactions. Furthermore this allows for any JCA compliant Resource Adapter to be pluggable to any J2EE Compliant Application Server.
  2. CCI, Common Client Interface: – This is an API which is used by the J2EE Components and other non managed Java Applications (like standalone Java programs and Java Applets) to communicate with the Resource Adapters, which in turn communicate to the underlying EIS.
  3. Packaging and Deployment Interfaces: – Packaging and Deployment Interfaces allow the Resource Adapters to be able to plug into any Application Server.

The following diagram shows all the components of the J2EE Connector Architecture. It shows how the components communicate with each other.

The CCI, Common Client Interface is part of the implementation of the Resource Adapters. The J2EE components use this API in order to communicate with the underlying EIS resource. Because of the System Level contracts the J2EE Application Servers provide the services like Connection Pooling, Transaction Management and Security Management and the programmers can stay away from the implementation of these services.

There are two types of environments based on the type of client application using the Resource Adapter. These are: –

  • Managed Environment: – This includes the multi tired J2EE based Web Applications that may have several Web / Application Components communicating to the Resource Adapters. Such applications are called as the Managed Applications in the JCA context.
  • Non-Managed Environment: – In a two tired architecture, where the application client directly uses the application, the Resource Adapter provides the system level services to its clients. Such applications are referred as Non Managed applications.

Resource Adapter

The Resource Adapter is a component in the J2EE Connector Architecture that sits between the J2EE Components and the EIS. This module is implemented with the EIS specific library, which can be written in Java or with native interface components. Basically it implements two things, first is the Common Client Interface, CCI so that when the developers invoke the methods of this library in their code, the invocations can be resolved by the implementations inside the Resource Adapter, and second is the implementation of the functionality through which it connects to the underlying EIS resource and get the work done for the method invocations. The Resource Adapters are required to support the System Level contracts as is required by the Application Servers. There are mainly two types of contracts that a Resource Adapter implements in order to get compliant with the JCA. These are: –

  • Application-Level Contracts: – Application Contract basically defines the CCI that the Resource Adapter must implement in order for the J2EE Components and the non-managed components to communicate to the underlying EIS resource.
  • System-Level Contracts: – This defines a set of System Contracts which enable the Resource Adapter to plug-in into the Application Server and utilize its services to manage connections, transactions and Security. The three basic contracts are discussed below: –
    • Connection Management: – The Connection Management contract specifies the following things: –
      1. Connection to the Resource Adapters for managed and non-managed components can be made by using consistent application programming techniques, which remain same every time.
      2. The Resource Adapter provides the Connection Factory and Connection Interface based on the CCI, which in turn is specific to the EIS.
      3. Provide a generic mechanism for the J2EE components to consume the Application Server services like Transaction, Security and last but not the least the Connection Pooling etc.
    • Transaction Management: – This contract extends the Application Server’s transactional capabilities to the underlying EIS Resource Managers. An EIS Resource Manager manages a set of shared EIS resources to participate in a transaction. It can manage the following two types of transactions: –
      1. XA Transaction: – XA Transactions are controlled and coordinated by external Transaction Managers. A JTA XATransaction Management contract exists between the JCA compliant Resource Adapters and its underlying Resource Manager. The participating EIS resource also supports XA Transactions by implementing an XAResource in their Resource Adapter. The JTA XAResource interface enables two resource managers to participate in transactions coordinated by an external Transaction Manager. This allows the transactions to be managed by a transaction manager which is external to the Resource Adapter.
      2. Local Transactions: – These transactions do not require any external Transaction Manager, because it is managed internally, either by the J2EE Application Server (container managed) or by the J2EE component (component managed). In Component Managed Transactions the component uses JTA UserTransaction interface or a transaction API specific to the EIS. When an application component requires an EIS Connection, the Application Server starts a local transaction using the currently available transaction context. Upon closure of the connection by the application component, the server commits or rolls back depending upon success or failure of the transaction.
    • Security Management:- This contract defines ways to implement security between the Application Server and the EIS resource. There are the following mechanisms used to protect the EIS against unauthorized access and other security threats:-
      1. Use of user identification, authentication and authorization.
      2. Use of open network communication security protocols like Kerberos which provide end to end security with authentication and confidentiality services.
      3. Implementing an EIS specific security Service.

EIS Sign-On

A Sign-on process is required while creating a new connection to EIS. Based on the security context, authentication and authorization is done for the user to obtain appropriate access. A re-authentication is required in case the Security Context is changed for the user. The following steps are required for sign on:-

  1. Identity of the initiating user, or Resource Principal, is determined. This helps finding the security context of the user using which the connection will be established to the EIS.
  2. Resource Principal is authenticated if the connection is not already authenticated.
  3. Establish a secure connection between the Application Server and the EIS Resource using secure mechanisms like SSL or Kerberos etc. At this point the connection is associated with the initiating user. All subsequent invocations will happen under this context.

This sign-on process can be Application Managed or it can be Container Managed. In case of Application Managed sign-on process, the application component itself provides the security credentials to the EIS Resource Adapter. While in the later case it becomes the duty of the application to find out the Resource Principal of the initiating user and present information of this Resource Principal to the EIS Resource Adapter in the form specific to the JAAS, Java Authentication and Authorization Service.

Packaging and Deploying a Resource Adapter

The Resource Adapters module is packaged as a .rar file, similar to the .ear files for the J2EE Application Modules. There are proper deployment and packaging interfaces that allow a Resource Adapter to plug-in to any J2EE compliant Application Server. The following diagram illustrates the process of packaging and deployment of Resource Adapters module into the Application Server.

The exact steps involved in packaging and deployment are listed below: –

  1. The EIS Resource Adapter provider, usually the EIS Vendor, implements the Resource Adapter as a set of Interfaces and utility classes implementing the CCI API and the EIS functionality. These implementations take care of the JCA contracts that the Resource Adapter need to follow for JCA compliance.
  2. All the components of the Resource Adapter, including the source files are packaged into a .rar file, called as Resource Adapter Module. The deployment descriptor of the Resource Adapter specifies the contract between the Resource Adapter provider and the one who deploys the Resource Adapter.
  3. In the actual deployment process the Resource Adapter is deployed in the Application Server and then it is configured with the Application Server and the underlying EIS environment.

Lets now discuss these steps in greater detail:-

Packaging a Resource Adapter

The Resource Adapters are proper J2EE components packaged in .rar files. One or more Resource Adapters can be staged in one directory and then packaged as .rar files. The following steps are usually involved for packaging a Resource Adapter:-

  1. Compile the Resource Adapter Java files into a staging directory.
  2. Create a .jar file to add the class files created in the above step.
  3. Create an ra.xml deployment descriptor file in the META-INF subdirectory. Add entries for the Resource Adapter.
  4. Create a J2EE Application Server specific deployment descriptor in the same directory and add the entries for the Resource Adapter.
  5. Create the Resource Adapter module .rar file by executing the following command: –

[code lang=”java”] jar cvf JavaBeatResourceAdapter.rar -C staging-dir[/code]

Now this .rar file can be deployed to the Application Server or packaged inside an application’s .jar file. The packaged Resource Adapter includes the following: –

  1. Java Classes and Interfaces that implement the functionality of the JCA contract and the underlying EIS resource.
  2. Some helper classes used by main implementation classes.
  3. Platform dependent native libraries required by the Resource Adapter.
  4. Meta information about the above elements.
  5. Documentation.

After installation of the .rar file, the directory structure of the Application Server looks like the following: –

[code lang=”java”] \AppServerHomeDir
\config
\JavaBeatDomain
\applications
\JavaBeatResourceAdapter.rar [/code]

There are basically two deployment descriptors packaged within a .rar file of the Resource Adapter Module. These are the ra.xml, which specifies the general information about the Resource Adapter, and the ABCAppServer.xml, which specifies operational parameters required for the Application Server.

Ra.xml, the Resource Adapter deployment descriptor

Following is a deployment descriptor for an ABC Resource Adapter, we will discuss about all the xml elements in this file after this example: –

[code lang=”xml”]<connector>

<display-name>ABCResourceAdapter<display-name>
<vendor-name>Java Beat</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>JDBC Database</eis-type>
<version>1.5</version>

<resourceadapter>

<managedconnectionfactory-class>com.sun.connector.javabeat.NoTxManagedConnectionFactory</managedconnectionfactory-class>
<connectionfactory-interface>javax.sql.Datasource</connectionfactory-interface>
<connectionfactory-impl-class> com.sun.Connector.abc.JdbcDataSource</connectionfactory-impl-class>
<connection-interface>java.sql.Connection</connection-interface>
<connection-impl-class>com.sun.connector.abc.JdbcConnection</connection-impl-class>
<transaction-support>NoTransaction</transaction-support>
<config-property>
<config-property-name>ConnectionURL</config-property-name>
<config-property-type>java.lang.String</config-property-type>
<config-property-value>jdbc:cloudspace:rmi:CloudscapeDB:create=true</config-property-value>
</config-property>
<authentication-mechanism>
<authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
<credential-interface>javax.resource.security.PasswordCredential</credential-interface>
</authentication-mechanism>
<reauthentication-support>false</reauthentication-support>

</resourceadapter>

</connector>[/code]

The first block of the descriptor is:-

[code lang=”xml”]<display-name>ABCResourceAdapter<display-name>
<vendor-name>Java Beat</vendor-name>
<spec-version>1.0</spec-version>
<eis-type>JDBC Database</eis-type>
<version>1.5</version>[/code]

It lists general information about the Resource Adapter, like its name, Vendor’s name, specification version, the type of the EIS resource that this Adapter is representing and the version of the JCA supported.

Then the name of the class that implements the javax.resource.spi.ManagedConnectionFactory interface is listed in the element.

The ConnectionFactory interface and the implementation class are mentioned thereafter in the following block of the descriptor:-

[code lang=”xml”]<connectionfactory-interface>javax.sql.Datasource</connectionfactory-interface>
<connectionfactory-impl-class> com.sun.Connector.abc.JdbcDataSource</connectionfactory-impl-class>[/code]
The Connection implementation class for the java.sql.Connection interface is com.sun.connector.abc.JdbcConnection.

The level of transaction support can be either NoTransaction, or LocalTransaction or XATransaction. In this example the Resource Adapter does not support transaction which is specified by the NoTransaction value in the element.

Certain properties of ManagedConnectionFactory can be configured by specifying a name and type of the property and then providing a value of the property as follows: –

[code lang=”xml”]<config-property>
<config-property-name>ConnectionURL</config-property-name>
<config-property-type>java.lang.String</ config-property-type>
<config-property-value>jdbc:cloudspace:rmi:CloudscapeDB:create=true</ config-property-value>
</config-property>[/code]

The last section of the deployment descriptor specifies the authentication mechanisms supported by the Resource Adapter provider. In this case only BasicPassword method is supported. The Security Credential interface is javax.resource.security.PasswordCredential. There is no re-authentication support with this Resource Adapter.

[code lang=”xml”]<authentication-mechanism>
<authentication-mechanism-type>BasicPassword</authentication-mechanism-type>
<credential-interface>javax.resource.security.PasswordCredential</credential-interface>
</authentication-mechanism>
<reauthentication-support>false</reauthentication-support>[/code]

The Resource Adapter can be deployed in two ways as discussed below: –

  1. By using the deploytool command line or the deploytool UI console using the following command: –
    • [code lang=”xml”]Deploytool -deployConnector %J2EE_HOME%\lib\connector\abc-ra.rar <HostName>[/code]
  2. Deploying as a Web Application archive file, i.e. .ear file. In this method the .rar file is included into the .ear file just as we include a .jar or .war file in it. And then the .ear file is deployed in the Application Server. To identify the .rar module in the package the following line is added into the application.xml file: –
    • [code lang=”xml”]<connector>abcresourceadapter.rar</connector>[/code]

JCA Advantages

J2EE Connector Architecture has emerged as the primary technology for providing a vendor neutral platform for the programmers to communicate with multiple EIS resources without changing their components at all. There are the following scenarios in which the technology offers a potential solution: –

  1. Enterprise Application Integration: – While integrating multiple EIS applications there are many challenges that need to be taken care of. These include, transaction, security and scalability issues. Multiple EIS vendors providing their own proprietary APIs for integration, which creates much bigger problem of embedding code specific to each vendor into the application components. But with the JCA technology, the EIS vendors are now required to provide with a Resource Adapters obeying the JCA contracts. And the programmers need to understand just the CCI API, required to communicate with the similar Resource Adapter of all the different EIS resources.
  2. Web-Enabled Enterprise Portals: – Enterprise portals usually unifies all the information, services, applications and processes for all the members of an enterprise, including the employees, clients, partners and customers etc. Such a portal needs to integrate all the heterogeneous EIS resources, such as database systems, information systems etc. which handle all information of the enterprise. In such a scenario the JCA technology solves the problem by seamlessly integrating the different EIS resources by introducing the concept of Resource Adapters and the CCI API. It also helps by providing the EIS sign-on mechanism that supports generic and application specific authentication mechanism.
  3. Business to Business Integration: – Business to Business integration requires end-to-end process automation and allows application interaction with an enterprise and across partners through the internet. In order to support the external partner interactions, the backend internal business systems need to be seamlessly integrated into the same process. With the help of JCA the backend EIS resources and end to end processes can be integrated without much difficulty.

Summary

In this article we discussed about the concept of JCA, J2EE Connector Architecture, how it helps in solving the problems faced in EAI, Enterprise Application Integration, by introducing the concept of Resource Adapters, and the CCI API to facilitate communication between the J2EE Application Components and the underlying EIS, Enterprise Information Systems. We also discussed about the deployment details of the Resource Adapters by looking into two main deployment descriptors required in the process.

This technology is aimed to solve the problems and challages that the industry face while working with heterogeneus EIS, Enterprise Information Systems. In the next article we will discuss about this technology in more detail, which would be aimed at professional programmers in the J2EE domain.

Filed Under: Java EE Tagged With: JCA

Follow Us

  • Facebook
  • Pinterest

As a participant in the Amazon Services LLC Associates Program, this site may earn from qualifying purchases. We may also earn commissions on purchases from other retail websites.

JavaBeat

FEATURED TUTORIALS

Answered: Using Java to Convert Int to String

What is new in Java 6.0 Collections API?

The Java 6.0 Compiler API

Copyright © by JavaBeat · All rights reserved