Create a simple Java client to call that web service. Using the default Java SE 7u2 SDK + runtime downloadable from Oracle, you run wsimport to import the service WSDL and generate proxy classes. You write a little code to instantiate the service class and call the service, run the app, and see the output from the successful web service call. Done! Well, not exactly.

When you run the Java client console app, the calls to the web service work but are accompanied by rather nasty sounding warnings about unknown policy requirements.

Jan 04, 2012 12:10:46 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0075: Policy assertion "{http://www.w3.org/2006/05/addressing/wsdl}UsingAddressing" was evaluated as "UNKNOWN".
Jan 04, 2012 12:10:46 PM [com.sun.xml.internal.ws.policy.EffectiveAlternativeSelector] selectAlternatives
WARNING: WSP0019: Suboptimal policy alternative selected on the client side with fitness "UNKNOWN"

How do we get rid of those warnings? There are certainly ways to suppress warning reports, but that’s not the right solution. The better question is how do we resolve the issue reported in the warning?

After a great deal of digging around, here’s what I’ve found:

1. WCF defaults to placing a wsaw:UsingAddressing WS-Policy assertion in your web service WSDL.
2. wsaw:UsingAddressing is not actually part of any SOAP standard, it’s some sort of WSDL extension to cover the gap until an official SOAP WS-Policy standard could be defined later.
3. Microsoft WCF supports wsaw:UsingAddressing.
4. Java’s JAX-WS reference implementation web service core framework (JAX-WS RI 2.2.4-b01) bundled with the JDK does not support wsaw:UsingAddressing. The rationalization seems to be that wsaw:UsingAddressing isn’t part of the WS-Policy spec, so “not our problem”. JAX-WS RI supports wsam:Addressing from the official WS-Policy spec.
5. This isn’t just Java folks thumbing their noses at Microsoft. This also causes interop problems with Java web service frameworks that support and use wsaw:UsingAddressing.
6. Java Metro is another web service framework, and one which does support wsaw:UsingAddressing. Metro is the result of Sun and Microsoft working together to resolve cross-platform web service interop issues.
7. Metro is easy enough to download, but how do you use it? Documentation is all about how to install Metro into an application server environment. Many app developers have asked “How do I use Metro in my Java client?”

As it turns out, Metro appears to do all of its magic at runtime. There is no IDE integration at all. All you need to do is reference the Metro .jar files in your Java project and the WS-Policy warnings will go away.

In the NetBeans IDE, this means adding each of the .jar files from the Metro/lib directory to the Libraries node in your Java project. Make sure they appear before the JDK reference. Make sure you select the actual .jar files, not just the Metro/lib directory.

In the IntelliJ IDE, this means:

1. Right click on the JDK node under “External Libraries” in the project tree
2. Click “Open Library Settings”
3. Click “Libraries” under “Project Settings”
4. Click the New Project Library tool button
5. Click “Java”
6. Select the Metro/lib subdir in the “Select Library Files” path selector dialog.

Note that in NetBeans, you have to select the actual .jar files; selecting only the Metro/lib directory won’t work in NetBeans.  Selecting only the Metro/lib directory works fine in IntelliJ.

To solve this UsingAddressing policy issue from the Java client end, use the Metro libraries. Period.

Another way to solve this interop issue would be to address the service end: Add wsam:Addresssing as an acceptable alternative to wsaw:UsingAddressing in the web service’s WSDL. With both addressing policies as siblings under an <ExactlyOne> element, clients that support wsaw:UsingAddressing will be happy and clients that support only wsam:Addressing will be happy. In theory, anyway.

However, I have yet to figure out how to add wsam:Addressing to the WSDL generated by a WCF service. Since I have a client-side solution I won’t be pursuing this further, but if anyone can provide a link to how to do this on the WCF WSDL side, I’d love to see that solution as well.

Share/Bookmark

(You do know that computers run on smoke, right?  ‘Cause if you let the smoke out, the computer don’t work no more!)

