I agree, JP, we have got a sort of consensus on SOA and integration. Here are two expressions I would like to comment on: "Your services are designed to work with each other by nature." and "successful SOA should reduce integration requirements and lead to a > more interoperable services infrastructure"
In this context 'integration' is viewed as an external means connecting two or more entities together vs. the entities are ready by themselves (by design) for collaboration. Am I correct in the interpretation? Actually, I like this contra-position because I think of integration in right this way (maybe I wrong but not that much) Let's looks at SOA business services first. There are 2 basic types of them: self-contained atomic stand-alone services (usually implementing one concrete business function and not looking for any assistance from other services to fulfill promised business functionality and RWE) and aggregate/composite services that may include processes as the implementations. Now, an "interoperable services infrastructure" suggests that services interact with each other. The atomic services can participate in the interactions only as a passive entities while aggregate/composite services may be passive or active entities depending on the scenario. Can an atomic service invoke another service? Of cause, there are no limitations, but it does not need it (otherwise, it not atomic any more). Can aggregate/composite service invoke an unknown service? Yes, it can, based on the business requirements to the needed business functionality. Will it do this? It depends on the risk assessment. I would not recommend SA business services invoke strangers due to unknown business trust and business implication. I think that service orchestration is the ideal form of service collaboration and the means of interoperable infrastructure. The orchestration is based on formalized (not necessary standardized but described) business functionality and connectivity. Orchestration does not require any service to know about other services 'internally' (however, a participant of the orchestration may be the orchestration manager by itself, but it is not a requirement of the initial orchestration). Thus, interpretability in the orchestration is based on ability to invoke a service interface based on its description (Web Services and IDL can provide for this feature). The observation above is at the edge of talking about standardized interfaces that interpretability 'might' require. I think, it would not be right approach now because it limits flexibility and adoptability to the changes and may be too restrictive to the future needs. I would prefer to invest into semantic-based mediation/transformation rather than in to unification of the interfaces. Example with Web Services and related message namespaces has shown us how difficult to insert a minimal change into standardized interface (not because it is standardized but because it is 'firm'). So, the standardization has not added much interoperability for the changing environment, and this changing world is going to stay with us for a few years. Thus, immediate solution for interoperability is in semantics (IMHO); when changes slow down, standardization maybe show more value. - Michael ________________________________ From: JP Morgenthal <[email protected]> To: [email protected] Sent: Monday, January 5, 2009 4:51:24 PM Subject: Re: [service-orientated-architecture] Linthicum's Latest Blog We've been over that issue before: Yefim Natis's paper begat Loraine Lawson's blog, which begat Joe McKendrick's blog that begat David Linthicum's blog. Loraine Lawson's blog also begat a very long-winded conversation here on this forum. I prefer we not rehash that. The intent of my post was to discuss the semantic use of integration in Dave's post versus orchestration. JP On Mon, Jan 5, 2009 at 11:37 AM, Michael Poulin <m3pou...@yahoo. com> wrote: > "You get to SOA through integration, or more accurately the loose coupling > of systems that create and architecture that's easy to change. " - returns > to the discussion of where SOA starts. > To me, SOA starts in disintegration, disassembly of the business model. This > allows to answer WHAT and WHY we need those systems that might be > loosely-coupled or integrated, and whether an integration or > loose-coupling (i.e. HOW) can really help us to achieve the "easy to change" > state. > I think, IT did enough already trying to 'guestimate' what really Business > needs. SO may be and should be applicable at all levels but only after > getting the clear understanding (from the business perspective) of 'what to > do this application for'. > I am glad for Dave with his definition of a "good architecture" but cannot > 100% agree with him. If you have quite stable and steadily growing market, > you care mostly about sufficient scalability and performances rather than > flexibility, which you do not have business needs, i.e. changes, for. Is an > extremely flexible architecture is the right/good one for such market? I do > not think so; it addresses different concerns than the market needs. > Integration may be a part of SO solution (SOS) but as its intermediary > outcome, not as a way into SOA/SOS [see, the start point matters]. The > statement "You get to SOA through integration" is wrong (IMO) as we agreed > in our previous discussion already: 'integration by itself does not > necessary lead to SOA' > - Michael > ____________ _________ _________ __ > From: JP Morgenthal <jpmorgenthal@ gmail.com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Monday, January 5, 2009 3:04:26 PM > Subject: [service-orientated -architecture] Linthicum's Latest Blog > > In Dave's latest posting: > > SOA is architecture with integration > (http://weblog. infoworld. com/realworldsoa /archives/ 2009/01/soa_ > is_architec. html) > he posits that integration is an inherent sub-component of SOA by its > nature. > > "Second, SOA, while also leveraging integration as a sub-pattern -- > and integration is a byproduct of SOA -- is really about architecture, > or at least it should be. You get to SOA through integration, or more > accurately the loose coupling of systems that create and architecture > that's easy to change. You can call this agility, changeability, or > whatever, but I call it good architecture. Integration indeed has > value, don't get me wrong, but the largest value is the ability to get > to an SOA, if you ask me. Or, at least to the SOA that's right for > your enterprise. " > > I commented on his blog as follows: > > "Perhaps the problem is with the word integration more than with the > term SOA in this particular case. > > Integration is clearly overloaded in this case. By their nature > services are designed to be chained together in series to form a flow > (we exclude the mega-service concept here which usually indicates poor > design, in which one service does everything). I don't believe we > should be calling this integration any longer. > > IMHO, integration is about making two disparate systems participate in > a larger systematic effort. If you have SOA, you remove this > limitation. Your services are designed to work with each other by > nature. Hence, we don't have integration, we have orchestration. " > > I thought it would be interesting to take this debate to this forum > where it could be addressed by the larger SOA contingent. I know > it's really just all a matter of semantics, because I'm sure there are > those among us that would consider orchestration a sub-component of > integration. However, for me, the distinction is important because > successful SOA should reduce integration requirements and lead to a > more interoperable services infrastructure. > > Thoughts? > > JP > >
