One Technology Does Not Fit All SOAs

Loraine Lawson

Monday, I shared an article in which Accenture CTO Donald Rippert outlined four phases of implementing service-oriented architecture:

  1. Using XML as an interface.
  2. Making legacy systems available as Web services.
  3. Using an ESB (enterprise service bus) to connect Web services and use composite processes.
  4. Using BPEL (Business Process Execution Language), which he notes will make it possible to change a business application by changing the process model rather than the code.

I know that not all SOAs use Web services, that there are alternatives to an ESB and that BPEL -- well, that's a whole Pandora's box of disagreement. But I read these as sort of typical evolutionary stages most people go through. As in, it's typical for companies to try at one point to do it all with Web services, then add the ESB.


But Rippert's use of those particular technologies to describe the phases really bothered SOA consultant and ZapThink managing partner David Linthicum. In fact, this week, Linthicum used his weekly InfoWorld podcast to outline exactly why he's bothered by this list.


He begins by agreeing with Rippert's initial point that people are doing the first couple of steps for SOA -- primarily, building out Web services, and then not driving it to the next level. But he heartily disagreed that it's necessary to use Web services, ESBs or BPEL at any phase of your SOA.


He started with the Web services phase. No doubt about it -- Web services can play a key role in a SOA. It's the enabling standard for externalizing services out of existing systems, Linthicum said. But sometimes, it just doesn't fit the bill and you need to use J2EE or even a proprietary system.


SOA's layers shouldn't be defined by specific technologies or standards, he counters. You can't buy an ESB or decide to use a standard and then make it work no matter what.

That's just completely silly and you'll end up building something that ultimately is not going to be effective or efficient for the architectural issues you're looking to solve.

Instead, you need to look at your requirements first and then choose a technology that will address those needs. If you're not sure what some of those alternatives might be, listen to the podcast -- Linthicum offers several alternatives for each phase.

At the end of the day this is architecture. Architecture is going to take some analysis and understanding before you figure out what technology and standards and patterns you need to toss at the solution.

This may not be easy to do -- you may need to hire additional help, either by finding a consultant or creating a staff enterprise architecture position, if you don't have one.


In November, I asked Linthicum how companies can find qualified SOA consultants. He suggested you find a qualified architect who can guide your SOA implementation. He recommended you look for an experienced architect with a non-vendor certification -- ZapThink offers such as a program, as does The Open Group.


But, as Linthicum warned in his podcast, the costs of choosing the wrong technologies and standards are high.

... At the end of the day if you don't make correct decisions, you're going to end up with an architecture that's not as efficient as it could be and therefore it's not able to perform as well, it's not going to be as changeable, it's not going to be agile and it's going to fall short based on the investment dollars you put into it. And you don't want to be that guy.

Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jan 4, 2008 3:51 PM adana oto kiralama adana oto kiralama  says:
hello.. thanks ;) Reply
Jan 4, 2008 3:53 PM mersin web tasar�m mersin web tasar�m  says:
hello.. thanks ;) Reply
Jan 17, 2011 10:07 AM dramil dodeja dramil dodeja  says: in response to mersin web tasar�m

JSF for nonbelievers: The JSF application lifecycle

The JSF lifecycle: an overview

The six phases of the JSF application lifecycle are as follows (note the event processing at each phase):

1.     Restore view

2.     Apply request values; process events

3.     Process validations; process events

4.     Update model values; process events

5.     Invoke application; process events

6.     Render response

The six phases show the order in which JSF typically processes a form GUI. The list shows the phases in their likely order of execution with event processing at each phase, but the JSF lifecycle is hardly set in stone. You can change the order of execution by skipping phases or leaving the lifecycle altogether. For example, if an invalid request value were copied to a component, the current view would be redisplayed, and some of the phases might not execute. In this case, you could issue a FacesContext.responseComplete method invocation to redirect the user to a different page, then use the request dispatcher (retrieved from the request object in the FacesContext) to forward to an appropriate Web resource. Alternately, you could call FacesContext.renderResponse to re-render the original view. (See the sample application below for details.)

Some developers using JSF may never write a component or extend the framework, while others may focus on just those tasks. While the JSF lifecycle will be the same for almost any project, you'll likely tap into it at different stages based on your role in the project. If you're concentrating more on the overall application development, you'll likely be concerned with the middle phases of the request processing lifecycle:

.     Apply requests values

.     Process validations

.     Update model values

.     Invoke application

If you're concentrating on JSF component development, you'll probably focus on the first and last phases of the lifecycle:

.     Restore view

.     Render response

In the sections that follow, I'll walk you through every phase of the JSF request processing lifecycle, including event handling and validation. Once you have a basic understanding of each phase, I'll introduce a sample application that shows how they all come together. Before we get started, take a look at Figure 1, a diagram of the JSF lifecycle.



Dramil Dodeja










Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.