Clemens Vasters

July 12, 2004

@ 06:07 AM

I've had several epiphanies in the 12 months or so. I don't know how it is for other people, but the way my thinking evolves is that I've got some inexpressible "thought clouds" going around in my head for months that I can't really get on paper or talk about in any coherent way. And then, at some point, there's some catalyst and "bang", it all comes together and suddenly those clouds start raining ideas and my thinking very rapidly goes through an actual paradigm shift.

The first important epiphany occurred when Arvindra gave me a compact explanation of his very pragmatic view on Agent Technology and Queueing Networks, which booted the FABRIQ effort. Once I saw what Arvindra had done in his previous projects and I put that together with my thinking about services, a lot of things clicked. The insight that formed from there was that RPC'ish request/response interactions are very restrictive exceptions in a much larger picture where one-way messages and much more complex message flow-patterns possibly involving an arbitrary number of parties are the norm.

The second struck me while on stage in Amsterdam and during the "The Nerd, The Suit, and the Fortune Teller" play as Pat and myself were discussing Service Oriented User Interaction. (You need to understand that we had very limited time for preparation and hence we had a good outline, but the rest of the script essentially said "go with the flow" and so most of it was pure improvisation theater). The insight that formed can (with all due respect) be shortened "the user is just another service". Not only users shall drive the interaction by issuing messages (commands) to a systems for which they expect one or more out of a set of possible replies, but there should also be a way how systems can be drive an interaction by issuing messages to users expecting one or more out of a set of possible replies. There is no good reason why any of these two directions of driving the interaction should receive preferred treatment. There is no client and there is no server. There are just roles in interactions. That moment, the 3-layer/3-tier model of building applications died a quick and painless death in my head. I think I have a new one, but the clouds are still raining ideas. Too early for details. Come back and ask in a few months.

Categories: Architecture | SOA

« Got caught | Home | Addressing insight over beer »

Monday, July 12, 2004 9:52:10 AM (Pacific Daylight Time, UTC-07:00)

Hi, Clemens,

One of the first questions I had when I started to think about SOA was "How do user interfaces fit into the picture". Microsoft's smart client concept didn't exactly give an answer. Then I had an epiphany ;), that actually the user interface is another service, just with one interface communicating with the user.

Now, you've clarified that picture even more, in that not only the UI is a service, but also the user is a service. The UI is then a kind of a translation service. One thing to note is that the user does not communicate with the IT system not only through a certain UI, but multiple UIs, and also through other users. E.g.:

1. a buyer orders something from an online store (frontend)

2. the store frontend sends the order to order processing service

3. order processing sends the order to billing service

4. billing service send the bill to the user through e-mail

4. the user prints the bill, signs it, goes with it to the accounting department

6. the accounting department pays the bill through online banking

7. the bank notifies the billing service the bill has been paid

8. the billing service notifies the order processing

etc, etc,

It's all services (user, store frontend, order processing, billing, e-mail, accounting, bank) and messages (order, bill, approved bill, payment).

The billion dollar question then, is: How can we benefit from the concept?

Regards,
Magnus

Magnus Hiie

Monday, July 12, 2004 12:42:47 PM (Pacific Daylight Time, UTC-07:00)

Interesting -- I had a similar kind of epiphany thinking about services that I dubbed "WSDL for the people." Unfortunately, I haven't pulled the concepts together fully, but I am thinking about how it ties into bp concepts.

Jef Newsom

Tuesday, July 13, 2004 3:42:19 AM (Pacific Daylight Time, UTC-07:00)

Just a quick observation: Isn't the user too chatty?

What leads me to this is we tried to model our UI framework on the idea of clearly separated layers with sync-points - akin to a message arriving. However, programming user interaction in this highly non-modal way proved onerous to typical programmers. For instance, you no longer do

if (userSaysYes()) doIt;

but instead set a request for the answer and handle the resulting message asynchronously.

Peter Arrenbrecht

Tuesday, July 13, 2004 7:27:08 AM (Pacific Daylight Time, UTC-07:00)

I started to puzzle over that one as well, at first the concept of the user is a service didnt sit well at all. But the more I thought about it the more it made sense.

So what of applications ?

Well if the user is a service then application are, as Magnus was saying, a service translator.

Which made me further think. We have wsdl for web services so what of usdl (i know its quirky) for the user translation application. There could be little need for bespoke applications in this concept.

Seems we are already going in that direction with InfoPath which can read wsdl and possibly in future xaml as a means of styling a generated UI. I think Infopath is in its infancy but with a combination of wsdl - for message definition, behaviour - for hinting at the UI experience, css (equivalent) for brand and styling, App development would only be a case of producing 3 files or an almagamation of them into usdl.

I dont like this future it give me less and less to do my msdn universal subscription might as well be a paintbox (its half that already). ;-)

Simon

SimonTocker

Comments are closed.

It's 2010. More bandwidth please. I want 1080p across the Atlantic.

Navigation for Clemens Vasters - Epiphanies