[
Lists Home |
Date Index |
Thread Index
]
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.
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.
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.
Yet when one talks in terms of enterprise frameworks, services
make more sense than methods or function calls.
len
From: Peter Hunsberger [mailto:peter.hunsberger@gmail.com]
On Tue, 30 Nov 2004 12:21:08 -0600, Bullard, Claude L (Len)
<len.bullard@intergraph.com> wrote:
> Are services responses to events?
>
> That is likely at least one level higher
> in the organizational architecture if call
> and response is the lowest level of description,
I don't think I get the distinction you're making here. Aren't these
orthogonal concerns? That is, one models the Time dimension
independently of the Function dimension [1] and shouldn't be tightly
coupling the implementation of either to each other?
> but if we are to speak of a 'services oriented
> architecture' that is meaningful beyond the
> most primitive descriptions, it can be useful
> to think in terms of event types over
> messages. Otherwise, a service and a method
> are indistinguishable. I'm not sure the fact
> of using XML to send and return the request or
> the opacity at the boundary are enough to
> distinguish a service from a method invocation,
> remote or otherwise.
Well if they are indistinguishable that sort of makes sense from a
high level architectural perspective. Aren't you starting to tread
into detail design and implementation once you start to try and draw
this boundary? Certainly the physical design enters into the
architecture, but if one is talking about SOA then I don't think one
is specifying the architecture down to the physical level. Rather
you're hitting some of the Data, Function and maybe Time and Network
dimensions at the conceptual and logical levels at best?
IOW, what this thread is circling around is that, currently, SOA is
not a complete "Enterprise Architecture" nor a best practice for
physical or detail design. As an architecture it's incomplete and
thus Tim's initial complaint.
--
|
