RE: Web Services/SOA (was RE: XML 2004 weblog items?
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@g...] On Tue, 30 Nov 2004 13:24:31 -0600, Bullard, Claude L (Len) <len.bullard@i...> 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?
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