a couple of years ago I was toying with the concept of a behavioural language, and thoughts of this came flooding back to me as I read
Rocky's recent post about SOA. The problem is not the "service" part of SOA, rather the message is incredibly limited and is basically data centric, not behavioural in nature.
Let's take a simple example of a real world person to person (autonomous entities) interacting in a "service" based transaction such as banking. In this case consider a loan application. The first thing is based on a few questions, they will gather the paperwork for the right kind of loan for you. typically, the form that needs to be filled in will have information about how to fill it in. There will also be conditional statements, such as "if you under 18… " etc.
So the interaction is somewhat dynamic. It's not like you can have the form already, as the form may change. So really, the whole UI is in fact the service. This leads us to thinking a web application or streaming WPF or an updating ClickOnce.
That's fine if you control both the entire application from server to UI, as
Geoff points out. But what if you don't ?
For example, if the rules change, such as the fees or minimum payments based on other fields in the data ? Typically this would require you to re-write this in multiple places
A service schema can set some basics as per an xsd, such as minimum value or required. but it can do so only statically. To make this dynamic, to provide a Behavioural Informative Language, the schema needs to be much richer and provide conditional statements, informative descriptive expressions that can be evaluated, and most importantly the ability to refer to other fields in the describing the attributes of a given field.
For example, let's say you have a first name and a last name property. The rules should be able to be specified that the field is required if the other one is empty. That is at least one of those fields must be filled in.
eg.
<Customer>
<FirstName required="If(IsNull(.LastName), true, false)">
<LastName required="If(IsNull(.FirstName), true, false)">
Likewise you could use standard operators, IsNull, If(,,) and maybe just a few more descriptive operators to describe the behaviour.
And some behaviours could themselves point to a service.
The idea is the description becomes a lot richer. UI elements could use this to form validation and guide user interaction.