As java developers, we think the “contract” is described by the java interface. But web services are language agnostic. We need to think beyond Java and Java interfaces. In web services the contract is described by the WSDL. Your services users could care less whether you implemented your web service using Axis, or Axis2, or JEE, or Xfire, etc.; your users only care about the WSDL.
Wy, exactly, do we "need" to think beyond Java interfaces? If, as is the case, with the JAX-WS and JAX-B annotations you can have the same level of specificity in your Java interfaces that you can have in WSDL, and those interfaces are correctly turned into workable WSDL, what is the difference if I write the "contract" in Java or in WSDL?
Moreover, working in WSDL -- or more specificially Schema -- tends to be a recipe for shooting youself in the foot. When overly "thinking" in XML, it is WAY WAY too easy to use XML idioms that are not or are poorly supporing in Java, C#, or any of the other OOP languages that clients will be attempting to use with your service. If you start from Java, that is almost assuredly a non issue.
Reuse of existing schemas is a good idea, but I don't see how it is necessarily precluded by any of this, though. That is just an object model that can easily be imported into your project as a one-way import because they implicitly WONT change.
The tools need to go beyond Java-to-Wsdl, to support WSDL to Java, or a meet in the middle approach.
I think the JAX-B/JAX-WS annotations are EXACTLY that meet in the middle approach. They let you have all the additional specificity from Schema without having to work with a PITA one-way code generation system. Moreover, since they are standard, you can easily switch between Glasshfish, Xfire and the plain old Mustang JRE. |
java.net RSS Feeds
