Io exception: The Network Adapter could not establish the connection

Recently, i did an RAC validation with our oracle partner and encountered this weird exception called "Io exception: The Network Adapter could not establish the connection".

Two client machine were running same java code (using jdbc thin driver & oracle datasource) in the same LAN as RAC servers, but they came out with differen behaviour. One could connect to RAC database, the other one always got io exception mentioned above.

The only difference between two machines was one of clients' host file having rac ip & hostname mapping entry, which is able to connect to oracle rac db.

Something weird is that all db clients and servers were actually sitting in the same LAN. I could ping and telnet db rac with rac ip address (virtual and real ) from client machines, but when i use ip address in the java class to lookup the db connection, i could not get connected to db if rac ip & hostname mapping entries were not available in the client host file.

Here is the sample Codes for RAC FCF connection:

OracleDataSource ods = new OracleDataSource();
OracleConnectionCacheManager occm = null;
ods.setUser("user-name");
ods.setPassword("password");
String cacheName = "cache";
String dbURL="jdbc:oracle:thin:@"+
"(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=ON)" +
"(ADDRESS=(PROTOCOL=TCP)" +
"(HOST=rac1-vip-address)(PORT=1521))" +
"(ADDRESS=(PROTOCOL=TCP)" +
"(HOST=rac2-vip-address)(PORT=1521)))" +
"(CONNECT_DATA=(SERVICE_NAME=orcl.abc.com)))";
ods.setURL(dbURL); System.out.println("Url=" + dbURL ); ods.setConnectionCachingEnabled(true);
Properties prop = new Properties();
prop.setProperty("MinLimit", "5");
prop.setProperty("MaxLimit", "40");
prop.setProperty("InitialLimit", "10");
prop.put (oracle.net.ns.SQLnetDef.TCP_CONNTIMEOUT_STR,"" + (5000)); // 5000ms ods.setConnectionCacheProperties(prop);
ods.setFastConnectionFailoverEnabled(true);
ods.setONSConfiguration("nodes=rac1-ip-address:6200,rac2-ip-address:6200"); ods.setConnectionCacheName(cacheName);
//occm = OracleConnectionCacheManager.getConnectionCacheManagerInstance();
Connection conn = ods.getConnection();

It looks somewhere JDBC driver looking up db connection with rac hostname instead of ip address and I have to put the rac ip & hostname mapping in the client host file for jdbc driver to resolve them.

Web service security & clustering

The Oracle Web Services Manager (OWSM) secures Web services by using policy enforcement points. It has several types of policy enforcement points: Gateways, Web service client agents (client-Agents), and Web service agent (server-Agents). These policies are created, managed, and located in the OWSM Policy Manager, which is a centralized policy store.

An example policy could be to require authentication and authorization to all services. This policy is centrally stored in the Policy Manager, and is consumed by all the agents and gateways deployed in the SOA.

Gateway Use Case

An Internet facing Web service can be protected by inserting a gateway in front of it. A gateway is similar to a web based proxy, it is a choke point where all Web service traffic is forced through. Gateways are SOAP/XML intermediaries that enforce Web services policies while intermediating Web services traffic between clients and services.

This would be done using a WS-Security Username Token for authentication. Based on the credentials, the gateway should be able to authenticate and authorize access to the service.

Alternatively, WS-Security SAML Token can be applied when business partners expose business processes to each other within a secure context.

Agent Use Case

A Web service agent is another useful policy enforcement point. Agents (client-Agents and server- Agents) are SOAP interceptors that enforce Web services policies from within the same Web application.

Agents execute in the same process as the application, while Gateways run on separate processes and possibly on different servers. Gateways can manage services from multiple applications while agents control services belonging to the single application.

Web service is not exposed over the internet, then using agents is a viable option to secure the business process. There can be other reasons for using agents. For example, if one wants end-to-end security where the data is secured from the beginning to the end of the process.


OASIS WSS UsernameToken Profile (User name and password)

OASIS WSS X509 Token Profile 1.1 (certificate based)

OASIS WSS SAML Token Profile 1.1 (Xml accertation token from accertation server for sso)

OASIS WSS SWA Profile 1.1


Reference:

Web Services Security, Part 1

