Home > SOA Tips > Guest Commentary
SOA Tips:
EMAIL THIS
 TIPS & NEWSLETTERS TOPICS 

GUEST COMMENTARY

On the road to SOA – Part 1, Boubez on early insights


Jack Vaughan
06.17.2009
Rating: -4.00- (out of 5)


News on SOA, EAI, Web services
Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google


Toufic Boubez has been involved with SOA since its beginning. While at IBM he co-authored the original UDDI specification. He later co-founded Layer 7 technologies, where he served as CTO. At present, the ever innovative Boubez is in stealth mode. Look out world! He recently spoke with SearchSOA.com editor Jack Vaughan. This is part one of a two-part interview.

Vaughan: You have been working at services for quite a while. Since before there were services! I know you are always looking forward, but I wonder if you could take a bit to look back. I think it's useful.

Toufic Boubez: I agree. I think in SOA or IT in general it's a mistake for people not to look back and see what's happened and where they came from, at what the original goals are, and try and learn from those patterns. I don't want to say necessarily from mistakes, but from the patterns, at least, that have happened before. I totally agree with looking back.

Vaughan: UDDI was certainly a major step toward SOA. Can you recall some of your thinking around that early on?

Toufic Boubez:The reason some of my early efforts were around UDDI was because I believed that was a missing component of a natural service oriented stack. Aside from just UDDI, which I was involved with in the early years, I started the SOA group at IBM in the late 90s. The reason that's important is that a lot of the ideas came from that group. UDDI was just happened to be one thing I worked on but there were several principles we started with, and again they came from us looking back at what worked and what didn't work in the past. We definitely learned a lot from object orientation-- encapsulation, decoupling, all that kind of stuff. But object orientation had been done only at the programming level. We decided, "Well that's good for programmers, but we need to bring it one level up to architecture." Again, the same issue about decoupling and encapsulation we brought u...


Digg This!    StumbleUpon Toolbar StumbleUpon    Bookmark with Delicious Del.icio.us    Add to Google



RELATED CONTENT
Guest Commentary
Get a grip on JavaFX 1.2 for Rich Internet Applications
On the road to SOA – Part 2, Governance is fundamental
SpringSource approach to adding enterprise class management and deployment features to Tomcat
Canonical Schema establishes interoperability: SOA Pattern (Week 6)
Legacy: Can't Live With It, Can't Live Without It
Review of protocols for cloud services - Part 1
SOA and TOGAF: A Good Fit?
Using atomicity to gain SOA granularity
Too Many Servers: A Case for Enterprise Architecture and TOGAF 9
Does Cloud Computing Hold Water?

SOAP (Simple Object Access Protocol)
Progress/Actional SOA diagnostic tool builds on Mindreef purchase
InterSystems Ensemble environment adds binary SOAP messaging
User combines open source ESB with data services to speed customer reports
WSDLs get a report card
Simple Object Access Protocol (SOAP) Tutorial
Web services for Windows CE
SOA for pets uses REST and SOAP
Netrics uses SOAP to clean data
Mindreef updates SOA testing tools
The top SOA stories of 2007, part 2
SOAP (Simple Object Access Protocol) Research

SOA implementations
SOA implementation evolves from open source to Oracle SOA suite
U.S. Coast Guard adopts SOA and ESB to better track ships at sea
SOA Implementation: Should top down meet bottom up?
ESB watered down by EAI, but distinction remains
On the road to SOA – Part 2, Governance is fundamental
Sparx releases new SoaML profile for Enterprise Architect 7.5
SOA implementation: It's the increments, stupid
Bury SOA inside a larger architectural vision
Enterprise Architecture in the Agile age - Part 1, Styles of EA
'SOA is working' for Edinburgh financial company
SOA implementations Research

RELATED GLOSSARY TERMS
Terms from Whatis.com − the technology online dictionary
DIME  (SearchSOA.com)
endpoint reference  (SearchSOA.com)
SOAP  (SearchSOA.com)

