« February 23, 2004 | Main | February 25, 2004 »
February 24, 2004
Crucial Committee Meeting on SB66 Tomorrow!
The House Public Utilities and Technology Committee ( Committee Schedule) will be holding a hearing on SB66, the UTOPIA killer, Wednesday at 4pm in Room 225. If you've never attended a legislative committee meeting before, you'll enjoy this little exposure to sausage making. Its vital that the committee see a room full of UTOPIA supporters, not a room full of Qwest employees and US West retirees. Please go and support UTOPIA. If this bill passes, UTOPIA will be dead and so will Utah's chance to be a broadband leader instead of the broadband backwater that Qwest and Comcast are offering us. If you can't make the meeting, please write to you Representative and express your opinion. Calls count for more than emails. Faxes are a good compromise. Here is a list of the members of the committee. You can get their email address from the House roster.
- Rep. Stephen H. Urquhart, Chair
- Rep. Glenn A. Donnelson, Vice Chair
- Rep. Sheryl L. Allen
- Rep. Ralph Becker
- Rep. Chad E. Bennion
- Rep. Greg J. Curtis
- Rep. Brent H. Goodfellow
- Rep. Ty McCartney
- Rep. Michael E. Noel
- Rep. Gordon E. Snow
- Rep. Michael R. Styler
- Rep. David Ure
04:00 PM | Recommend This | Print This
Large Scale SOA Deployment Dramtically Increases Complexity
Independent applications before SOA is put in
place |
Service oriented architectures (SOAs) are about reuse. The goal of a service-oriented architecture is to build applications using modules that (1) look like network services, (2) are potentially very far away and (3) perhaps owned by someone else. There are some significant benefits to be had including reduced hardware expenses, fewer systems to operate and maintain, and better software reuse. All of these benefits come at the expense of significantly increased complexity. Let's see why.
The two figures to the right show schematically what can happen to add this complexity. The first figure shows five applications with their modules all operating independently. Changes to the yellow application have little impact on the operation and behavior of the other applications.
Interdependencies between applications after
SOA is put in place |
The second figure shows a similar set of applications that are interdependent because of module sharing. This is more of a problem than simply sharing beans in an EJB application where the application will be built, tested, and maintained separately. Here, because we're sharing services, rather than just code, the operation of many modules affect the overall operation of many applications. For example, the failure of the purple module in this scenario can cause all five applications to fail.
There are basically three problems:
- No one team understands or controls all the moving parts. Problems have much wider impact. As the second schematic shows, there is a big ripple effect for service failures, increased latency, security lapses, and so on.
- Change management is more complex. Parts need to be added, upgraded, fixed, and replaced on the fly with no external impact. In an SOA, expected level of service can change after its put into production. For example, we may put a module into service and then increase its expected service level when it is incorporated into a new, mission critical application.
- Separation of concerns is more difficult. Stake-holders (operations, engineering, security, lines of business) need to be able to do their jobs without having constant interaction. Traditionally, deployment is the time when all stake-holders come together. Moving to an SOA can't cause the entire business to be reorganized. For example, when a privacy policy is changed, does everyone need to get together or can just the privacy officer and operations make the change without involving development and the lines of business?
Web service intermediaries are attempting to solve some of these problems, but there is still little corporate experience with these issues on a large-scale basis and little "best practice" information is available to help companies plan for a move to an SOA.