[
Lists Home |
Date Index |
Thread Index
]
Introduce them to the model of thinking of reports. Your organization
has no doubt over time created many reports and most of these are
asynchronous in the business process (not reliant on call and response
or only lightly) and are long transactions (people take vacation, people
take sick leave, people are overloaded so wait states are bad). These
reports evolved out of the normal elastic time of human processes.
Below the level of a report, there are problems of currency but
timestamps are good here. There are binding orders but implementing a
notification system isn't that abnormal. There are routing problems
but implementing a distribution data model isn't that abnormal.
SOA is there to bridge the gap between machine time and functions and
human time and procedures. OOP is geeky. That's fine. Keep it away
from the humans. :-)
len
From: Fraser Goffin [mailto:goffinf@googlemail.com]
Andrew,
actually re-reading your original email (more carefully) I can see
that we agree on most (probably all) of the things I was grumbling
about (I'm always a bit grouchy on a Sunday night :-). I *do* agree
that utility services (and actually even some business services can be
modelled) in an RPC 'style', we use this for one of the ones you
mentioned (looking up reference data - aka. code lists).
The point you make about synch vs. async is extremely topical to me
right now. I have for a while been trying to explain to our design /
architecture team that whereas a synchronous model on paper looks
attractive, and there are indeed aspects of an overall busines process
that *must* be conducted that way, if we really want to be able to
scale as well as implement expected reliability assurances into our
services, then we need to squeeze those pieces out and implement them
asynchronously. Of course this can have an impact of the way that
business processes currently operate and it can take a while to
convince our business colleagues that they aren't losing anything (and
hopefully gaining a great deal).
I work in the implementation team (much more fun than ivory tower
stuff) and as you say, when the 'rubber hits the road' physical
practicalities come into play.
Actually looking back over what I've just written, your probably right
about the level of understanding of this stuff, so probably I need to
practice a bit more patience :-|
|
