I am tasked to create a web service that sits in the Weblogic server. I have a few questions after doing some readings:
1. Does the web service that sits on the Weblogic server use the weblogic's stub generator or I am free to use any other code generator like from JWSDP?
2. If I adhere to the SOAP messaging style, interoperability will not be an issue. If not, what do I have to make sure that the service can be called by other systems?
I hope there is someone out there who can help me by answering questions. Might sound studpid but I really want to learn.
Joined: Aug 19, 2005
Originally posted by Patricia Teoh: 1. Does the web service that sits on the Weblogic server use the weblogic's stub generator or I am free to use any other code generator like from JWSDP?
WebLogic has been supporting web services since version 6.1 - however each version's support for web services is quite different. WebLogic 8.1 web services weren't compliant with the (JAX-RPC based) J2EE 1.4 web services specification which lead some teams to use other toolkits like Axis 1.x or JWSDP 1.x despite the many difficulties that were encountered in doing so. The current generation of Java-based (Java EE 5, Java SE 6) web service toolkits tend to be JAX-WS based (often requiring JDK 5 at a minimum - Axis2 claims to only use JDK 1.4, though that may change once they start to use Java annotations).
2. If I adhere to the SOAP messaging style, interoperability will not be an issue.
You can't assume that. Earlier generations of SOAP web service toolkits (including the earlier WebLogic platforms) made heavy use of the RPC/encoded mode of messaging which was notorious for interoperability problems. This is why currently document-oriented web services which use the document/literal mode of messaging are considered a best practice for SOAP web services. However even then use of the more advanced features of XML Schema in your WSDL like enumerations, inheritance and polymorphism can create problems with "less capable" clients.
Within service-orientation, solution logic designed as services is intentionally positioned as enterprise resources and sometimes even enterprise-wide resources. This enterprise-centric perspective is one of the main reasons that only and subset of object-orientation principles was carried over into service-orientation.
The object-orientation design paradigm is comprised of a rich set of fundamental and supplemental design principles that structure and organize object logic within and across classes. Several of these principles have been carried over into service-orientation, while others have been omitted entirely.
[ May 07, 2008: Message edited by: Peer Reynders ]