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.