Web Services Security, Part 2

Web Services Security, Part 3

Apache WSS4J 1.1.0 Released

Securing Web Services and the Java WSDP 1.5

Tutorial

Securing Web Services Using the SAML or UserNameToken Profiles

Clustering and Securing Web Applications: A Tutorial

Web Services Security (2003)

http://www.xml.com/pub/a/ws/2003/03/04/security.html
http://www.xml.com/pub/a/ws/2003/04/01/security.html

Oracle TAF & FCF

Transparent Application Failover (TAF)

Transparent Application Failover (TAF) is a feature of the Java Database Connectivity (JDBC) Oracle Call Interface (OCI) driver. It enables the application to automatically reconnect to a database, if the database instance to which the connection is made fails. In this case, the active transactions roll back.

Transparent Application Failover (TAF) is a client-side feature that allows for clients to reconnect to surviving databases in the event of a failure of a database instance. Notifications are used by the server to trigger TAF callbacks on the client-side.

TAF is configured using either client-side specified TNS connect string or using server-side service attributes. However, if both methods are used to configure TAF, the server-side service attributes will supersede the client-side settings. The server-side service attributes are the preferred way to set up TAF.

TAF can operate in one of two modes, Session Failover and Select Failover. Session Failover will recreate lost connections and sessions. Select Failover will replay queries that were in progress.

Transparent Application Failover
Configuring Transparent Application Failover

Fast Connection Failover (FCF)

Fast Connection Failover offers a driver-independent way for your Java Database Connectivity (JDBC) application to take advantage of the connection failover facilities offered by Oracle Database 10g. The Fast Connection Failover mechanism depends on the implicit connection cache feature. As a result, for Fast Connection Failover to be available, implicit connection caching must be enabled.

FCF vs TAF

TAF is always active and does not have to be set, it does not work with the OCI Connection Pool.
Oracle recommends not to use TAF and Fast Connection Failover in the same application

Web Services Protocol Stack

You may hear web services for many years and already get some ideas of it, but always get confused and lost in the set of protocol and technology in use and not sure how they are related to each other in the picture.

Here, i would like to give another explanation of them from underlying protocol stack in use for web service so that you can organized, relate them properly in mind.

The Web service protocol stack is a collection of computer networking protocols that are used to define, locate, implement, and make Web services interact with each other. The Web service protocol stack mainly comprises four areas (source:wikipedia):

* Transport Protocol: responsible for transporting messages between network applications and includes protocols such as HTTP(s), SMTP, FTP, as well as the more recent Blocks Extensible Exchange Protocol (BEEP). Now, most common protocol in use is HTTP(S).

* Messaging Protocol: responsible for encoding messages in a common XML format so that they can be understood at either end of a network connection. Currently, this area includes such protocols as XML-RPC, WS-Addressing, REST and SOAP, which is most common one in use today.

* Description Protocol: used for describing the public interface to a specific web service. The WSDL interface format is typically used for this purpose.

* Discovery Protocol: centralizes services into a common registry such that network web services can publish their location and description, and makes it easy to discover what services are available on the network. At present, the UDDI API is normally used for service discovery.

Web service protocol stack also includes a whole range of recently defined protocols: BPEL, SOAP-DSIG.

In general terms, a web service is a software component or service that has been published on the World Wide Web in one of several particular ways, but industry tends to use the term web services more specifically, to describe services that are exposed using SOAP, an XML-based message encoding that is typically transported using HTTP.

XML-RPC

XML-RPC is a remote procedure call protocol which uses XML to encode its calls and HTTP as a transport mechanism. XML-RPC is a very simple protocol, defining only a handful of data types and commands, and the entire description can be printed on two pages of paper. Some people still prefer XML-RPC to SOAP because of its simplicity, minimalism, and ease of use. (source:wikipedia)

SOAP

SOAP is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework so that more abstract layers can build on.

There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server) and the server immediately sends a response message to the client.

SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere, probably from WDDX (source:wikipedia).

A SOAP message is an ordinary XML document containing the following elements:

* A required Envelope element that identifies the XML document as a SOAP message
* An optional Header element that contains header information
* A required Body element that contains call and response information
* An optional Fault element that provides information about errors that occurred while processing the message