My experiments with Code First took a turn for the worse today as my test app deteriorated from working nicely to failing with murky error messages that seemed to have little to do with the source code changes I just made. How am I supposed to figure this stuff out if they keep rearranging the maze?

I had configured my domain service to always drop the database tables and reset the tables with test data (using DropCreateDatabaseAlways)  whenever the entity model changed. I knew I would be making lots of changes to the model/schema, so might as well just wipe the slate clean every time.

As the strange failures began to mount, I noticed that sometimes after modifying my POCO entity classes (and therefore changing the entity model) running the test app did not hit my breakpoints in the context’s OnModelCreating or the initializer’s Seed methods.

To figure out what I had changed to cause all this pain, I started commenting out non-essential parts of the POCO classes, eliminating associations and composite keys and so forth.  The weird failures continued.  The failures weren’t even consistent – sometimes the client app would run once just fine and create all the tables it needed, then fail mysteriously with an invalid metadata error on the second run or when the page was refreshed.  Sometimes the first run didn’t even survive the first web request data query.

By the time I had whittled the POCO classes down to a single class with no inheritance and no associations and still had the client fail, I decided it was time to take a lunch break.  It didn’t matter what time it was, I needed to put it aside, leave it alone for awhile so I could make a fresh start later.

When I came back from my lunch break there was an error message box on the screen that I hadn’t seen before.  It said the database could not be dropped because it was in use by another client.  I had left the debugger paused at a breakpoint in the test app and it had trapped this exception some time after I had left my desk.

After a moment of head scratching, I realized the other database client was the Server View in Visual Studio that I was using to inspect the tables created by EF to see how my changes to the POCO entities affected the SQL schema.  Close the database connection in VS, restart the app and poof! Everything worked as it should.  It even worked twice in a row, which at that point was a new record for the day.

What was happening was the domain service in my test app was actually attempting to drop the tables from the database and build everything anew, but Visual Studio’s open connection to the SQLExpress service was blocking the drop action. Apparently, dropping the tables is a asynchronous action with a very long timeout interval.  The client would make its first request for data, the domain service would receive the request and fire up the DbContext, realize that the model and database needed to be regenerated, and issue the database drop and create operation.

The drop and create didn’t complete immediately, but apparently other activities proceeded asynchronously and began to fail because the schema found in the database didn’t match the expected schema.  I would see these bizarre failure error messages while stepping through the domain service code as part of the initial data request.  What I didn’t see was the root cause – the drop tables failure – because it didn’t fail until long after I had killed the test app and gone back to wondering what I was doing wrong in my source code.

So, simple solution: Always close any open connections in the Server Explorer before running an app that will drop tables.

This is not the error you’re looking for

Another tip for working with Code First Entities:  if you get a compile error about “You can’t use this entity in a method of your domain service class because it has not been exposed in your DbContext”, but you look at your DbContext class and you can see you most certainly have exposed that entity as a DbSet<class> property, here’s what you do:  Ignore the error message.  It’s a red herring. Instead, go check that your entity class explicitly designates a property as the primary key, using the [Key] attribute.  Fluid API calls to define a key in OnModelCreate won’t do – VS will only be satisfied by a Key attribute.

I don’t claim to know why, but after a day of permutations and combinations, this is what I found cleared the problem for me.

Share/Bookmark

I did a bit of proof of concept work using MEF about a year ago.  MEF is all about composition of providers and consumers.  MEF’s main job is to connect the providers to the consumers so that when the consumer code executes, the providers they require are “just there.”

As trivial as that sounds, it significantly changes how you think about programming.  It forces you to think in terms of composition instead of in terms of plumbing and bushwhacking.  As a result, you can focus more energy on solving your actual problem instead of spending the majority of your time building the plumbing and scaffolding so that you can get to the point where you can begin to solve your problem.

