[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Web Services/SOA (was RE: XML 2004 weblog items?

soa method
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@g...]

On Tue, 30 Nov 2004 12:21:08 -0600, Bullard, Claude L (Len)
<len.bullard@i...> 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.



Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.