Grails,CXF plugin and .NET

As promised here's a follow up on the WebService interoperability between Grails using Apache CXF plugin and .NET.

First let's create a simple example project and install the grails-cxf plugin:

grails create-app example
grails install-plugin cxf

Next let's create a service:

grails create-service example

This has created 2 files:

grails-app/services/example/ExampleService.groovy
and
test/unit/example/ExampleServiceTests.groovy

The first one is the one we need to modify so let's get to it:

package example

import javax.jws.*

@WebService(serviceName="ExampleService", name="Example")
class ExampleService {

    static expose = [ 'cxfjax' ]

    @WebMethod(operationName="sayHello")
    String sayHello(@WebParam(name="name") String name) {
        "Hello ${name}!"
    }
}

As you can see I've added every possible bit of information to customize the generated WSDL. With all that in place we can get the description of this service (WSDL) at http://localhost:8080/example/services/example?wsdl. Let's use that to create a .NET client. This time from command-line:

SET PATH=%PATH%;"C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin"
wsdl.exe http://localhost:8080/example/services/example?wsdl

In the first line we're expanding the system path so that all the tools are available from anywhere. In the second line we're generating a client for the web service we've created in Grails. Simple enough, right?

Let's create a simple console application and use this newly generated client:

Program.cs:
using System;

public class Progra {
    public static void Main(String[] args) {
        Console.WriteLine(new ExampleService().sayHello("John"));
    }
}

Let's compile everything from command-line:

set PATH=%PATH%;C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319
csc *.cs

Again, no magic here. Once you've compiled everything run the application and bum! Everything works as expected :)
My guess is that CXF plugin didn't work just right out of the box because of some problems with default naming that CXF is using when auto-generating WSDL. With all the annotations in place everything seems to be working just fine.

I hope this will help someone. In case you'd like to fiddle with it yourself here's the example. in src/csharp you'll find the sources for the client along with a batch file to compile them.

Unfortunately when it comes to a more advanced scenario, like for example returning an array of domain objects from a service method the CXF plugin still fails to produce good enough WSDL to work with .NET. This is the case where XFire plugin shines best!

FYI: the same trick does not work with Axis2 plugin. The naming is all whacko. Things like this$dist$set$2 and urn:this$dist$get$2 hurt the WSDL code generator so much it spits nothing out but a load of warnings.

Have fun!

JavaEE 6 + Metro WebServices

Following the post about WebServices with Grails here's a short summary of my attempt to make Java's EE 6 WebServices work with .NET. It's quite a basic example but as history shows even the simplest examples might not work (as it is the case with Axis2).

Setup

So here's a definition of a Hello WebService:

package com.aplaline.integration.webservices;

import javax.jws.*;

@WebService(name="Hello", serviceName="HelloService")
public class HelloService {
    @WebMethod
    public String sayHello(@WebParam(name="name") String name) {
        return "Hello " + name + "!";
    }
}

As you can see there's no magic here. Let's see how NetBeans' configuration option look like for this guy:



Surprisingly enough there's mentioning of a .NET version! Let's see how this works. I'll be using VWD 2008 SP1 to test it:



Let's add a web reference to this web site:



Now let's create a blank Default.aspx page and add some code to call that web service:

Default.aspx:
[...]
<form id="form1" runat="server">
<div>
  <table>
    <tr>
      <td><asp:Label ID="Label1" runat="server" Text="Enter name" /></td>
      <td><asp:TextBox ID="input" runat="server" /></td>
    </tr>
    <tr>
      <td align="right" colspan="2"><asp:Button ID="Button1" runat="server" 
          onclick="Button1_Click" Text="Click me" /></td>
    </tr>
    <tr>
      <td colspan="2"><asp:Label ID="output" runat="server" /></td>
    </tr>
  </table>
</div>
</form>
[...]

Default.aspx.cs:
[...]
    protected void Button1_Click(object sender, EventArgs e)
    {
        output.Text = new localhost.HelloService().sayHello(input.Text);
    }
[...]

