So, how I did I come to be wondering if using Web Services within the same application was wrong yesterday?

Well, let's imagine some scenarios and their "traditional" solutions.

Scenario 1

Problem

Say you want to simply approve/decline a document in a workflow and pass it via email to the next approver, but you know that, for whatever reason, the user won't have Author access to it.

Solution

What I'd tend to do here is create an Agent which accepts the document's ID and the action/status to be performed.

Issues

This is no biggy really, but ideally this would need to be a POST request (we all know GET should only fetch data and not change it, right!). When you POST data to an Agent you need to manually decouple all the name/values manually from within the REQUST_CONTENT field (or REQUEST_CONTENT_001 etc if more than 64k passed!!). This is where it gets a bit messy and tedious.

Scenario 2

Problem

You just want to change the value of field on a document. Ideally you want to be able to specify the field.

Solution

You could always create a HTTP request that posted to a ?SaveDocument URL with the field's name/value pairing as the only parameter passed.

Issues

What if you want to avoid triggering a full save of the document? Maybe because you don't want to run the code in the form's WQS agent, for whatever reason.

Again you find yourself needing to create an(other!) agent. 

Scenario 3

Problem

You want to re-order a set of documents. This is something I've described before and you can see demos of it here.

Solution

To do this I POST a list of the documents and their order to a ?CreateDocument URL. The document (which have SaveOptions field set to "0") has a WQS agent which loops through the mutli-value field which received the list and, for each document, updates its order.

Issues

While this works well it involves the addition of two new design elements to the database just to solve one "simple" task.

What's The Problem?

While the scenarios above aren't exhaustive - just some things that came to mind right now - you should see a common theme appearing?

In all cases all we want to do is perform some action on the server. It doesn't really matter what we want to do. The problem is that for each new action we decide to add we need to create a new design element (if not two). If you end up adding 10 action you could have up to 20 design elements cluttering up (an already cluttered in some cases) database.

What's The Solution?

For ages now I've been thinking of doing away with all these separate agents by writing a single agent that can perform any action needed. You can call if via GET or POST and you pass the action it is to perform using the URL. So the URL might be:

/database.nsf/actions?OpenAgent&action=approve

The document ID and other data would then be posted to it.

Inside the agent would be a big "Select Case (Action)" which examines the URL and performs the right code block depending on what it's asked to do.

Still all quite messy but at least all the backend "business logic" is in one place. I haven't got as far as creating it yet, as I'm knee-deep in Flex at the moment and that allows me to use Web Services, which, potentially, make it even simpler.

Where Do Web Services Come In?

In Flex there is support for using Web Services. You define the Web Service and when the app loads it fetches the WSDL code and you then have all the backend methods/actions available.

Using a Web Service you can keep all the logic for the various actions you might need to perform within a database in one place.

Better yet it defines what parameters a method needs to accepts and even makes them "typed" for us. We don't need to decode and decouple the data posted. The Web Service does this for us. In our backend code we can just start working directly with the data parts as we'd expect.

Even better still the Web Service can return the result of the action to Flex as a String, Boolean etc and Flex works with it without any type casting/checking needed.

In Summary

We're not talking about replacing the Standard Domino URLs here, such as ?SaveDocument etc. If you're creating/editing a document with a form then use the standard approach.

What I'm talking about is a simple way to code the actions we often need to bolt on to make an application/database do anything useful.

Yesterday's discussion didn't feel like there was a conclusion as to whether consuming a Web Service from the same server and the same application was "wrong". The more I think about it though the less I care. I'm a Domino developer. I've spent the last 10 years using any method I can to get things to work.

Eight years ago I described a hack that uses the Navigator design element to get a Form to act as a database's homepage. I still use it to this day. Who uses a Page to store CSS still, even though there's a StyleSheet design element specifically for this? I know I do.

As Domino developers we're using to the by-whatever-means approach to making things do what we want. I don't see why I should stop now.

Tomorrow?

Tomorrow I'll show you the code on both sides of this --- the Flex code that consumes the Web Service and the LotusScript that makes up the backend logic. Hopefully then you'll agree that what I am doing makes not only sense but our jobs easier, which has to be a good thing, right?