RE: Web Services/SOA (was RE: XML 2004 weblog items?
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@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  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. --
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format