All the elements above are declared in the default namespace for the SOAP envelope (source: w3schools)

WSDL

The Web Services Description Language (WSDL) is an XML-based language that provides a model for describing Web services.The current version of the specification is the 2.0. The WSDL defines services as collections of network endpoints, or ports. WSDL specification provides an XML format for documents for this purpose.A port is defined by associating a network address with a reusable binding, and a collection of ports define a service.

WSDL is often used in combination with SOAP and XML Schema to provide web services over the Internet. A client program connecting to a web service can read the WSDL to determine what functions are available on the server. Any special datatypes used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the functions listed in the WSDL.WSDL 1.2 was renamed WSDL 2.0 because of its substantial differences from WSDL 1.1. By accepting binding to all the HTTP request methods (not only GET and POST as in version 1.1) WSDL 2.0 specification offers a better support for RESTful web services, much simpler to implement by beginners. (source:wikipedia)

A WSDL 1.1 document uses the following elements in the definition of network services:

* Types– a container for data type definitions using some type system (such as XSD).
* Message– an abstract, typed definition of the data being communicated.
* Operation– an abstract description of an action supported by the service.
* Port Type–an abstract set of operations supported by one or more endpoints.
* Binding– a concrete protocol and data format specification for a (not more than one) particular port type.
* Port– a single endpoint defined as a combination of a binding (not more than one) and a network address.
* Service– a collection of related endpoints (port).

WSDL 2.0 is different from WSDL 1.1 check out the example of a structured WSDL 2.0 document from here.

UDDI

Universal Description, Discovery and Integration (UDDI) is a platform-independent, XML-based registry for businesses worldwide to list themselves on the Internet. UDDI is a cross-industry effort driven by all major platform and software providers like Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, and Sun, as well as a large community of marketplace operators, and e-business leaders.

JAX-RPC
Check out my previous two posts (1|2) in this blog.

JAXR

Java API for XML Registries (JAXR) defines a standard API for Java platform applications to access and programmatically interact with various kinds of metadata registries. JAXR provides a uniform and standard Java API for accessing different kinds of XML-based metadata registry.

Current implementations of JAXR support ebXML Registry version 2.0, and UDDI version 2.0. More such registries could be defined in the future.

The JAXR API insulates application code from the underlying registry mechanism. When writing a JAXR based client to browse or populate a registry, the code does not have to change if the registry changes, for instance from UDDI to ebXML.

WS-I
The WS-I Basic Profile (official abbreviation is BP), a specification from the Web Services Interoperability industry consortium (WS-I), provides interoperability guidance for core Web Services specifications such as SOAP, WSDL, and UDDI. The profile uses Web Services Description Language (WSDL) to enable the description of services as sets of endpoints operating on messages. BP complied web service means smooth internal operability (messaging, description and registry) between web services regardless of underlying implementation.

Open Source Tool for JDBC Debugging and Monitoring

P6Spy is a open source framework to intercept and debug JDBC interaction with a database and optionally modify database statements. It's a wrapper of all JDBC elements ( Connection, PreparedStatement, ResultSet... ) and it has a powerful feature in order to log all informations about those interactions. P6Spy includes P6Log, an application that intercepts and logs the database statements of any application that uses JDBC.

This application is particularly useful for developers to monitor the SQL statements produced by EJB servers, enabling the developer to write code that achieves maximum efficiency on the server.

You can also use it together with spring and hibernate for performance tuning as well.

Reference List:

P6Spy

P6Spy Official Home

Integrate P6Spy with Spring

Improving Hibernate's Performance

P6Spy released: automatic logging of your database/EJB queries

XML-RPC vs JAX-RPC

XML-RPC

XML-RPC is a remote procedure call protocol which uses XML to encode its calls and HTTP as a transport mechanism. XML-RPC is a very simple protocol, defining only a handful of data types and commands, and the entire description can be printed on two pages of paper. Some people still prefer XML-RPC to SOAP because of its simplicity, minimalism, and ease of use. (source wikipedia)

The original XML-RPC uses only a few data types and does not require namespaces. It achieves considerable flexibility by defining and types which can contain other values. Responses are also simple XML with as the root element with either or as the child element. The contrast with complex SOAP responses is striking.

