이 문서의 내용에 대한 무단 복제를 금합니다.
Copyright © 2003 Yoon Kyung Koo, All rights reserved.

Notes on J2EE 1.4 AS Developer Release and Features

J2EE 1.4 AS 개발자 릴리스를 사용하면서 웹서비스와 EJB, JMS, J2EE Connector, XML 등에 관련된 팁들을 정리하고 있습니다.

1. Web Service Creation in EJB 2.1

Only a stateless session bean(say, SLSB) can create a web service.

WSDL to SLSB

Defining WSDL document first is a top-down way to create a web service. We will use the wscompile tool.
  1. First create a WSDL document.
    Note that mandated JAX-RPC support for soap bindings are rpc/encoded, rpc/literal and document/literal.
  2. Next create a wscompile tool configuration document (config.xml) and specify the location of WSDL document in it.
  3. run wscompile -f:wsi -keep -import -mapping jaxrpc_mapping.xml config.xml. This tool generates necessary stub files and a JAX-RPC mapping file which is necessary for J2EE environment.
    If you don't want to map xml types to java types, -f:nodatabinding option will help, in which you should handle SOAPElement parameters yourself. However, I can't see the way how J2EE 1.4 AS generate tie objects for no data bound SEI.
    (-f:wsi option mandates WS-I interoperable code. for further usage of wscompile tool, follow after JAX-RPC Tools link below.)
[HERE TO GO]

SLSB to WSDL

Generating WSDL document later is a bottom-up way to create a web service.
wscompile -define -d ${somewhere_java_output} -nd ${somewhere_nonjava_output} -classpath ${classpath} -mapping mapping.xml config.xml

2. How the Dynamic Proxy works?

Dynamic proxy is a Java language new-comer in Java 2 SDK 1.3.
[HERE TO GO]

3. Message-Driven Bean

To use message-driven bean(in short, MDB) in J2EE 1.4 AS, you should set the JNDI name of EJB as the JNDI name of message destination in sun-ejb-jar.xml (sun-ejb-jar|enterprise-beans|ejb|jndi-name) in case of using JMS message.
Note that you can use non-JMS messaging scheme in MDB from J2EE version 1.4.

Non-JMS, i.e., R/A incoming message endpoint MDB

With J2EE 1.4 AS DR, configuring ejb-jar.xml is not sufficient for Resource Adapter endpoint MDBs.
An additional, non-standard sun-ejb-jar.xml is required to describe resource adapter information like this :
<sun-ejb-jar>
  <enterprise-beans>
    <name>MyRAEndpoint</name>
    <unique-id>239732644</unique-id>
    <ejb>
      <ejb-name>MyRAEndpointBean</ejb-name>
      <jndi-name>MyRAEndpointBean</jndi-name>
      <mdb-resource-adapter>
        <resource-adapter-mid>MyResourceAdapter</resource-adapter-mid>
        <activation-config>
          <activation-config-property>
            <activation-config-property-name>myPropertyName1</activation-config-property-name>
            <activation-config-property-value>MyPropertyValue1</activation-config-property-value>
          </activation-config-property>
        </activation-config>
      </mdb-resource-adapter>
    </ejb>
  </enterprise-beans>
</sun-ejb-jar>

4. Building a resource adapter which conforms to J2EE Connector 1.5

4.1. System contracts

a. Connection management contract
Resource Adapter has two kinds of connections. One is for application components and the other is for physical EIS connections.
ConnectionFactory and Connection is conceptually defined for application components but the contract doesn't specify the interface types which represent the RA-application component connection and factory. so any Java interfaces will do for the connection and factory.
ConnectionFactory interface should have a getConnection() method which returns specific connection interface, and Connection interface should have a close() method.
If the RA supports CCI, then the connection would be javax.resource.cci.Connection and the factory would be javax.resource.cci.ConnectionFactory.
In case of JDBC, the connection is java.sql.Connection and the factory is javax.sql.DataSource.
javax.resource.spi.ManagedConnectionFactory and javax.resource.spi.ManagedConnection interfaces are used for the physical EIS connections.
Other related interfaces include javax.resource.spi.ConnectionManager, javax.resource.spi.ConnectionRequestInfo.
Application Server provides a ConnectionManager implementation for RA in managed environment, but RA itself should provide a ConnectionManager implementation for non-managed environment. This is another requirement of implementing an RA.

To summarize, Resource Adapter implementation should include belows :

