![]() |
Site Archive (Complete) | |||
|
ABOUT US |
CONTACT |
ADVERTISE |
SUBSCRIBE |
SOURCE CODE |
CURRENT PRINT ISSUE |
NEWSLETTERS
|
RESOURCES
|
BLOGS
|
PODCASTS
|
CAREERS
|
||||
May 25, 2007
Java Web Services and the SOA-J FrameworkJohn Dorsey
Using a WSDL-centric approach to Java web services decreases complexity, especially when working with legacy Java applications
DDJ: We're speaking to Mark Hansen, the founder of Javector Software and the author of SOA Using Java Web Services. Mark, your book introduced a web-services tool called SOA-J. What is SOA-J and how does it related to Java's Jax-WS?
MH: SOA-J is an application framework for doing what I call "WSDL-centric" Java web services and programming. It allows you to essentially edit a WSDL to create a Java web service — the reverse from the way that Java EE 5 web services work; the way that Jax-WS works, where essentially you start with a class and you annotate it to create a web service, what I call a "Java-centric" approach. SOA-J kind of stands that on its head. You start from the XML and the WSDL description and use that to get to the Java. You map the WSDL and the XML that is the language of SOA to the Java classes. If you've got all these applications that you've built over the years using Java, and now you've got to start to enable them to interact with web services. You may be exchanging purchase orders from customers over the Internet; you may be integrating with a business partner over ebXML. Somehow you've got to map your existing Java to the XML messages that get passed back and forth, and the web services.
DDJ: So if you start in XML, you don't have to translate from Java into XML and back to Java.
MH: Its saying, "Let Java be the backend processing, and let's treat XML and the description language for web services, which is WSDL, let's actually try to do the programming in that." It's a more natural process; it's a lot easier to do things that way once you're familiar with XML. If you're not, if you're a Java programmer, if you don't know XML, it may feel a little bit awkward at first. You know, for developers that are committed to web services, and familiar with XML, there are a lot of drawbacks to some of the Java EE approaches, which I show how to work around in the book. SOA-J is kind of one approach.
DDJ: So how does SOA-J work with Jax-WS?
MH: SOA-J is built on top of Jax-WS. You can think of Jax-WS as a toolkit, and SOA-J as an application framework on top of the toolkit, much like servlets is a toolkit, and Struts is an application framework that runs on top of the servlets. Same thing with SOA-J: It's a lot easier to set up web services in SOA-J than it is to program directly in Jax-WS.
The problem is difficult to solve in the SOA space for Java programmers. You know, it's a mapping problem, XML to Java. You may have a purchase order object you've used for years, and if you take Jax-WS and just applied the standard Jax-WS mappings to that, it will create a purchase order XML document for you, but it may not be the same structure as the purchase order document that your business partners are using. So then you have the problem of how do you map out one to the other? So what SOA-J does is it gives you the tools so that your Java purchase order looks like the standard purchase order out on the Internet, without having to go through all of that sort of translating one bit-mapping.
DDJ: Is SOA-J free or a commercial product? Where can we learn more about it?
MH: SOA-J is an open-source project that's hosted at Sourceforge, at sourceforge.net/projects/soa-j. Commercially, the code can be licensed, and is available under the GPL but it's a dual-license.
|
|
||||||||||||||||||||||||||
|
|