For xml-rpc, wsdl and uddi is not involved for client to invoke the web service.

Implementations of XML-RPC:

There are five Implementations in Java list at xmlrpc.com as of December 2003. However, many of these projects appear to be inactive. The project hosted by the Apache Web Services Project is active. It looks like the Apache Web Services Project is on the right track with version 3, so keep an eye open on it if you are interested in an open-source XML-RPC solution.

JAX-RPC - The Java API for XML-based RPC

Instead of using xml-rpc protocol, JAX-RPC make used of SOAP protocol for messaging which enable web service a industry standard.

SOAP

SOAP is a protocol for exchanging XML-based messages over computer networks,normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web services stack, providing a basic messaging framework so that more abstract layers can build on.

There are several different types of messaging patterns in SOAP, but by far the most common is the Remote Procedure Call (RPC) pattern, in which one network node (the client) sends a request message to another node (the server) and the server immediately sends a response message to the client. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere, probably from WDDX. (Source: wikipedia)

WSDL is involved for client to invoke the web service when use JAX-RPC.

Is XML-RPC Still Useful?

The complexity of the JAX-RPC implementation has caused somewhat of a backlash among programmers. It seems you should consider XML-RPC over JAX-RPC if:

* Your application uses relatively simple requests
* You control both server and client sides and/or you don't need to publish a WSDL
* You want to keep client-side parsing simple (as in AJAX applications)

Architecture Chaos of Web 2.0 Application

Struts, Spring, Seam, JSF, Hibernate, iBatis, Ajax and EJB, there are so many java technology, my question is which one should go for to mix and match out a wonderful J2EE Web 2.0 architecture for new project.


Model layer

Spring+Hibernate
Spring+iBatis (With skillful DBA or developers with advnaced sql skill)
EJB 3.0, forget about the EJB 2.1 (with developers expert in JDK 1.5 and annotation)

View & Controller layer

Struts1 + Ajax (zk/echo/gwt) + Tile (templating)
Spring MVC + Ajax (zk /echo/gwt) + Tile (templating)
JSF+Icefaces/Zk(AJAX)+Facelet / Tile(templating)
RichFaces / AJAX4JSF

Integration Layer

Web services
BPEL process (a collection of inter-related web services)
Enterprise Service Bus
JMS & MOM

Other than suggestion above, JBoss seam and Oracle ADF and Webcenter come with full technology stack for web 2.0 architecture.

As for which technology and plaftform should be used in the development, not only it depends on the value and benefits technology bring to the project, but available tools and people to support and accelerate the development play a part as well.

Only with good tools (development & testing) and big pool of talent people/developer, project can be delivered on time.

So, which tools should be chosen for the project development? Again, there are many open tools available in each phase of SDLC.

Someone can use a combination of tools below:

Eclipse with Checkstyle, PMD, Mylar, Subversion (Subclipse), JUnit plug-ins
Subversion version control
maven2
Jira issue tracking
Confluence wiki
Cobertura test coverage
QuickBuild Continuous Integration system
Enterprise Architect for requirements and design in UML, and document generation

But it may not fit your project and you will need to figure out your own tool set with some R&D work on it.

Here, i would like to suggest a book (not-yet-published, but coming-soon) called "Java power tools". It maintain a comprehensive open tools and I believe with this book, people can shorten the R&D work for development tools findings.

So, what is your voice for this confusion and chaos?

JAXM & Messaging

JAXM Definition

JAXM, the Java API for XML Messaging, defines a lightweight Java API for composing, processing, sending, and receiving XML documents. It supports both synchronous (HTTP) and asynchronous (SMTP) messaging and “Out-of-the-box” support for ebXML messaging.

Fundamental Elements

The JAXM Service

A JAXM service consumes JAXM messages sent by a JAXM client. To develop a JAXM service, developers extend the class javax.xml.messaging.JAXMServlet and implement either the javax.xml.messaging.OnewayListener or javax.xml.messaging.ReqRespListener interface. The choice of interface depends upon whether the interaction between the client and the server is asynchronous (OnewayListener) or synchronous (ReqRespListener) in nature.

