Discussions

News: Webservices with Spring, XFire and jsr181

  1. Marc Logemann has written up "Webservices with Spring, XFire and jsr181," a walkthrough of deploying web services with Spring and XFire that are compliant with the Web Services Metadata JSR, JSR-181. After defining the web service interface and deploying the war, he says, And what more? Nothing. Thats it. Deploy and you can test your webservice by using XFire..."
    Just wanted to share my experiences i made yesterday while implementing webservices via XFire. Since i migrated to Java5 yesterday, i thought its a good idea to use its strengths in form of using annotations for webservices. Because i am using Spring, XFire was an obvious choice because of its neat integration into Spring. So take a seat and see yourself how easy it is to create webservices with this combination.
    He then walks through the configuration files, adding the XFire configuration to Spring, and then defining the service as well as an interface for it. He also shows the client code for using the service. It's a nice example of a simple web service deployment. The statement of "What more? Nothing." is very telling, and probably the way web services should be exposed.

    Threaded Messages (11)

  2. Thanks for posting this, I'm sure it will be helpful. I had the same experience as the poster and ended up with pretty much the same configuration. About the easiest way to expose classes as web-services and they perform well too.
    You dont need to have an interface for it but its a better programming style, so we create also an interface. If you dont want to do it, you can put all the other annotations also in the implementation class.
    The interface doesn't hurt but I don't think it is needed for good design: With web-services, I'd consider WSDL to be the "interface". Whether it is generated by a SOAP framework or hand written, the WSDL is the service contract. I'd suggest keeping your service endpoint classes very slim on business functionality and coding them with generally coarse method signatures. Think of them as a facade that dispatches to other POJOS to do the work. This is similar to the good old stateless-session bean as facade pattern and allows for the same swapping out of implementation functionality without breaking the contract. Actually, if you used a xdoclet back in the day for generating your SS bean remote interfaces and configuration I think you'd see a high similarity to JSR-181 and web service design strategies. If I follow the above guidelines there is no real benefit that I can see for creating a separate interface for the endpoint classes. ________________________ George Coller DevilElephant
  3. Good advice[ Go to top ]

    With web-services, I'd consider WSDL to be the "interface". Whether it is generated by a SOAP framework or hand written, the WSDL is the service contract.
    I tend to go one step further, and consider not only the WSDL but also any implementation classes it defines to be 'part of the interface'. Basically, a good rule is "if it's defined in the WSDL/XSD it shouldn't be directly manipulated by business logic".
    I'd suggest keeping your service endpoint classes very slim on business functionality and coding them with generally coarse method signatures. Think of them as a facade that dispatches to other POJOS to do the work.
    Yep. And, for additional insulation, avoid passing the data classes defined in the 'interface' (see above) directly to your business-tier POJO's. This decouples your business tier from the interface contract for any specific service implementation.
  4. OO Mapper[ Go to top ]

    In our project we use WSDL first webservices and use the services as facdes to the underlying business pojos. So my question is is there any way to automate the conversion of interface objects to internal bussiness objects. Object-to-Object mapper.
  5. Re: OO Mapper[ Go to top ]

    Try Dozer for this. I think it's got some promise... http://dozer.sourceforge.net
  6. Re: OO Mapper[ Go to top ]

    I've used Jakarta Commons BeanUtils for this quite successfully. There's an object in there called org.apache.commons.beanutils.PropertyUtilsBean. I believe it uses reflection to snap up the named getters and setters and matches between the two objects, even if it's of a different type. Usage is: PropertyUtilsBean bean = new PropertyUtilsBean(); bean.copyProperties( newObject, oldObject ); P.S. Even though DTO's are a "bad smell", it seems like a valuable pattern to add flexibility to an application. I'd be interested, what does everyone else use to map between XFire model objects and application model objects, or is everyone just mapping directly to the application model?
  7. Mapping[ Go to top ]

    This is really the same issue faced when you put objects into relational databases. I use property utils but went a step further and defined an interface for objects that do the mapping. I called it a BeanStocker thinking of the guys that work in grocery stores at night stocking the shelves. It's got one method that copies things from one object to another. It is responsible for moving properties and anything that implies. For example, I use the same one to copy both directions if there are classes that are used for things coming into the web service and things going back out of it. In that case, it has to figure out which way it is going and react appropriately. I have Spring inject an object that implements that interface into places that need to convert the web service transfer objects to the business objects. Then I wrote a simple BeanStocker that just copies all the similarly named properties with PropertyUtils from commons. When I need something fancier, I whip up a special version and have Spring inject that one instead of the generic one. For example, I have one that will notice arrays with the same name in the two classes. If found it creates a similarly sized array in the destination object and fills it in with new instances of whatever is the right class and then uses another BeanStocker that is injected into it to copy the array contents, item by item. A special one could convert dates to a different time zone as it copies. Or it could map several fields into a single one. Its all the beauty of interfaces, facilitated by IOC.
  8. I have pretty much similar write up on Xfire in my blog. In addition it includes how to intercept the SOAP calls with EJB and sample HTTP security setup. http://www.tsolak.com/?p=10 Hope this shameless post will be usefull for some.
  9. Also consider glassfish[ Go to top ]

    Hi, I liked the article and have two question: is it possible to expose the annotated webservices as RPC/Encoded with XFire? Is it possible to use XFire without Spring? Furtermore, readers who are interested should also consider glassfish. In JEE5 (if you are willing to drop Spring) you do not need any XML plumbing anymore. You just use the annotations on a POJO and it gets exposed as web service automatically. No need to write/adapt any descriptor file, not even web.xml. Upon deployment your annotated class will gets scanned and deployed automatically. The problem for me at this moment, is that these webservices only get exposed as DOC/Literal. Cheers, Franck
  10. I liked the article and have two question: is it possible to expose the annotated web-services as RPC/Encoded with XFire?
    I don't 100% know what you are asking here (RPC/Encoded) but XFire 's annotations implement the JSR-181 standard. So I think yes, SOAP RPC is part of the implementation
    Is it possible to use XFire without Spring?
    Yes - stand-alone XFire is simple . It has a dependency on the XBean framework so it's stand-alone configuration looks a lot like Spring anyway. I'd suggest just downloading it and looking at the demos. I'm not sure how much simpler a SOAP framework could get.
    In JEE5 (if you are willing to drop Spring) you do not need any XML plumbing anymore. You just use the annotations on a POJO and it gets exposed as web service automatically. No need to write/adapt any descriptor file, not even web.xml. Upon deployment your annotated class will gets scanned and deployed automatically.

    The problem for me at this moment, is that these web-services only get exposed as DOC/Literal.
    Ok, I think you are getting your standards/frameworks a bit mixed up/intertwined. JEE5 defines annotations via the JSR-181 standard. Xfire is just one implementation of that standard. If you read the JSR-181 spec (not too bad actually) you have full control over the doc/literal or RPC switches for the generated WSDL. The spec can be downloaded here: http://www.jcp.org/en/jsr/detail?id=181 Honest, it isn't that big (50 pages but with lots of tables and examples) and really explains how to use JSR-181 well. Xfire does not need Spring. But if you are already using Spring it is nice to know that it is easily integrated with Spring. Spring isn't incompatible with JEE5 either. Of course I'm assuming when we are talking Spring here we are only talking about the configuration framework part of Spring. Also you should note that XFire does not need to be configured via 181 but can expose classes using some simple XML configuration. They even have a javadoc markup config so that 181-like configuration can be done with JDK-1.4, which does not support annotations. The one argument I can see being made is should JSR-181 even exist? Shouldn't we all be doing WSDL first web services? I'd say nope. JSR-181 is just another tool and for many developers and projects it is just what the doctor ordered for quick and easy web-services. Proper architecture and design of your system is still left as an exercise to the reader. Sigh, when will they automate that? George Coller DevilElephant
  11. Xfire and RPC/Encoded[ Go to top ]

    I liked the article and have two question: is it possible to expose the annotated web-services as RPC/Encoded with XFire?

    I don't 100% know what you are asking here (RPC/Encoded) but XFire 's annotations implement the JSR-181 standard. So I think yes, SOAP RPC is part of the implementation

    XFire does not support RPC/Encoded. That's a good thing actually, because RPC/Encoded is sort of forbidden by the WS-Interoperability guys.
  12. Re: Xfire and RPC/Encoded[ Go to top ]

    XFire does not support RPC/Encoded. That's a good thing actually, because RPC/Encoded is sort of forbidden by the WS-Interoperability guys.
    You are right - thanks for making that clear. I'm not sure if it is a good thing or not - especially from the XFire client side. If it is part of the standard that other web-services may be using (Google API for one) then the client should be able to handle it. WS-I or not. Of course we're talking about open source here so someone with some knowledge on this who cared could just submit the implementation. Unfortunately it isn't me. _____________ George Coller DevilElephant