ÀÌ ¹®¼ÀÇ ³»¿ë¿¡ ´ëÇÑ ¹«´Ü º¹Á¦¸¦
±ÝÇÕ´Ï´Ù.
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.
- First create a WSDL document.
Note that mandated JAX-RPC support for soap bindings are
rpc/encoded, rpc/literal and document/literal.
- Next create a wscompile tool configuration document (config.xml) and specify the
location of WSDL document in it.
- 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
:
- ConnectionFactory interface which declares getConnection()
method (if not use javax.resource.cci.ConnectionFactory)
- ConnectionFactory implementation class
- Connection interface which declares close() method (if not use javax.resource.cci.Connection)
- Connection implementation class
- javax.resource.spi.ManagedConnectionFactory implementation class
- javax.resource.spi.ManagedConnection implementation class
- javax.resource.spi.ConnectionManager implementation class (only
used in non-managed environment)
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
- EJB is a distributed component, to say a remote object, which RA
is not. So RA cannot be called from outside J2EE server.
- 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.
- Using RA from other components requires additional registration
of RA as a resource. It's a bit more bothersome.
Pros
- RA is much less restrictive than EJB. RA can access the local
file system, can bind a server socket, ...
- RA doesn't use remote calls. everything occurs locally.
- 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
- 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