The JAXM Client

Clients exchange messages with JAXM services. JAXM clients can either interact directly with a JAXM service or go through a JAXM provider. JAXM clients that interact directly with a JAXM service can only participate in synchronous interactions. JAXM clients that use a messaging provider can participate in asynchronous as well as synchronous interactions with the JAXM service.

The JAXM Messaging Provider

A JAXM messaging provider is responsible for managing the routing of messages for a JAXM client. Besides providing a degree of separation between a JAXM client and service, a provider can also offer additional services like reliable messaging, security, and transaction support. Currently, clients that want to interact asynchronously with a JAXM service have to use a provider.

The JAXM Message

All JAXM messages conform to the SOAP 1.1 and SOAP with Attachments standards. JAXM messages also support the concept of higher-level protocols like ebXML through the concept of messaging profiles. A messaging profile defines the messaging contract between two parties. A JAXM client and service that share a message profile like ebXML can conduct business by exchanging ebXML messages.

JAXM & Messaging

* JAXM is an synchronous / asynchronous (queue-based) messaging API
* Not part of J2EE 1.4
* Uses queues on either side
* Doesn’t provide WSDL facilities
* Can be used in conjunction with JAXB to convert to objects

Difference in JAXM & JMS

The JAXM API was designed for Internet SOAP-based messaging, while the JMS API was designed as a common messaging API to be layered over existing enterprise message-oriented middleware (MOM) applications.

The delivery endpoint models differ. JAXM provides direct point-to-point messaging, while JMS uses destinations to provide a reliable asynchronous messaging capability.

JMS clients send messages to, and retrieve them from, destinations. JMS provides a model whereby an intermediary, a messaging server, makes sure a message is delivered between two applications that do not know directly about each other, but know only about the common destination.

A JAXM client is interoperable over any SOAP 1.1 compatible client (there must be an agreed-upon profile between providers, however), whereas a JMS client is interoperable only with other JMS clients over the same messaging system (or another messaging system for which the JMS provider supports a proprietary gateway).

The JMS API does not define interoperability between message providers. It does not define a common message format, only a number of message types; the clients must agree on the precise format. (It is possible to wrap a SOAP message, or any other kind of XML message, in a TextMessage and send it via JMS.)

Find out more info from JAXM FAQ

Why there is a need for JAXM?

The goal of JAXM is to provide a rich set of interfaces for document-style web services. Document-style web services enable the exchange of XML documents between two parties, as opposed to RPC-style web services, which expose software functions as web services.

JAXM-based web services can be used effectively in Such scenario:

When two parties want to exchange data using XML documents that are bounded using well-defined XML schemas instead of invoking software functions (Java objects, C procedures, etc.) exposed as RPC-style web services.

I would like to recommend you to go through a article called "Developing E-Business Interactions with JAXM" for a good understanding of How & Where to use JAXM

Implementation

Sun provides JAXM implementation, but does not support full ebXML messaging service specification, there is alternative implementation of ebMS 2.0 from www.freebxml.org.

ebXML & Message Service

Find more from my previous post here.
Find more from article called "ebXML Message Service - An In-depth Overview"

Reference List:

http://java.sun.com/webservices/jaxm
Sun JAXM tutorial
Developing E-Business Interactions with JAXM

JAX-RPC vs JAX-WS

Java API for XML-Based RPC (JAX-RPC) is a Legacy Web Services Java API, it uses SOAP and HTTP to do RPCs over the network and enables building of Web services and Web applications based on the SOAP 1.1 specification, Java SE 1.4 or lower, or when rpc/encoded style must be used.

You can use the JAX-RPC programming model to develop SOAP-based web service clients and endpoints. JAX-RPC enables clients to invoke web services developed across heterogeneous platforms. Likewise, JAX-RPC web service endpoints can be invoked by heterogeneous clients. JAX-RPC requires SOAP and WSDL standards for this cross-platform interoperability.

JAX-RPC lets people develop a web service endpoint using either a Servlet or Enterprise JavaBeans (EJB) component model. The endpoint is then deployed on either the Web or EJB container, based on the corresponding component model. Endpoints are described using a Web Services Description Language (WSDL) document.(This WSDL document can be published in a public or private registry, though this is not required). A client then uses this WSDL document and invokes the web service endpoint.

