Hoi Borjan, 
 
Goed stuk!. Ben blij dat ik regelmatig op deze website kijk. 
In het kader van het kennismanagement, waar wij beiden zo verknocht aan zijn, zou het goed zijn als je deze paper met onze collega's deelt. Dat is niet afhankelijk van een goede instrument maar van (de wil om) gebruik (te maken) van beschikbare communicatiemiddelen. Volgens mij kijken onze collega's namelijk niet zo vaak op deze website. je zou ook kunnen melden dat je dit artikel op via nova architecture hebt geplubliceerd. 
groetjes, 
Mary

Ja, prima stuk. Nog iemand die hier regelmatig eens komt kijken ;-).

Borjan, 
 
An interesting article indeed. I can indeed also recommend the Thomas Erl site: http://www.soapatterns.com/. I am looking forward to the patterns you and others in Via Nova Architectura will publish. 
 
I have one question with respect to a statement you make: "Please note here that significant numbers of integration solutions were service oriented much before the term ‘Service Oriented Architecture’ has been introduced." Could you please elaborate on that. Are you saying that these integration solutions were for business which were themselves service oriented? 
 
With kind regards, 
 
Richard

Richard, 
I apologize for not reacting more promptly; have been on vacation for two weeks … 
The SOA precursors I'm referring to are solutions that were produced at some large telecom firms. Saying this, I'm not excluding other efforts that have led to SOA – it is merely that I do know about some and not about others. 
Anyway, the integration solutions created in two projects I’ve been involved with (both started before the acronym SOA came to life) have been entirely service oriented, so I’ll elaborate on those. Again, there have been others, for sure. SOA is a pattern, and patterns come to life evolutionary. 
One of the business problems has been how to facilitate product delivery via own outlet stores and later via outlet stores AND other channels like call centers and intermediate retailers. The customer database, stock inventory (phones, other devices, cables, …), billing, workforce planning etc, all these systems were required to be accessible from the call centre application and the applications supporting the outlet store employees (having employees accessing each system separately has been causing serious problems).  
In the projects I’ve been involved, the systems were interacting via Tuxedo (http://en.wikipedia.org/wiki/Tuxedo_(software)) on-line messaging and the Tuxedo environment has been extended by a number of custom made adapters (hub-and-spoke integration style). Additionally, to make the solution sustainable, the interfaces were controlled centrally, on the enterprise level. This was accomplished by augmenting the technique of Tuxedo through introduction of formal contracts conforming to the guidelines of the OSCA architecture of Bellcore. 
OSCA proscribed contracts between ‘building blocks’ of the solution. The contracts were specifying the formal interfaces (parameters) but also preconditions, post-conditions, semantics and the QoS aspects of interactions. Of course, there were neither open standards nor commercial products to support this (XML wasn’t there, for example). Nonetheless, the loose coupling of Tuxedo augmented by the contract formalism of OSCA worked well in practice. 
To me, OSCA was really visionary. Most unfortunately, the successor of Bellcore, Telcordia, does not allow free access to any, even really old and most likely commercially obsolete documents. Some OSCA articles may be illegally available on Internet (like the article from 1990, ‘The OSCA™ Architecture, Enabling Independent product software maintenance’). Someone interested into that piece of SOA history should visit the Telcordia Technical Document Center and then check ‘Distributed Interoperable & Operable Computing Environment and Systems (DIOCES)’ (http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=268164543SEARCH& KEYWORDS=Distributed+Interoperable+%26+Operable+Computing+En vironment+and+Systems+(DIOCES)&TITLE=&DOCUMENT=&DATE=&CLASS=PS42&COUNT=1000#TR). There you can find documents like ‘OSCA(TM) Contract Specification Guidelines’ etc.

Beste Borjan, 
 
Ik wil je complimenteren met dit non hand waving in depth expertise value adding article. That's all. 
 
Dank en groet, 
Raoef.