Web Services: Using Complex Types
Last week I showed how simple it is to share data between Domino and ASP.NET using Web Services. That example was way too basic though and not a great example of how simple it really is - even in a more "real world" scenario.
Here's a Notes database with some basic information about fashion designers that I made up:
Now, let's share this information with our ASP.NET MVC website!
First we create a new Web Service Provider in Domino Designer:
I called it FashionDesignerLookup and renamed the Untitled.java file to Lookup.java. Then I added a separate Java file called FashionDesigner.java which is our custom "Model" object.
Here's what FashionDesigner.java looks like:
It's a simple class which exposes a few string properties and one integer for age. Still, very simple.
Now, here's what the Lookup.java file looks like (this is the class specified as the "Port type class" for this service):
The Web Service now has a method called getAllDesigners() which simply returns an array of objects - all of the type FashionDesigner - back to the calling Web Service.
But how does the Web Service consuming part in ASP.NET take to this new custom class? Very easily, as we'll see.
Back in Visual Studio, first thing we do is update and/or rename our Service Reference to point to the new location of the WSDL file for the Provider we just made and then change the references to the service and the new method in the "Home" Controller file (see last week's post for more detail on that).
Here's the HomeController.cs file with the updated code in it:
The above code simply passes an array of FashionDesigner objects to the View using the ViewBag property, which we can then reference in the View it's passed to, as below:
Notice I've defined a local variable in the View of type FashionDesigner[] and the code simply loops through this array of designers and lists them all in table.
Notice how ASP.NET recognizes the FashionDesigner class and has strongly-typed its member properties. Visual Studio created the C# classes to represent our FashionDesigner class all on its own, based on the content of the new WSDL file. Again, we didn't need to do anything at all.
Note: Removing or changing the types of properties for the custom class in Domino Designer makes Notes throw a fit ("The requested operation failed"). Plan you classes carefully up front! Also, if you do change the Web Service in Domino remember to right click the Service Reference in Visual Studio and refresh it!
Here's what the MVC page looks like in the browser:
It can't get much simpler than that, can it now!?
Overkill?
Some of the feedback on last week's post about Web Services argued against their use in favour of more developer-friendly REST-based requests. The argument being that Web Services are overly-complicated.
While Web Services may well be complicated and bloated, Domino and ASP.NET make it so easy to create and consume them that the majority of the complexity is hidden away from us.
While I'm a purist at heart too and love the idea of using a RESTful approach, you just can't argue with how simple, yet advanced, the above approach is. One of the aspects I like about is how the Web Service is almost "self-documenting". Any developer you share the WSDL with can import it and then has an instant view of the objects and their methods and properties via IntelliSense type-ahead.
How do you get around authentication? This is great if you're serving up data everyone has access to. But what about data that is secured at the document level, like getting "my tasks" out of a database.
I've run into this issue plenty and just end up sticking that data in an iframe using single sign on isapi filter for domino.
Reply
I haven't really. The only type of authentication my scenario calls for is to check that the caller is allowed to use the service. This won't use the NAB and will use Web Services authentication (once I work it out).
People last week talked about Directory-based alternatives though in the comments.
Reply
Show the rest of this thread