Todd, you are 1000% right with 'SOI, service oriented integration, is probably best stated as WSOI- Web Services Oriented Integration. '
WSOI- Web Services Oriented Integration - is one and only one acceptable term in this context. We have to DE-COUPLE Web Services from Service Orientation. Just a technical construct has obfuscated the brilliant concept and now is killing it. I recruit volunteers to save Service Orientation! - Michael ________________________________ From: Todd Biske <[email protected]> To: [email protected] Sent: Thursday, March 19, 2009 3:33:04 AM Subject: Re: [service-orientated-architecture] SO applied to different architecture levels (was Re: Roch on SOA Failures) Here's my take. SOI, service oriented integration, is probably best stated as WSOI- Web Services Oriented Integration. It's simply the act of taking the same integration points that arise in a project and using web services or some other XML over HTTP approach to integrate the systems. Could this constitute a service-oriented application architecture? Absolutely, but in my mind, there is at best incremental benefits in this approach versus some other integration technology. Because the scope is a single application, it's unlikely that any ownership domains beyond the application itself were identified, so there won't be anyone responsible for actually looking for and removing other redundant service implementations. Because the scope of the services involved didn't change, only the technologies used, it's unlikely that the services will have any greater potential for reuse than they would with another integration technology except that XML/HTTP will be more interoperable, than say, Java RMI, if that's even a concern. To me, SOA must be applied at something larger than a single application to get anything better than incremental gains. Services should be defined along ownership domains that create accountability for driving the redundancy out of the enterprise where appropriate. This is why an application rationalization effort or application/ service portfolio management is a critical piece of being successful. If it's just a "gut feel" that there is a lot of waste in the IT systems, arbitrary use of a different integration technology won't make that go away. Only working to identify the areas of redundancy/waste, defining appropriate ownership domains, and then driving out the redundancy through the use of services will make a significant difference. -tb On Mar 18, 2009, at 12:46 PM, Rob Eamon wrote: Wanted to explore the "SOI vs SOA" aspect a bit. I've long held that SOA is not a distinct level of architecture. Some agree that SOA is a style, not an architecture itself. The term SOA does not infer any particular level. One can apply SO principles to any architecture. Some use the term SOA to refer to an architecture definition, rather than a style. In other words, SOA is EA. SOA infers architecture at the enterprise level. If one is not defining an EA when "doing SOA" then it isn't SOA, it is something else. [Some-- at least Steve ;-) -- equate SOA to BA. I'm omitting BA for the purposes of this discussion.] It is this latter view that seems to weigh in on the SOI vs. SOA topic and seems to have prompted the invention of the "SOI" term. It implies that architecture is not involved. Assuming one agrees with the notion of an "integration architecture" as a possible architectural level, is it reasonable to apply SO principles to the IA? As such, would the IA be an SOA? Is applying SO to IA a poor choice? Is defining an IA a poor choice, as opposed to a more encompassing EA effort? Is redefining the EA (e.g. "simplifying their applications and...") the only reasonable path to business agility? Is business agility *the* primary thing to strive for? -Rob --- In service-orientated- architecture@ yahoogroups. com, Anne Thomas Manes <atma...@... > wrote: > > Most organizations that I've spoken to are using service-oriented > middleware to do integration (SOI rather than SOA). Very few > companies are actually rearchitecting their systems, i.e., > simplifying their applications and data architectures in order to > increase agility.
