This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
In Java petstore 1.3.2 version the Admin swing gui application connects to EJB Tier via Web Tier and with http post and passes plain XML over http. It also receives the same (i.e plain XML over http ) . So, parsing the XML and converting the java objects back to XML is there in both sides. [ I am talking about HttpPostPetStoreProxy.java ].
In Java petstore 1.3.1 version the Admin swing gui application connects to EJB Tier via Web Tier but it uses JAX-RPC (i.e WebServices ). [I am talking about WebServicePetStoreProxy.java ]
So, I have 2 questions. ======================= (1) Why in 1.3.2 which is a later version of Petstore than 1.3.1 the WebService approach has been taken out and old "plain XML over http" has been taken ? In this respect someone has told me that Sun has moved it WebServices related samples to Adventure Builder. Is it true ? If that is the reason to taken away the WebServices approach from Petstore demo then I think it is not good. Is there any architectural advantage using "plain XML over http" instead of WebServices here?
(2) What is the reason Sun has taken this Swing Client --> Web Tier --> EJB Tier approach ? Why not Swing Client -> EJB Tier ( using RMI-IIOP not EJB WebService Endpoint ). It should be faster ,no XML parsing will be there . ( If we use WebServices still the XML to object conversion will happen internally]. Or Marshalling and demarshalling of RMI-IIOP request is more expensive than WebService XML parsing/simple XML parsing ?
Has sun provided any good reason to choose this path ? Actually I have not found it in the document.
Is there any architectural advantage using "plain XML over http" instead of WebServices here?
Although I can't speak for authors of Petstore, architecturally WebServices is more expensive than XML-RPC because of the overheads in publish-find-bind cycles. A service has to publish it self in a registry and the client(s) will have to query the registry and bind to the service.
XML-RPC just gets about two layes below the WS protocol stack and talks to the service end point directly. Therefore it not only performs better, but also reduces book-keeping activities.
This is my analysis, but they may beg to differ
Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Joined: Jun 20, 2004
In case of WebService also, publishing in a registry and binding it is not an mandatory action. If u know the end-point you can bind and call the Service. Isn't it ?
Any of the JAX-RPC Client types ( i.e static stub, dynamic proxy or DII ) can bind and call an endpoint without finding it in registry.
Then the binding and finding overhead will not be there. If u use Static Stub then most of the tools generate the necessary classes from the WSDL. So, the developer deals with only mainly with POJOs . Life is simpler .Isn't it ?