[
Lists Home |
Date Index |
Thread Index
]
Yeah. I used to use the term 'dimensional viewpoint' in
the sense the chaos theorists use it. OTOH, I don't think Box et al are
thinking
about time-dependencies. At a Vancouver Hytime conference,
I even presented a formula that got a few oohs and aahs.
Wish I could remember it. The project manager made me
take it out of the final document delivered to the Navy,
the infamous Appendix F.
But context is easier. Maybe we just need a good topic map
for this stuff. Seems they have the term 'view' now.
Every few years, we toss out the old terms and attempt
to reapply the technologies that didn't quite make it
in the last cycle. Occasionally, we even sacrifice a
goat at the first conference with the new name attended
by the same people. The goat is very important.
len
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
On Tue, 30 Nov 2004 13:24:31 -0600, Bullard, Claude L (Len)
<len.bullard@intergraph.com> wrote:
> No disagreement.
>
> I understand it's incompleteness. As I responded to Karl,
> it seems to be a concept that fell from the work in enterprise
> modeling that dates at least as far back as Mark Fox's work.
> I made use of that when writing the Enterprise Engineering
> papers eons ago. One doesn't always organize services independent
> of time. One can organize functions that way, but any
> any service that requires a time-constrained resource
> can't be. Sequenced services (eg, orchestrated or
> choreographed) can't be if they share common resources.
Ok. I think I see what you're getting at. That means the real way to
look at this is that Services are a Time dimension model and not a
Function dimension model. From a conceptual model POV that makes
sense. You're supposed to be modelling business cycles there and as
you point out to Karl SOA: "is how businessHeads see their businesses,
as contracts for products, goods, and services."...
>
> Yes, the levels are mixed and that is why I said, thinking
> of events is at least one level higher, but so are services.
> Seems to me a term was borrowed from a higher level of
> organization and applied to a lower level. It depends on
> the viewpoint of the observer/user. To a programmer, a
> service looks like a method call.
Alternately, given the above, you get a service when you can
predictably/reliably invoke a method at some point in time. All the
WS wrappings then become ways of making the invocation of the method
more predictable (via encapsulation) for more people (via discovery).
And that's the sizzle that the people are trying to sell by using the
SOA term...
> I don't object to Tim's complaint. I agree. I'm used to living
> in a world of fuzzy concepts. I'm not used to coding in a
> fuzzy framework, so I make the adjustment. Where this gets
> hard is when the sales and marketing people come to chat.
Sure, some hand waving as they invoke the magic term "SOA" and next
thing you know your boss expects transparent data exchange with 500
new business partners to be up and running in a month...
> Yet when one talks in terms of enterprise frameworks, services
> make more sense than methods or function calls.
Perhaps not, perhaps one simply has to keep each of them in the proper
context?
|
