Web Services on Drugs

After a long time looking into Application development and UX widget, I am taking a fresh look at Web Services and I'll be starting to play with JSON and REST ideas. But first thing first, I have to refresh my IDE install on my MacBook Air - This is an easy 2 steps process: Download the latest version from OTN - Version 11.1.2.1.0 is the latest (Build 6081). Follow the steps from Shay's blog . The 1.7 GB file is not really lightweight on the WIFI network - it's better to have something else to do while waiting for the file to be ready, like learning about Oracle Enterprise Repository: Start with the overview, here . Next is the Java API References , a.k.a. the JavaDoc and the OSR online documentation . There is a lot of reading material, so you should be good for some time. You can also browse the Sample Code collections on OTN - My next stop is the Oracle CRM On Demand Sample Code . Here are 3 screen shoots that are important: Pop-up screen you wi...

As I am going through some more web-services related work, I came across two arguments to favor TodDown (or WSDL first) design pattern: 1) Including the partner link information that BPEL is expecting to find is trivial when you own the WSDL document. Try to get this added at the end of your document, using code first... <plnk:partnerLinkType name="StepTransform" xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"> <plnk:role name="XmlStepTransformPort"> <plnk:portType name="tns:XmlStepTransformPort"/> </plnk:role> </plnk:partnerLinkType> 2)Adding wsdl:documentation element within wsdl:portType/wsdl:operation will improve the end-user experience, and should be done always. It's like arguing against the value of javadoc on external APIs.... Today, the mood is WSDL first: Design, then code.

JAX-WS 2.1 is out. Here is a blog entry that will give you all the details you need: see the Fast & Furious . For me, it means it's time to give it a try and build some interface to PayPal Web services. The performance improvement seams to be worth a closer look. In my current project, I have start to look at performance between different implementations for a given Business Process, and I am getting to the point were the interpretation of the performance number can be swinged either way, just with a few tweaks on my dataset. Here is a tip I wanted to share with those that are trying to use SOAPElement --the JAX-RPC/SAAJ equivalent of the DOM Element-- when trying to work with large datagram that are handled as XML: Make sure you do not try to preserve whitespace. Otherwise, for every nested element you have (XMLElement) you will have an extra java object to carry the linefeed (an XMLText). It can add up very quick. The key is on line 193, in the code folowing code snippet: 189...

As part of my ongoing work on the SOA and SCA (Society of Confused Architects) bandwagon, I have a new not-so-easy error to explain and share with you. Here is how the error will reads from the client side, when using Oracle Web Services tech Stack on the 10gR3 releases: javax.xml.rpc.soap.SOAPFaultException: Caught exception while handling request: deserialization error: java.lang.IllegalArgumentException The SOAP response will look something like that: 1 <? xml version = '1.0' encoding = 'UTF-8' ?> 2 < env:Envelope xmlns:env = "http://schemas.xmlsoap.org/soap/envelope/" > 3 < env:Body > 4 < env:Fault > 5 < faultcode > env:Client </ faultcode > 6 < faultstring > Caught exception while handling request: deserialization 7 error: java.lang.IllegalArgumentException </ faultstring > 8 </ env:Fault > 9 </ env:Body > 10 <...

Here is an error that I have seen a few time in the past days, for which I have not find an easy way around. Just a user error, hard to catch... < env:Body > < env:Fault > < faultcode > env:Server< /faultcode> < faultstring > Internal Server Error (Caught exception while handling request: java.lang.reflect.UndeclaredThrowableException)< /faultstring> < /env:Fault> < /env:Body> In playing with the 'mapheaderstoparameters' option for the topDownAssemble target, I forgot to change the method signature on the implementation class before to repackage my application. When the code generated at deployement time does not match with the code packaged in your application, this is the error you may get. Until we get smarter in the code generation and have dynamic services with pre-deployment check, the best remains to make a knot on your handkerchief.