- Introducing Windows Presentation Foundation
- Understanding Workflow in Windows SharePoint Servi...
- Opinari #16 Posted: SOA and the Reality of Reuse
- The Real Threat to Java EE
- Introducing the .NET Framework 3.0
- Doubting the Long Tail
- Standardizing the Right Thing: BPMN or BPEL?
- Why BPEL is Like Bytecode
- On Defining "Workflow"
- Introducing InfoCard
Opinari
Subscribe
Responses to SOA and the Reality of Reuse
# Friday, September 29, 2006
I've been surprised by the responses I've seen to my latest Opinari. I expected more people to disagree with me, defending the promise of service reuse. What I've seen instead is general (and sometimes enthusiastic) agreement. Even the comments on Joe McKendrick's ZDNet entry were largely in agreement, although I'm not sure Joe himself shares my perspective.
Microsoft's Harry Pierson wrote an interesting response on the importance of context in reuse, something I fully agree with. His observation that reuse with services might well be more difficult to achieve than it was with objects also rings true, since the requirement for remote access to services does raise the bar. David Ing also wrote a useful response, raising some excellent points about why reuse is valuable primarily for services that expose data.
For a view from the other side, I had a chance to talk recently with the author Thomas Erl. We both presented at Gartner's Application Development Summit this week, and Thomas is significantly more bullish on the potential for reuse. As I understand it, his view (based on experience gained from his firm's consulting work) is that if an organization does an appropriate top-down analysis of a well-defined business domain, it's quite possible to discover and implement reusable services. This is a good argument, and I'm willing to believe that there are cases where this kind of analysis-led reuse can work.
What's harder for me to believe is that a majority of organizations will be able to do this. Instead, I've come to expect most efforts to take a more technically oriented bottom-up approach. Given that the coming wave of vendor platforms will all but force us to build service-oriented applications, it will be hard to avoid at least this much SOA.
Will this simpler, less ambitious approach offer all of the benefits claimed for SOA? Certainly not. But is it an improvement over the world we live in today? Just as certainly, the answer is yes. Like objects, services won't provide everything promised by their most fervent exponents. Nonetheless, this shift counts as a step forward.
3 comments :: Post a Comment
Comments:
When I read the opinar I didn't understand your point talking about reuse and SOA in the same sentense so I responded with this.
In my world SOA comes from the frustration with applications built up as a silos of data and hard coupled parts. IMHO the goal with SOA is to break down the silos into compositions of services.
Compositions uses services not for the sake of reuse, but from the possibility to virtualize on functionality and be able to reconstruct the application from one point to another without rebuilding and deploying a new version of the application.
Rebuilding classic non-SOA applications comes with development costs, consultant costs, migration costs, long time frame, etc.
I would say reusability is the opposite to agility since reuse results in coupling, which agility tries to oppose.
Also, I would like to ask you how agility is "just another form of reuse" (as you write in your opinar)?
-Jonas
In my world SOA comes from the frustration with applications built up as a silos of data and hard coupled parts. IMHO the goal with SOA is to break down the silos into compositions of services.
Compositions uses services not for the sake of reuse, but from the possibility to virtualize on functionality and be able to reconstruct the application from one point to another without rebuilding and deploying a new version of the application.
Rebuilding classic non-SOA applications comes with development costs, consultant costs, migration costs, long time frame, etc.
I would say reusability is the opposite to agility since reuse results in coupling, which agility tries to oppose.
Also, I would like to ask you how agility is "just another form of reuse" (as you write in your opinar)?
-Jonas
True: "the reuse of business objects failed."
False: "the barriers to pervasive reuse of business logic remain high."
Discussion (or click through my name above for the 16/10/2006 post):
http://weblogs.asp.net/erobillard/archive/2006/10/16/Object-Reuse_2C00_-David-Chappell_2C00_-and-the-Rule-of-the-Least-Common-Denominator.aspx
False: "the barriers to pervasive reuse of business logic remain high."
Discussion (or click through my name above for the 16/10/2006 post):
http://weblogs.asp.net/erobillard/archive/2006/10/16/Object-Reuse_2C00_-David-Chappell_2C00_-and-the-Rule-of-the-Least-Common-Denominator.aspx
# posted by 
: October 16, 2006 10:21 AM
: October 16, 2006 10:21 AM
All these young turks fretting over reuse. (sigh)
If you have worked in computer science as long as I have (35 years) you will have seen that "reuse" has been a holy grail in every era and always comes up short. Subroutines, functions, libraries, modules, classes, components, distributed versions of all of the previous, and now "services".
The problems are always the same:
* knowing how to make something reusable (which only happens with feedback from multiple attempts to reuse each particular component)
* knowing where to find components which are reusable, and knowing
what those components do (which means doing the detailed clear type
of documentation that never seems to get done)
* and most importantly, it is simply more easy (dare I say fun) to
develop from scratch than to find, learn, debug, refactor, existing
"reusable" components written/controlled by someone else.
* OH, and dont let me forget! People have the whole notion of "components" (aka services) backwards...FRAMEWORKS are what must be reusable and reused. Components dont exist! In the same way that donut holes dont exist. Frameworks are the donuts which define the holes/components. As long as people think about components in isolation, all of the above problems are made worse
Post a Comment
If you have worked in computer science as long as I have (35 years) you will have seen that "reuse" has been a holy grail in every era and always comes up short. Subroutines, functions, libraries, modules, classes, components, distributed versions of all of the previous, and now "services".
The problems are always the same:
* knowing how to make something reusable (which only happens with feedback from multiple attempts to reuse each particular component)
* knowing where to find components which are reusable, and knowing
what those components do (which means doing the detailed clear type
of documentation that never seems to get done)
* and most importantly, it is simply more easy (dare I say fun) to
develop from scratch than to find, learn, debug, refactor, existing
"reusable" components written/controlled by someone else.
* OH, and dont let me forget! People have the whole notion of "components" (aka services) backwards...FRAMEWORKS are what must be reusable and reused. Components dont exist! In the same way that donut holes dont exist. Frameworks are the donuts which define the holes/components. As long as people think about components in isolation, all of the above problems are made worse
# posted by : October 24, 2006 7:15 AM
: October 24, 2006 7:15 AM
<< Home