Modern UDDI and old CORBA Object Trading Service both have the same problem - how to express a look-up query to find the service you need? Google's and others' word-matching techniques does not work well enough in the business, its efficiency is about 80% (as you mentioned) and we need a much better result w/o "having a meeting and just agreeing on the share vocab". Actually, in SO, we are interested in functions rather than in vendors (who we could have a meeting with)
Serendipity:Looking for something, we usually find something elsebut it is exactly what we need. This is my translation from Russian version of Winnie-The-Pooh. This is what I think we need in SO service discovery. - Michael ----- Original Message ---- From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, July 4, 2008 12:12:12 PM Subject: Re: [service-orientated-architecture] Re: Legacy into SOA (was Vandersluis on a Data Abstraction Layer's Benefits) I saw a presentation once at a conference (SAINT 2003 IIRC) where someone presented a mathematical model that said that semantic matching could only ever get to around the 80% accuracy level. The chap next to be from CSFB pointed out that this was billions if not trillions in lost transactions so he'd probably give it a miss ;) I'm prepared to be wrong on semantics but until its more efficient than sitting down and having a meeting and just agreeing on the share vocab then I can't see a great deal of point to it. To your management point, that is what I mean by energy, the efficiency point is the question not whether integration is being done or not. This means that standards based approaches and formalised governance (which can increase efficiency) help from a business perspective and its ITs job to ensure that the efficiency is sustainable. Steve 2008/7/4 Michael Poulin <[EMAIL PROTECTED] com>: > You are saying (together with Rob) that interaction is integration. Well, > you, guys, may be right; I looked at it from the manager position - do I > need an integration work to be planned or systems can interact w/o it... > > However, a "nice theory" will become a crucial requirement when a business > service starts viewed as the business-IT thing and its meaning should be > understood in the business first, then in IT. I also haven't not seen such > thing working. Does anybody know a practical example of Semantic SOA (not > theoretical articles from conferences) ? > > - Michael > > ----- Original Message ---- > From: Steve Jones <jones.steveg@ gmail.com> > To: service-orientated- architecture@ yahoogroups. com > Sent: Friday, July 4, 2008 9:52:13 AM > Subject: Re: [service-orientated -architecture] Re: Legacy into SOA (was > Vandersluis on a Data Abstraction Layer's Benefits) > > 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] com>: >> 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 <jones.steveg@ gmail.com> >> To: service-orientated- architecture@ yahoogroups. com >> 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 >>>>> >>>> >>>> >>> >>> >> >> > >