JAX-RPC in J2ee 1.4 supports 4 types of stubs and invocations: static stub, dynamic proxy, Dynamic Invocation Interface (DII) and Application client.

Static Stub Client
Web service client makes a call through a stub, a local object that acts as a proxy for the remote service. Because the stub is created by wscompile at development time (as opposed to runtime), it is usually called a static stub.

Example: Invoking a Stub Client
Stub stub = (Stub) (new MyHelloService_Impl().getHelloIFPort());
stub._setProperty (javax.xml.rpc.Stub.ENDPOINT_ADDRESS_PROPERTY,endpoint_address_string);
HelloIF hello = (HelloIF)stub;
System.out.println(hello.sayHello("Duke!"));

Dynamic Proxy Client
In contrast, the client call a remote procedure through a dynamic proxy, a class that is created during runtime. Although the source code for the static stub client relies on an implementation-specific class, the code for the dynamic proxy client does not have this limitation.

Example: Dynamic Proxy
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);
com.example.StockQuoteProvider sqp = (com.example.StockQuoteProvider)service.getPort(portName, StockQuoteProvider.class);
float price = sqp.getLastTradePrice("ACME");

Dynamic Invocation Interface Client
With the dynamic invocation interface (DII), a client can call a remote procedure even if the signature of the remote procedure or the name of the service is unknown until runtime. In contrast to a static stub or dynamic proxy client, a DII client does not require runtime classes generated by wscompile.

Example: Dynamic Invocation Interface
javax.xml.rpc.Service service = ServiceFactory.newInstance().createService(...);
javax.xml.rpc.Call call = service.createCall(portName, "getLastTradePrice");
// This example assumes that addParameter and setReturnType methods are not required to be called
Object[] inParams = new Object[] {"ACME"};
Float quotePrice = (Float)call.invoke(inParams);

Application Client
Unlike the stand-alone clients, for an application client, because it's a J2EE component, an application client can locate a local web service by invoking the JNDI lookup method.

Example: Application Client
Context ic = new InitialContext();
MyHelloService myHelloService = (MyHelloService)
ic.lookup("java:comp/env/service/MyJAXRPCHello");
appclient.HelloIF helloPort = myHelloService.getHelloIFPort();
((Stub)helloPort)._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY,args[0]);
System.out.println(helloPort.sayHello("Jake!"));

Service Endpoint Model

JAX-RPC supports a client model for the service consumer, and a service endpoint model for the service producer.

Application-Level Interaction Modes

JAX-RPC specifies three client application interaction models:
* Synchronous request-response two-way RPC
* Asynchronous (non-blocking) request-response two-way RPC
* One-way RPC

JAX-WS 2.0 is the successor of JAX-RPC 1.1 - the Java API for XML-based Web services. If possible, JAX-WS should be used instead as it is based on the most recent industry standards.

What remains the same?

Before we itemize the differences between JAX-RPC 1.1 and JAX-WS 2.0, we should first discuss what is the same.

* JAX-WS still supports SOAP 1.1 over HTTP 1.1, so interoperability will not be affected. The same messages can still flow across the wire.

* JAX-WS still supports WSDL 1.1, so what you've learned about that specification is still useful. A WSDL 2.0 specification is nearing completion, but it was still in the works at the time that JAX-WS 2.0 was finalized.

What is different?

* SOAP 1.2
JAX-RPC and JAX-WS support SOAP 1.1. JAX-WS also supports SOAP 1.2.

* XML/HTTP
The WSDL 1.1 specification defined an HTTP binding, which is a means by which you can send XML messages over HTTP without SOAP. JAX-RPC ignored the HTTP binding. JAX-WS adds support for it.

* WS-I's Basic Profiles
JAX-RPC supports WS-I's Basic Profile (BP) version 1.0. JAX-WS supports BP 1.1. (WS-I is the Web services interoperability organization.)

* New Java features
o JAX-RPC maps to Java 1.4. JAX-WS maps to Java 5.0. JAX-WS relies on many of the features new in Java 5.0.
o Java EE 5, the successor to J2EE 1.4, adds support for JAX-WS, but it also retains support for JAX-RPC, which could be confusing to today's Web services novices.