For example, if you’re writing some code and you require “X” to get your work done, you write your MEF code module to declare your need for “X”.  When your module is loaded by MEF, MEF will take care of the dirty details of finding a provider to fill your need for “X”.  The provider may be the one you had in mind when you wrote the code, or it may be completely different, but as long as it implements “X” faithfully, you don’t really care.  The application defines the list of providers to choose from – whether a fixed list determined at build time or a list gathered at runtime – the point is, you and your code don’t need to deal with the how, just declare the what and keep going.

MEF alters your coding thought process from

“I need to figure out how to load and connect to something to get the X that I need”

to

“I need X.  I can rely on X being here when my code executes.  If for whatever reason X isn’t available, my code won’t be loaded so I don’t have to mess with all that.”

This change in thought process is similar to the shift that can and should occur when you go from writing traditional fire-brigade error handling code to writing code in an exception handling environment. For most of the code in your app (the middle layers), you can operate under the mantra of “If execution gets this far, then everything prior to this must have succeeded.  If anything back there failed, it would have thrown an exception so I wouldn’t be here now.”

I’ll see if I can get clearance to blog about my little MEF experiment from awhile ago.

Share/Bookmark

You could create an event handler method to catch each of the old style events fired by the old code and turn around and fire the corresponding new style event in your API, but who wants to write all that mind numbingly repetitive code?

There is a simpler way.  The two incompatible event patterns do have one thing in common:  the Invoke method.

But first, some background.

Custom EventHandler Types, 1.0 Style

In .NET 1.0 the pattern to define an event property was to define an EventArgs class to carry the arguments of your event and define an EventHandler delegate type which uses that EventArgs class as its args parameter.  Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    public delegate void ActivityCompletedEventHandler(object sender,
                                                       ActivityCompletedEventArgs e);

    class Bar
    {
        public event ActivityCompletedEventHandler Completed;
    }

Generic EventHandler<> Types, 2.0 Style

With the advent of generic types in .NET 2.0, the generic EventHandler<> parameterized type was born.  This parameterized EventHandler<> delegate type simplifies how you declare and use event handlers – you don’t have to declare a custom event handler delegate type to match your event args class every time you create a new kind of event.  This is exactly the kind of thing that parameterized types (aka generics) were created to solve. Like this:

    public class ActivityCompletedEventArgs : EventArgs
    {
        public ActivityCompletedEventArgs(int resultCode, string result)
        {
            ResultCode = resultCode;
            Result = result;
        }

        public int ResultCode { get; private set; }
        public string Result { get; private set; }
    }

    class Bar
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;
    }

However, the downside is that EventHandler<> delegates are not assignment compatible with the old style non-generic EventHandler style delegates.

The Invoke Bridge

Both styles of event delegate have an Invoke method with a signature of (Object sender, EventArgs args), where EventArgs is the arguments class specific to this particular event.  You can use this point of commonality to convert between event styles without too much trouble.  The trick is to use the .Invoke method in one style of event as the callback method registered in the other style of event:

    class OldStyleClass
    {
        public event ActivityCompletedEventHandler OldStyleEvent;
    }

    class NewStyleClass
    {
        public event EventHandler<ActivityCompletedEventArgs> Completed;

        public void blah()
        {
            var obj = new OldStyleClass();
            obj.OldStyleEvent += new ActivityCompletedEventHandler(Completed.Invoke);
        }
    }

The code above hooks up the events so that when OldStyleClass.OldStyleEvent fires, it will fire the NewStyleClass.Completed event.

The main catch to this technique (in C#) is that the reference to the event’s .Invoke method must be made from within the context of the class that defines the event. C# doesn’t allow access to the members of an event delegate outside of the class that defines the event. The rules may be different in other .NET languages.

If you want to use this technique in the opposite direction (to have a new style event fire an old style event), you will need to be able to modify the source code of the old style class that defines the old style event. This is much less common than making old style code to fire new style events.

Share/Bookmark

Silverlight was the primary deployment vehicle for live online video coverage of the Olympics last summer, and more recently live video coverage of the Obama inaugeration last month.  Moonlight enables Linux users to view video and applications built for Silverlight on their Linux boxes.

Scott Guthrie has more details here.

Share/Bookmark