b. Transaction management contract
A Resource Adapter should provide javax.resource.spi.LocalTransaction implentation class if local transaction is supported.
And should provide javax.transaction.xa.XAResource implementation class if global(XA) transaction is supported.
ManagedConnection implementation class will have references to local transaction and xa resource objects.
c. Security contract
d. Lifecycle management contract
A Resource Adapter implementation class should implement interface javax.resource.spi.ResourceAdapter and follow the JavaBeans requirements. Say, ResourceAdapter JavaBean.
Outbound communication uses a javax.resource.spi.ManagedConnectionFactory interface (and also javax.resource.spi.ResourceAdapterAssociation interface) implemented JavaBean.
Likewise, inbound communication uses a javax.resource.spi.ActivationSpec interface (which extends javax.resource.spi.ResourceAdapterAssociation interface) implemented JavaBean.
Usually ManagedConnectionFactory JavaBean and ActivationSpec JavaBean registers themselves with the ResourceAdapter object.
e. Work management contract
See javax.resource.spi.work.Work interface and javax.resource.spi.work.ExecutionContext class.
f. Transaction inflow contract (for inbound connectivity type)
g. Message inflow contract (for inbound connectivity type)
A message end point should be specified as an MDB. Additional activation information should be given using activation-config element in the MDB deployment descriptor. Related types include javax.resource.spi.ActivationSpec and javax.resource.spi.MessageEndpointFactory.

4.2. Client API

a. Standard Common Client Interface(CCI)
b. Adapter-specific client API
[HERE TO GO]

4.3. Configuration

ResourceAdapter, ManagedConnectionFactory, ActivationSpec class are designed as JavaBeans, and can be configured by deployment descriptor.

4.4. Resource Adapter in comparison with EJB

A resource adapter can be a valuable component of J2EE server from J2EE 1.4. It can afford both incoming and outgoing messaging and communicate with EJBs in bi-directional way, which servlets cannot (EJB cannot lookup servlets).
Comparing with EJB would have interesting points. Refer to J2EE Connector Architecture 1.5 specification.
Cons
  1. EJB is a distributed component, to say a remote object, which RA is not. So RA cannot be called from outside J2EE server.
  2. Clustering RA is not as easy as EJB. If RA is implemented not to use connections to external EIS sytems, which can be possible according to the J2EE 1.4 spec, the RA developer should implement all the recovery and redundancy things by himself.
  3. Using RA from other components requires additional registration of RA as a resource. It's a bit more bothersome.
Pros
  1. RA is much less restrictive than EJB. RA can access the local file system, can bind a server socket, ...
  2. RA doesn't use remote calls. everything occurs locally.
  3. RA's life cycle is much more predictive and straightforward than EJB's. RA has much less managed aspects, so it's easier to implement something which has long and stateful life cycle.

4.5. Known Bugs

  1. Resource adapter is not updated when redeployed until the AS restarts.

5. Java Message Service(JMS)

Performance issues

TextMessage performs better than BytesMessage, BytesMessage than ObjectMessage. [HERE TO GO]

Competing Consumers

[JMS 1.1 p65]
For PTP, JMS does not specify the semantics of concurrent QueueReceivers for the same Queue; however, JMS does not prohibit a provider from supporting this. Therefore, message delivery to multiple QueueReceivers will depend on the JMS provider’s implementation. Applications that depend on delivery to multiple QueueReceivers are not portable.

[EJB 2.1 p340]
The Deployer should avoid associating more than one message-driven bean with the same JMS Queue. If there are multiple JMS consumers for a queue, JMS does not define how messages are distribued between the queue receivers.

[JMS 1.1 p77] Queue regarding JMS selector
A client uses a QueueReceiver for receiving messages that have been delivered to a queue.
Although it is possible to have two sessions with a QueueReceiver for the same queue, JMS does not define how messages are distributed between the QueueReceivers.
If a QueueReceiver specifies a message selector, the messages that are not selected remain on the queue. By definition, a message selector allows a QueueReceiver to skip messages. This means that when the skipped messages are eventually read, the total ordering of the reads does not retain the partial order defined by each message producer. Only QueueReceivers without a message selector will read messages in message producer order.

[JMS 1.1 p83] Topic regarding JMS selector
Messages filtered out by a subscriber’s message selector will never be delivered to the subscriber. From the subscriber’s perspective, they simply don’t exist.

A. Related Links

[Class Loader, Dynamic Proxy, XML, JDBC, JNDI, LDAP, Transaction, Security, Cryptography, SSL, Authentication, Login, Authorization, CORBA, RMI, RMI-IIOP, ... 본격적인 자바 개발자로 가기 위한 (책) 자바 2 SDK 1.4 시작 그리고 완성]

Yoon Kyung Koo <yoonforh at yahoo dot com>
이 페이지는 2003년 12월 1일에 처음 만들어졌습니다.
Last modified: Fri Feb 27 15:32:49 KST 2004