SOA / Web Services / Java

A Technology Blog

Archive for September, 2008

Oracle in Middleware

Posted by Vivek on September 21, 2008

Oracle has an array of products for building a strong middleware. Oracle has done everything it can to provide integration solutions to its customers. But not all are happy with these solutions. You can see some curt replies on forums or ask any oracle developer.

If you complain about deployment and usabilities of Oracle Enterprise software, you just know the tip of an iceberg.

When you are (God forbids) unlucky enough to get hired as a Senior Software Developer for Oracle, you will see the full horrible iceberg.

First of all, their enterprise software architecture is bad, and based on all the principles of “How to write slow and unreliable Java code”. They use EJB, RMI and all distributed technologies unnecessarily, for no particular reason, except to amuse themselves, and torture their customers.

Second of all, a lot of Oracle enterprise applications claim to be J2EE applications, but contain a lot of Active X and proprietary javascript code for Internet Explorer, so they run only with Internet Explorer.

Third of all, they have very bad intergration strategy between Oracle products, so some Oacle products run very well (well here means relatively less bugs) with every other Application Server, except Oracle Application Server 😉

Forth of all, they don’t have good practice about Refactoring, Code review, Test first Development, only have theory, so the quality of Oracle’s code is terrible.

Fifth of all, they have a very funny build process for J2EE application, which involves 10 different tools, from simple javac to Ant to Unix shell sh, m4 interepreter to Cruise Control, perl script, yapp and God know what else. But I swear that one day I really counted them, and there were 10 different things in all. Why the hell they cannot use Ant and Cruise Control, or if they must, use either Perl or Sh script? But they use 10 different things. Thanks God they don’t include C# and Visual Basic into the build process.

Sixth of all, they don’t have incremental build for some enterprise applications, so each time a developer change some thing in one file, he has to build the whole thing, and deploy the whole J2EE app again.

Seventh of all, Oracle Application Server is the second worst J2EE application server in the whole industry. (The worst is IBM Websphere). Even some Oracle enterprise products cannot be deployed reliably on OAS, while they can be deployed fairly easy on Weblogic or any other things. The performance of OAS is terribly bad, although they advertise something else on Oracle Website. And the Management Console is a typical study case about “How to design bad User Interface”.

The last, but not least, that the team spririt in Oracle development team sucks. I don’t even want to go into the details.

Of all other things, Oracle Collaboration Suite, Oracle iProcurement and Oracle HR tools …, I think Oracle produces those kinds of software to take revenge on their customers, make their lives miserable. There is nothing that is more difficult and inconvenient to use than those Oracle hacky wacky products.

So except database which has been developed since Larry Ellison’s time, all other Oracle products suck.

Posted in Middleware, oracle | Tagged: , , , | 1 Comment »

RPC-style vs Document-Style Web Service

Posted by Vivek on September 12, 2008

There has been lot of confusion on which style of web service is used but It is always recommended to use a Document-style webservice to realize SOA.

RPC style web service:
These web services are easier to create and are usually synchronous in nature.
The responsibility of marshalling and de marshalling lays with SOAP engine, This leads to significant performance degradations when message passed to an operation is large or complex.
Since large sized messages lead to performance degradation in RPC style web service, they are not suitable for implementing coarse grained functionality requiring information messages having more number of fields.
However fine grained functionalities is better implemented by RPC style web services.
Document style web service:
Document style web services are more time consuming to create, as it is the onus of the service to create the required objects from XML document.
These web services can consume large sized documents without any significant drop in performance as there are no overheads of marshalling and de marshalling associated with SOAP engine.
Document style web services are ideal for representing coarse rained functionality as a single large sized  document can be used to transfer information required to implement a business functionality.
Document style web service are primarily used for implementing asynchronous service.

RPC encoded web services are easiest  create but offers least control in terms of usage of custom data types, validation and interoperability.
RPC encoded web service are slower in performance because of added overheads of marshalling and un marshalling.
Document literal web services are harder to create but scores higher in all the above metrics and this is one of the reasons WS –I basic profile encourages the usage of document literal web services.

Document style web services are better suited for defining custom data types as they are not constrained by the usage of a particular encoding style. Document –literal web services offers the best performance and RPC –encoded web services offers the least performance as in document-literal web service overheads of marshalling and un marshalling no longer lies with SOAP engine. In a document –literal web service alternative techniques such as  SAX based parsing or custom data binding tool like XML beans, castor can be used.In case SOAP engine does not maintain state a document –literal web service can be used to carry state related data in the document. While using RPC –encoded web service often platform specific data structures are exposed in WSDL, which might not be supported by other platforms.

Posted in Web Services | Tagged: , , , , , | 10 Comments »