Results

As it turns out it works out of the box properly.



For the kicks of it let's try and consume the same web service from PHP 5.3:

<?php
$client = new SoapClient("http://localhost:8080/WebServices/HelloService?wsdl");
var_dump($client->sayHello(array("name" => "John")));
>

There's a little inconvenience when calling web services from PHP in that the parameters need to be passed as an array instead of simply specifying their value. In the long run it's kind of healthy because different webservice stacks tend to handle things differently and putting the proper context into the whole thing.



This is the first pleasant surprise since I've started to work on the web-service interoperability between .NET and Java. It looks like things are definitely going in the right direction :)

Here's the Java project for reference.
Here's the .NET website for reference.

Have fun!

Grails, WebServices and .NET interoperability

This is just a quick note for all those that have tried to interop between Grails and .NET using Apache CXF or Apache Axis2 and failed miserably:

Don't use those libraries - instead use the good old grails-xfire plugin. This guy just works out of the box with .NET 3.5 and 4.0. In C# just add a web reference and you're all set!

More on this topic soon - stay tuned!

Creating a blog web application - part 1

Hi,

Today I'm starting a series of posts that will describe the process of creating a blog web application.

First of all we'll have to gather some high-level requirements and define the technologies that we'll use to write this web application.

Let's start with the requirements. As you'll see they are pretty simple as the application we're going to write is not a very fancy thing.

Blog Web Application Requirements.

1. Everyone must be able to view the list of posts along with comments.


2. Owner of this blog will have the possibility to add new posts.


3. Everyone must be able to post comments to posts added by blog owner.


4. Retrieve the list of blog entries as RSS feed.


5. Add posts using a WebService interface.

That's it. Pretty simple, right? Now since this is going to be a full-blown application we're going to need to make some decisions about the technology used to persist the data, manipulate them and finally to visualize them in a web browser.

For the purpose of this tutorial I've selected the following parts:

• Visual Web Developer 2008 SP1 Express Edition IDE - free, powerful, ergonomic, awesome tool


• For the main framework we're going to use I've selected ASP.NET MVC framework because of its vast control over every single part of the application. It gives a clean separation of concerns and enables testability as well so it's a really nice thing.


• As a presentation engine we're going to use the standard ASPX engine as it comes for free with the ASP.NET MVC.


• We'll follow the View-Controller-Service-DAO-Database execution scheme. That way every single component of the application will have its clean task to perform and testing it will be a breeze.


• For database access we'll use NHibernate because of its independence of the actual RDBMS. I realize that most of you will use Microsoft SQL Server and thus the LINQ-to-SQL framework but this one option is already well covered in a number of tutorials and I wanted to do something else.


• For the actual RDBMS we'll use Firebird. The reason behind this choice is quite simple: first Firebird has an option to run as an embedded database as well as a full-blown database engine. Secondly I've used Firebird for a number of projects already and I'm very pleased with the performance of this database. And third, it's licensing model allows one to use it in any kind of application (commercial and open source)


• Obviously we're going to need some IoC engine. As you'll see we'll have the luxury of selecting any IoC framework we want, ranging from Spring.NET, Castle, StructureMap, NInject, Autofac to Microsoft's Unity Application Block. I personally prefer Unity for its attribute-driven control over injected dependencies but Spring.NET is going to be an option we'll discuss as well.


• And last but definitely not least we're going to follow the Test-Driven Development style. For that we'll use NUnit as it contains all of the features we're going to need ranging from a command-line xslt-driven output runner to simple mock framework. It has been around for a long time now and despite of some shortcomings and differences with other unit-testing frameworks (like JUnit or DUnit to name a few) it is still my favorite one.

Let me make a note on that last point: I'm definitely not an expert on TDD. You might find that throughout the project I'm not exactly following some practices or you might know some better option to perform some steps. Finally you might skip the testing part all along if you want to - whatever makes you happy.

That's it for now. In the next part we'll start off with creating the necessary projects and writing some code that will make up our controllers.

Stay tuned!