Its a nice theory but I've never seen automatic semantic matching work in practice.
Although what you are talking about is automating the integration practice rather than eliminating it. As a piece of madness how about this If it requires energy to bring things together then this constitutes an act of integration. The scale of the integration is related to the amount of energy required. There are marked jumps in this energy requirement and automation can reduce, but not eliminate, the energy required. The efficiency of an integration environment is measured in terms of both the energy required in its creation and in the energy required to maintain its stability. Entropy thus becomes normal IT operations and energy is the governance, development and support effort required. (http://service-architecture.blogspot.com/2007/10/should-it-deliberately-create-chaos.html) Steve 2008/7/3 Michael Poulin <[EMAIL PROTECTED]>: > Yes, certainly. Can we look at it from different angle? A requirement of > sharing context may be too strong and quite constraint. What if instead of > sharing we would look at ability to share? > > Assume, we have two business divisions in the same financial or oil/gas > company (I mean - standardized and regulated markets) situated in different > countries. That is, they share the same sphere of corporate policies ( for > simplicity of the example) but use their local jargon in terminology and > relationship/dependency definitions. The service in both divisions can > interact w/o preliminary shared context but if both of them have proper > semantics 'engines' capable of understanding each other. This understanding > is the context after all but it appears on demand, not at the design time. > > How about this? > > - Michael > > ----- Original Message ---- > From: Steve Jones <[EMAIL PROTECTED]> > To: [email protected] > Sent: Thursday, July 3, 2008 9:15:24 AM > Subject: Re: [service-orientated-architecture] Re: Legacy into SOA (was > Vandersluis on a Data Abstraction Layer's Benefits) > > But they still need to understand both the vocab, syntax and the > semantics of the interaction which requires more communication, blind > integration is an entertaining pastime that I've seen companies engage > in, its quite stunning some of the issues it can bring. > > I think natural should also require a shared context. > > Steve > > 2008/7/3 Michael Poulin <[EMAIL PROTECTED] com>: >> If the systems do not expose their communication points via a WS or REST >> interface and somebody has to do some work to put them on and connect >> internally, this is the 3-rd party work, this is integration. If systems >> can >> communicate via WS or REST w/o additional "hooking", the interfaces are >> natural. >> >> We cannot say how effective communication/ integration is based on this >> info. >> I do agree with you. >> >> - Michael >> >> ----- Original Message ---- >> From: Steve Jones <jones.steveg@ gmail.com> >> To: service-orientated- architecture@ yahoogroups. com >> Sent: Wednesday, July 2, 2008 11:06:05 PM >> Subject: Re: [service-orientated -architecture] Re: Legacy into SOA (was >> Vandersluis on a Data Abstraction Layer's Benefits) >> >> Would you count lobbing a WS or REST interface as being "natural" or >> "3rd party"? For me doing that still doesn't mean you have an >> effective integration approach you have to think a little bit longer >> before putting the string in place. >> >> Steve >> >> 2008/7/2 Michael Poulin <[EMAIL PROTECTED] com>: >>> When systems cannot interact with each other but we need them doing this, >>> we >>> use integration. Thus, are the interaction and integration the same >>> things? >>> >>> When I talked about a 3rd party for integration, I meant not a broker but >>> somebody building the integration (since the parties could not interact >>> on >>> their own). Looks like this 3-rd party and associated process of building >>> integration is the major difference between natural interaction and >>> interaction based on integration. When integration is done and systems >>> interact, there is no difference (though, in this case, the interaction >>> is >>> provided by the means that do not belong to neither of the participants) >>> . >>> When an broker is used in the middle, it does not seems to me as an >>> explicit >>> interaction. >>> >>> - Michael >>> >>> ----- Original Message ---- >>> From: Steve Jones <jones.steveg@ gmail.com> >>> To: service-orientated- architecture@ yahoogroups. com >>> Sent: Wednesday, July 2, 2008 5:09:13 AM >>> Subject: Re: [service-orientated -architecture] Re: Legacy into SOA (was >>> Vandersluis on a Data Abstraction Layer's Benefits) >>> >>> I actually thought that this was the spaghetti definition of >>> integration, multiple systems all connecting directly giving and n^n >>> complexity. >>> >>> Its certainly still integration but quite often its the worst form. >>> >>> Steve >>> >>> 2008/7/1 Todd Biske <todd.biske@ gmail. com>: >>>> Rob wrote, in response to Michael: >>>> >>>>> >>>>>> >>>>>>> >>>>>> >>>>> >>>>>>> IMO. App A and App B talking to each >>>>>>> via any number of direct means is still integration. Same goes >>>>>>> for provider x and provider y. . >>>>>> >>>>>> I do not think we reach an agreement in this ever. >>>>> >>>>> Not surprising. Not many agree with me on that particular point--it's >>>>> viewed as too generic a definition of integration. >>>>> >>>> I agree with you Rob. I don't think an integration requires having a >>>> third party involved, that's just one technique. >>>> -tb >>>> >>>> Todd Biske >>>> http://www.biske. com/blog >>>> Sent from my iPhone >>>> >>> >>> >> >> > >
