OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Web Services/SOA (was RE: [xml-dev] XML 2004 weblog items?

[ 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.


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.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS