Monday, December 08, 2003


10g 9.0.4 Arrives

By the by ... you know how folks from Oracle keep on saying, "Any day now it will be released, really!"?  Well it's live now.  Oracle Application Server 10g is here

My recommendation ... try out file based clustering.  Here's the documentation: http://download-west.oracle.com/docs/cd/B10464_01/core.904/b10495/chapter4.htm#1019511.

Once you have two OracleAS instances (on Linux, once on the right Redhat release, my install of the Java edition took about 10 minutes to click "Next, Next, Next ..."), configuring a file based cluster, takes about, oh, 10 seconds - the engineers/PM's on this feature nailed it!

See



comment []
10:02:40 PM    

Web Services Tip: Untyped SOAP Requests

Here's a new feature in OC4J 9.0.4 that might help out in your Microsoft interoperability quest - support for untyped requests coming for J2EE Web services set up for rpc/encoded invocation. 

 I won't bother you with comment on larger interoperability issues - this article from Anish Karmarkar, Oracle's representative on the WS-I gives a great overview and industry direction in this space - rather I'll focus on this mundane issue because many folks run into it in their first interoperability tests between .NET and J2EE, typically from taking the default Web services configuration provided by both vendors.

So here goes - here's my class:

package com.rpc;
public class Greeting
{
public String sayHello(String p)
{
return "Hello: " + p;
}
}

Let's publish it as a Web service using JDeveloper as was done yesterday for the doc/literal example (see this same example I keep pointing you at on OTN for the JDeveloper wizard steps).  This time just take all the defaults and keep it as a rpc/encoded configuration (unlike yesterday's doc/literal entry).

A rpc/encoded SOAP message that will successfully invoke it looks as follows  (JDeveloper can generate a programmatic client from the Web service WSDL to generate this for you or Oracle Application Server automatically provides a pre-built Java client on its endpoint home page):

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHello xmlns:ns1="GreetingService" SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<p xsi:type="xsd:string">Mike</p>
</ns1:sayHello>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

and the response for that message:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloResponse xmlns:ns1="GreetingService" SOAP-ENV:encodingStyle="
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">Hello: Mike</return>
</ns1:sayHelloResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The problem is that Microsoft will, particularly with their SOAP 2.0 toolkit, normally sends untyped SOAP messages.  In an rpc/encoded world that can cause the receiving Web service to sieze up because it doesn't know the types.  Check out this far more erudite entry on the technical stuff going on under the covers.  An example untyped message for our example would be:

<?xml version = '1.0' encoding = 'UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="
http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHello xmlns:ns1="GreetingService">
<p>Mike</p>
</ns1:sayHello>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Note the lack of the string typing in the <p> parameter. In OC4J 9.0.2/9.0.3, the container would dutifully throw a fault unless you wrote a custom serializer for this SOAP message, telling the SOAP engine what the heck to do with the <p> parameter.

In OC4J 9.0.4, all you have to do is generate your web.xml with some extra bits to handle the untyped message. You can always read the documentation (see Chapter 12, Advanced Topics) or be lazy like me and simply add the right lines to your web.xml to handle the untyped messages.

I'll do it the lazy way.  Here is the web.xml configuration for the Web services servlet, before the change when only rpc/encoded messages are accepted:

<servlet>
<servlet-name>GreetingService</servlet-name>
<servlet-class>oracle.j2ee.ws.StatelessJavaRpcWebService</servlet-class>
<init-param>
<param-name>class-name</param-name>
<param-value>com.doc.Greeting</param-value>
</init-param>
<init-param>
<param-name>interface-name</param-name>
<param-value>com.doc.IGreetingService</param-value>
</init-param>
</servlet>

Add these lines:

<init-param>
<param-name>accept-untyped-request</param-name>
<param-value>true</param-value>
</init-param>

and your web.xml will look as follows:

<servlet>
<servlet-name>GreetingService</servlet-name>
<servlet-class>oracle.j2ee.ws.StatelessJavaRpcWebService</servlet-class>
<init-param>
<param-name>class-name</param-name>
<param-value>com.doc.Greeting</param-value>
</init-param>
<init-param>
<param-name>interface-name</param-name>
<param-value>com.doc.IGreetingService</param-value>
</init-param>
<init-param>
<param-name>accept-untyped-request</param-name>
<param-value>true</param-value>
</init-param>
</servlet>

Re-deploy, and with minimum effort, you have made your rpc/encoded Web service will now accept untyped requests. Check it out next time you run into one of those dreaded serialization problems when working with .NET Web service clients and OC4J 9.0.4 - it might just be your ticket out of what might have appeared to be a mess.



comment []
10:00:03 PM