The Good, the Bad, and the Ugly of Service-Oriented Architecture
page 4 of 7
by Tom Fuller
Average Rating: 
Views (Total / Last 10 Days): 38846/ 82

The Good

Service orientation via web services can often be the best approach for enabling core business processes. The most important aspect to finding the SO sweet spot is determining what can be reused. Services are often considered application building blocks. With that comes a great responsibility for the application visionaries. There is a natural time during an application’s envisioning when service boundary identification can be done by those that best understand what business processes can be reused.

If these services are envisioned and designed with the enterprise in mind, and not the specific application being envisioned, there is a good chance that a reusable service will be delivered. There are a lot of inherent risks here too. You have to involve the right resources for auditing those services which are thought to be reusable. Typically in a large enterprise there could be other projects that have either already started or already built a large portion of that same service.

Loosely-coupled, reusable services have a number of other obvious benefits. That is if the services are designed using the four service-oriented tenets listed here:

1.     Boundaries are explicit: This means that we make no assumptions about what is behind an SO boundary. We cross service boundaries intentionally to use a service that would most likely be usable by more than just our application. These boundary crossings are expensive and should be done only when necessary. It is tempting to do this as a standard architectural approach with the hopes that a library of services will become a reality by accident. Architecture never happens by accident, service boundaries being explicit is the most important tenet to understand and abide by.

2.      Services are autonomous: This is self explanatory really; autonomy, by definition, means self-governing or stand alone. This becomes important when you start to look at services that are defined based on the needs of a specific system or interface. When services can not be independently built, versioned, and deployed, they are destined to fail in the long run. Without careful adherence to this tenet, services will never reach their potential for reuse or longevity.

3.      Services share schemas and contracts, not classes and types: This speaks to the platform neutrality of services. All services are designed to exchange contracts for behavior and schemas for data structure. Avoiding type system dependency is what ensures interoperability.

4.      Compatibility is policy-based: Policies define the constraints for accessing the service. This allows services to define a mechanism for communicating no matter what their current capabilities are. This guarantees that services will always be capable of negotiating a set of rules for communication. As services begin to provide enhanced capabilities like transaction flow and reliable messaging, a policy can still be defined that will allow first generation ASMX services to talk text-based XML over HTTP.

When the design strategies for delivering services keep these tenets in mind, they can realize many benefits. Portability of the individual parts of an application is inherent because of the neutral nature of the transport channel. Each of these parts is also individually scalable. Services can also see a huge gain in maintainability and extensibility because of their centralized nature. Services are also potentially durable, reusable core components in enterprise architectures.

There are some other great reasons to look at implementing service-oriented architectures today. One reason is that it provides the ability to extend the investment of the legacy components in your architecture. I love the saying: “If it ain’t broke … front end it.” Implementing a service-oriented front end for a legacy system will expose that same business logic to an entirely new generation of applications. This does come with risks, but if those legacy systems you intend to expose via service orientation are carefully tested, there is a great opportunity for renewed ROI.

Another great implementation of service orientation is often referred to as shared state or workflow-type applications. The best example I can think of is a loan application. If that loan might have a number of different states that numerous applications would act upon during its lifespan, then you will most likely benefit greatly from a service-oriented approach.

The obvious scenarios still apply as well. When you have a need for interoperability, service orientation has obvious benefits. If you need to expose your application’s business logic to a brand new front end hosted on a disparate platform, SOA provides exceptional ROI.

View Entire Article

User Comments

Title: Project   
Name: Dude MaN (for protection)
Date: 2007-10-11 10:07:28 AM
hey i am doing a report on the pro and cons on Architecture can u help me.
Title: RE: Great article, but Moore's Law?   
Name: Tom Fuller
Date: 2005-09-01 10:00:55 PM
Just realized I was cut off when I posted my response. Sorry for taking so long to notice......

I think we'll see in the future that if the services that are intended to stand the test of time are delivered as tightly coupled portions of a business application then those services will in the long run lose any level of autonomy (which would be another one of those tenets).

This has been at the heart of almost every discussion I've had with people about SOA lately and I plan to write another article in the upcoming weeks titled "SOA Design Strategies: Adhering to the 4 Tenets". This will go into detail on these very issues we are discussing.

Thanks again for taking a look at my article and I appreciate your criticism.
Title: RE: Great article, but Moore's Law?   
Name: Tom Fuller
Date: 2005-08-30 10:05:45 PM
Thank you for the feedback. I have to admit the loose application of Moore's Law in the article has come under some crticism. What I will say is that I did not intend to say poor design was justified through my use of Moore's law in the article. I really wanted to use it more as a high level comparison to show that there is little to no doubt that the capabilities of our hardware and infrastructure will only continue to increase. It is that increase that could neutralize any of these minor performance concerns with SOAP based transports and message serialization. This does not mean that you can completely dismiss performance concerns today but SOA will continue to focus on delivering loosley coupled systems that can last longer than the applications we delivered in the past. That in my mind means we should consider the potential capabilities of the network and the hardware that these systems will depend on.

The rest of your comments seem to focus on the design issues surrounding service orientation and they are certainly valid. It is too often the case that common layered architectures fall into the trap of future proofing everything that is built because of the constant pains associated with versioning. This comes back to an issue of agility in your software delivery process. I know this is easier said than done but, the fact remains, if there was no concern that services could be delivered outside of the natural release schedule of an application then you could avoid this "Field of Dreams" approach you talk about.

You have also made a very powerful statement below and that was, "some sort of agreement on what the service is all about should be reached". This covers two of the critically important tenets of SO. You are talking about boundaries being explicit here and that services exchange contracts and schema not objects and types. I think we'll see in the future that if the services that are intended to stand the test of time are delivered as ti
Title: Great article, but Moore's Law?   
Name: TravelMonkey
Date: 2005-08-29 12:25:20 AM

A great article overall!

However, I was a bit dismayed by the fact that you seem to use Moore's Law (or a variant thereof) as a scapegoat to allow for poor performance today. I may be stretching what you said a bit, but you seem to imply that somewhat adequate performance from SOA is OK today, because Moore's Law will take effect and in 18 months things will be better.

Has Moore's Law been extended to include networks now? I have not done the math, but I would say it's a reach to say that it has held true for our bandwidth.

At any rate, I would advocate creating the best performing design and code you can today, and leave Moore's Law as a nice theory, not an excuse if you can't make good performing code. SOA doesn't NEED to be poorly performing, though I think poorly written web services have doomed it with that stigma at times, to some purists. I think an "outside the firewall" scenario does allow for some "slop" in the code, as one expects slower performance out in the cloud due to network latencies beyond our control. However, for an intranet app, the SOA needs to scream. Internal users are far less forgiving of slow performance.

I also don't think SOA implies poor performance--I think poor design implies poor performance. Spend some of the expense of SOA on ensuring your design meets good performance standards from the beginning; you'll save money in the long run by making apps that perform today.

I think another potential money pit that needs to be examined is to ensure that you don't get bitten by the "Field of Dreams" scenario. You know--"If you build it, they will come." I don't feel that SOA is about that. Make sure service consumers are in place (a real need is identified) and that some form of contract is in place. I'm not necessarily advodating contract-first, but some sort of agreement on what the service is all about should be reached.

Your article is a great overall view of SOA, I think. Well done.

Title: Nice article   
Name: user
Date: 2005-08-25 2:50:40 PM
Really nice condeptual article. Can you give real time example where some company is already using SOA.


Product Spotlight
Product Spotlight 

Community Advice: ASP | SQL | XML | Regular Expressions | Windows

©Copyright 1998-2024  |  Page Processed at 2024-07-25 11:05:05 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search