Sunday, June 27, 2010
Saturday, June 26, 2010
WebServices with CXF - Testing using JUnit
As you know JUnit is for Testing, so basically I'm going to test my running/deployed WebApplication by declaring this Test Cases:
This one is just a TestCase which tests my Spring Bean ServiceAnd this fellow tests our WebService
As you can see, we need to link using our Service Interface (LibraryService.class) to this JaxWsProxyFactoryBean instance
That was easy! Isn't it???WebServices with CXF - Configuration files III
Now I'll cover my Apache CXF configuration file
As I said before this is not rocket science. It follows the same logic used in every Spring configuration file, everything is based on Beans tags
If you remember my serviceApplicationContext, I declared a Bean called LibraryService
Well, we're going to make reference to this particular Bean on our CXF configuration file, so we can expose it (We already changed our Interface & Implementation using annotations)
Now if you analyze carefully my CXF configuration file, this section links my Spring Bean (Service) with my endpoint on CXF through implementor & implementorClass attributes, which basically link my Java Code (implementorClass) and my Spring Bean (implementor);
The only thing you must add is "#" character before Spring's Bean name: #LibraryService
Finally, I'm using another attribute called address to declare the address for this WebService, by declaring it as address="/LibraryService", this will be my URI for this WebService: http://localhost:8080/little-library-lite/services/LibraryService
Why /services/LibraryService?? I declared on my web.xml that URL Pattern.
In my next and last entry I'll test this WebService using JUnit, if you want to see the WSDL file for all your available WebServices, you can do it by going to http://localhost:8080/little-library-lite/services
There you'll see a list of available WebServices and by clicking them you'll see each one's WSDL
Sunday, June 13, 2010
WebServices with CXF - Configuration files II
I'll just include my Spring configuration files.
Why files? -I though Spring only needs an applicationConext??? Well... Because I prefer to split configuration files according to it's purpose:
- One will have everything related to the Persistence layer
- and the second one will have all my Business layer -services
serviceApplicationContext
When I met Annotations, I just felt in love with them, because one of the main advantages you gain is small configuration files.
On my next entry I'll cover my Apache CXF configuration file and how it fits.
WebServices with CXF - Configuration files I
I'll show 2 basic configuration files: web.xml & my hibernate configuration file (mapping.cfg.xml)
As you noticed I'm using Spring MVC (see webApplicationServlet), but for now let's focus on Spring and CXF:
My 3 main configuration files are listed here, where the 3rd one is for CXF (really obvious file name) and to enable Apache CXF is so simple, Did you remember XFire?
Now let's see my (small) Hibernate configuration file (which I just called mapping.cfg.xml) Instead of using resource=, I'm using class=, because I don't have any hbm.xml file. I'm mapping directly to the class (due to Java Annotations, my mapping it was declared on each POJO).
Now what do you think? Is not as complex as looks like.
WebServices with CXF - Integrating with CXF II
This is going to be a really small entry, because we're going to finish with my ServiceImplementation.
On the next entries we'll discuss configuration files & finally we'll see everything working (Obviously I'll need to test it).
But before that, let's analyze my implementation:
As I've been doing I'm using a lot of WebServices Annotations
What I did???
- Define service name of the Web Service
- Declare the complete name of the service endpoint interface defining the service's abstract Web Service contract (My Interface)
- And set my targetNamespace: the targetNamespace is used for the namespace for the wsdl:portType (and associated XML elements)
WebServices with CXF - Integrating with CXF I
As I said before on Service Interface & Implementation, somehow we'll have to retake that code to implement CXF, and that's what we're going to do.
I want to expose as WebService my LibraryService and as WebMethods these methods:
- public List
getAllAuthors() - public List
getAllBooks() - public List
getAllEditors() - public List
getAllOnlyEditors() - public BookDTO getBook(Integer bookId)
Ok, everything looks nice, but what happens if my client is asking for a "subService" (WebMethod) which returns AllAuthors, but he/she doesn't expect a WebMethod called getAuthors, retrieveAuthors or returnAuthors.What can we do??? -We're done with our coding and that method (getAllAuthors) is being used in many places in our App.
Are you going to rename your code just because your client doesn't like your naming convention???. Later you'll see my answer. Let's modify my code, first, Interface then Implementation;
By adding Java WebServices API Annotations And don't forget for every method we must declare it like a WebMethod In this case I'm declaring a couple of additional attributes, which basically let me give another name to WebMethod, a different name to my original Java Method - this will be the name available on my WebService/WebMethod (this is the second option for my client)
And finally, what can I do if have logic on this interface that I don't want to make it public (available as WebMethod)???
This is the answer: "Just exclude it"