* The data mapping model
o JAX-RPC has its own data mapping model, which covers about 90 percent of all schema types. Those that it does not cover are mapped to javax.xml.soap.SOAPElement.
o JAX-WS's data mapping model is JAXB. JAXB promises mappings for all XML schemas.

* The interface mapping model
JAX-WS's basic interface mapping model is not extensively different from JAX-RPC's; however:
o JAX-WS's model makes use of new Java 5.0 features.
o JAX-WS's model introduces asynchronous functionality.

* The dynamic programming model
o JAX-WS's dynamic client model is quite different from JAX-RPC's. Many of the changes acknowledge industry needs:
+ It introduces message-oriented functionality.
+ It introduces dynamic asynchronous functionality.
o JAX-WS also adds a dynamic server model, which JAX-RPC does not have.

* MTOM (Message Transmission Optimization Mechanism)
JAX-WS, via JAXB, adds support for MTOM, the new attachment specification. Microsoft never bought into the SOAP with Attachments specification; but it appears that everyone supports MTOM, so attachment interoperability should become a reality.

* The handler model
o The handler model has changed quite a bit from JAX-RPC to JAX-WS.
o JAX-RPC handlers rely on SAAJ 1.2. JAX-WS handlers rely on the new SAAJ 1.3 specification.

Additional reading list:

Developing Web Services at a Glance
http://java.sun.com/webservices/technologies/index.jsp#Core_Web_Services
Java API for XML-based RPC (JAX-RPC)
http://java.sun.com/developer/technicalArticles/xml/jaxrpc/

Reference:
http://java.sun.com/webservices/technologies/index.jsp#Core_Web_Services
http://www-128.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc.html
http://www.ibm.com/developerworks/webservices/library/ws-tip-jaxwsrpc2.html

Keywords: SAAJ, JAXB, SOAP, JAX-RPC, JAX-WS

Using Oracle RAC in OAS, Weblogic and Websphere

Oracle Application Server 10g R2 (OAS)

To enable the Fast Connection Failover mechanism, properties of "connectionCachingEnabled" and "fastConnectionFailoverEnabled" must be set to true on the (connection-factory) tag for an OracleDataSource object. the JDBC URL String must be set using the service name syntax. The service name specified on the connection URL is used to map the connection cache to the service.

Valid URL Usage

url="jdbc:oracle:oci:@TNS_ALIAS"

url="jdbc:oracle:oci:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"

url="jdbc:oracle:oci:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"

url = "jdbc:oracle:thin@//host:port/service_name"

url = "jdbc:oracle:thin@//cluster-alias:port/service_name"

url="jdbc:oracle:thin:@(DESCRIPTION=
(LOAD_BALANCE=on)
(ADDRESS=(PROTOCOL=TCP)(HOST=host1) (PORT=1521))
(ADDRESS=(PROTOCOL=TCP)(HOST=host2)(PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"

url = "jdbc:oracle:thin:@(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cluster_alias) (PORT=1521))
(CONNECT_DATA=(SERVICE_NAME=service_name)))"


If a SID is specified on the URL, when Fast Connection Failover is enabled, then an exception is thrown.

For more inforamtion, find them from links below:

http://download.oracle.com/docs/cd/B31017_01/web.1013/b28958/datasrc.htm#CHDEHFHE
http://download.oracle.com/docs/cd/B31017_01/core.1013/b28939/j2ee.htm#ASTED006
http://download.oracle.com/docs/cd/B31017_01/core.1013/b28939/security.htm#CDDGFADE


Weblogic

For how to use Oracle RAC DB with Weblogic application server, find the detail information from links below:

http://edocs.bea.com/wls/docs81/jdbc/oracle_rac.html
http://edocs.bea.com/platform/docs81/db_mgmt/oracle_rac.html

Websphere

For how to use Oracle RAC DB with Websphere application server, find the detail information from links below:

http://www.ibm.com/developerworks/websphere/techjournal/0710_barghouthi/0710_barghouthi.html
http://www.ibm.com/developerworks/websphere/techjournal/0706_banerjee/0706_banerjee.html