RELATED RESOURCES
2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems
Search Bitpipe.com for the latest white papers and business webcasts
Whatis.com, the online computer dictionary


p one level higher.

The main issue there was interoperability. We had no way for one stack to work with another stack, for one product from one vendor to work with another from another vendor. That's where XML came in handy. People can argue the merits good or bad of XML, but what XML gave us was a bandwagon, if you want, that everybody could jump on so that software vendors could agree on something. That sort of led us down the path to what became service orientation and eventually web services. But everything we did came from taking patterns that have worked in the past, specifically from object orientation and component orientation, component architecture and object architecture.

Vaughan: And this set the stage for the SOA is dead movement!

Toufic Boubez: Well I was part of two "software revolutions." One of them was the object oriented revolution. What came out of SmallTalk was object orientation, which became a big thing. SmallTalk gave us something that is fundamental still to this day. But the lesson I drew from that is that, no matter how exciting a technology is, a good cycle for adoption takes about 10 to 15 years.

Later, again, we got all excited and to a certain extent we forgot the patterns of the past. It's going to take 10 to 15 years for the cycle to be established. Now, lo and behold we're ten years into it, about the same time frame, where at the beginning everybody thought "Alright, service orientation is going to be the next big thing in a couple years, everyone will be doing service orientation and web services." Where, in reality, just because of momentum and all kinds of established procedures and established mechanisms, it takes a while for big corporations and organizations to move. Another 10 to 15 years and here we are. I think we keep forgetting the time it takes for these cycles. That's one thing I learned from being exposed to these two big waves.

Vaughan: Where did we go with the wave?

Toufic Boubez A few years into this service oriented stuff we got sidetracked and we forgot the original principle of why we were doing it and ended up just doing just web services, which is what we were doing before in client server technologies but now doing over in XML, which made it less performant and more prone to a whole slew of issues.

So we were getting all the bad stuff without getting any of the benefits. That was unfortunate because it took several years for people to start getting out of that rut and start to realize that it's not about XML, it's not about web services, and it's not about request response, but it's about service orientation and how you build decoupled or loosely coupled systems that allow you to exchange messages back and forth. I think we're back on track now. It took us a few years to get out of that for a variety of reasons. I don't want to start blaming individual people or organizations, but I think we've gotten back on track.

Vaughan: When you say "back on track," is this REST versus SOAP that you are talking about?

Toufic Boubez: No, not necessarily. SOAP and WSDL, all those technologies, are part of the issue in that people concentrated on the technologies. But just the fact that I'm using SOAP or XML does not mean that I'm doing service oriented architecture. All I'm doing is maybe taking systems that I already built and just putting a SOAP front end in front of them. It is important to think globally about what service orienting an enterprise means. People were just slapping XML back and forth without really paying attention to what it means.

And SOAP versus REST is part of that problem, of course, because we were in the mindset of "Okay we have to use SOAP, we have to use XML" without really paying attention to the bigger picture of how to build an architecture that is loosely coupled versus how we put bits on the wire.

That degenerated into a big religious war between the SOAP camp and the REST camp which sidetracked us even further. SOAP versus REST should be a technology implementation detail.

interview with Toufic Boubez, part 2

Rate this Tip
To rate tips, you must be a member of SearchSOA.com.
Register now to start rating these tips. Log in if you are already a member.




DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.



SOA Trends and Strategy - SOA Education, SOA Development, SOA Implementations
About Us  |  Contact Us  |  For Advertisers  |  For Business Partners  |  Site Index  |  RSS
SEARCH 
TechTarget provides technology professionals with the information they need to perform their jobs - from developing strategy, to making cost-effective purchase decisions and managing their organizations' technology projects - with its network of technology-specific websites, events and online magazines.

TechTarget Corporate Web Site  |  Media Kits  |  Site Map




All Rights Reserved, Copyright 2001 - 2009, TechTarget | Read our Privacy Policy
  TechTarget - The IT Media ROI Experts