Rockford Lhotka's Blog

Home | Lhotka.net | CSLA .NET

 Thursday, April 08, 2004

Totally unrelated to my previous blog entry, I received an email asking me about the ‘future of remoting’ as it relates to web services and SOA.

It seems that the sender of the email got some advice from Microsoft indicating that the default choice for all network communication should be web services, and that instead of using conventional tiers in applications, that we should all be using SOA concepts instead. Failing that, we should use Enterprise Services (and thus presumably DCOM (shudder!)), and should only use remoting as a last resort.

Not surprisingly, I disagree. My answer follows…

Frankly, I flat out disagree with what you've been told. Any advice that starts with "default choices" is silly. There is no such thing - our environments are too complex for such simplistic views on architecture.

Unless you are willing to rearchitect your system to be a network of linked _applications_ rather than a set of tiers, you have no business applying SOA concepts. Applying SOA is a big choice, because there is a very high cost to its application (in terms of complexity and performance).

SOA is very, very cool, and is a very good thing when appropriately applied. Attempting to change classic client/server scenarios into SOA scenarios is typically the wrong approach.

While SOA is a much bigger thing than web services, it turns out that web services are mostly only useful for SOA models. This is because they employ an open standard, so exposing your 'middle tier' as a set of web services really means you have exposed the 'middle tier' to any app on your network. This forces the 'middle tier' to become an application (because you have created a trust boundary that didn't previously exist). As soon as you employ web services you have created a separate application, not a tier. This is a HUGE architectural step, and basically forces you to employ SOA concepts - even if you would prefer to use simpler and faster client/server concepts.

Remoting offers superior features and performance when compared to web services. It is the most appropriate client/server technology available in .NET today. If you aren't crossing trust boundaries (and don't want to artificially impose them with web services), then remoting is the correct technology to use.

Indigo supports the _concepts_ of remoting (namely the ability to pass .NET types with full fidelity, and the ability to have connection-based objects like remoting's activated objects). Indigo has to support these concepts, because it is supposed to be the future of both the open web service technology and the higher performance client/server technology for .NET.

The point I'm making, is that using remoting today is good if you are staying within trust boundaries. It doesn't preclude moving to Indigo in the future, because Indigo will also provide solutions for communication within trust boundaries, with full .NET type fidelity (and other cool features).

Web services force the use of SOA, even if it isn't appropriate. They should be approached with caution and forethought. Specifically, you should give serious thought to where you want or need to have trust boundaries in your enterprise and in your application design. Trust boundaries have a high cost, so inserting them between what should have been tiers of an application is typically a very, very bad idea.

On the other hand, using remoting between applications is an equally bad idea. In such cases you should always look at SOA as a philosophy, and potentially web services as a technical solution (though frankly, today the better SOA technology is often queuing (MQ Series or MSMQ), rather than web services).

 

Thursday, April 08, 2004 7:13:51 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 

A number of people have asked me about my thoughts on SOA (service-oriented architecture). I have a great deal of interest in SOA, and a number of fairly serious thoughts and concerns about it. But my first response is always this.

 

The S in SOA is actually a dollar sign ($OA).

 

It is a dollar sign because SOA is going to cost a lot of people a lot of money, and it will make a lot of other people a lot of money.

 

It will make money for product vendors, as they slap the SOA moniker on all sorts of tools and products around web service creation, consumption and management. And around things like XML translators and transformers, and queue bridging software and transaction monitors and so forth. Nothing particularly new, but with the SOA label, these relatively old concepts become fresh and worthy of high price tags.

 

It will make money for service vendors (consultants) in a couple ways.

 

The first are the consultants that convince clients that SOA is the way to go – and that it is big and scary and that the only way to make it work is to pay lots of consulting dollars. SOA, in this world-view, involves business process reengineering, rip-and-replace of applications, massive amounts of new infrastructure (planning and implementation) and so forth.

 

The second are the consultants who come in to clean up after the first group make a mess of everything. This second group will also get to clean even after many clients who didn’t spend on big consulting dollars, but bought into the product vendors’ hype around SOA and their quasi-related products.

 

Who loses money? The clients who buy the hyped products, or fall for the huge consulting price tags due to FUD or the overall hype of SOA.

 

Since I work in consulting, SOA means dollars flowing toward me, so you’d think I’d be thrilled. But I am not. This is a big train wreck just waiting to derail what should be a powerful and awesome architectural concept (namely SOA).

 

So, in a (most likely vain) effort to head this off, here are some key thoughts.

 

  1. SOA is not about products, or even about web services. It is an architectural philosophy and concept that should drive enterprise and application architecture.

  2. SOA is not useful INSIDE applications. It is only useful BETWEEN applications.

    If you think you can replace your TIERS with SOA concepts, you are already in deep trouble. Unless you turn your tiers into full-blown applications, you have no business applying SOA between them.

  3. Another way to look at #2 is to discuss trust boundaries. Tiers within an application trust each other. That’s why they are tiers. Applications don’t trust each other. They can’t, since there’s no way to know if different applications implement the same rules the same ways.

    SOA is an idea philosophy and concept to help cross trust boundaries. If you don’t cross a trust boundary, you don’t want SOA in there causing complexity. But if you do cross a trust boundary, you want SOA in there helping you to safely manage those trust and connectivity issues.

  4. To turn #3 around, if you are using SOA concepts, then you are crossing a trust boundary. Even if you didn’t plan for, or intend to insert a trust boundary at that location in your design, you just did.

    The side-effect of this is that anywhere that you use SOA concepts between bits of code, those bits of code must become applications, and must stop trusting each other. Each bit of code must implement its own set of business rules, processing, etc.

    Thus, sticking SOA between the UI and middle tiers of an application, means that you now have two applications – one that interacts with the user, and one that interacts with other applications (including, but obviously not limited to your UI application). Because you’ve now inserted a trust boundary, the UI app can’t trust the service app, nor can the service app trust the UI app. Both apps must implement all your validation, calculation, data manipulation and authorization code, because you can’t trust that either one has it right.

    More importantly, you can’t trust that FUTURE applications (UI or service) will have it right, and SOA will allow those other application to tap into your current applications essentially without warning. This, fundamentally, is why inserting SOA concepts means you have inserted a trust boundary. If not today, in the future you WILL have untrusted applications interacting with your current applications and they’ll try to do things wrong. If you aren’t defensive from the very start, you’ll be in for a world of hurt.

 

In the end, I think the trust boundary mindset is most valuable guide for SOA. Using SOA is expensive (in terms of complexity and performance). It is not a price you should be willing to pay to have your UI talk to a middle tier. There are far simpler, cheaper and faster philosophies, concepts and technologies available for such interaction.

 

On the other hand, crossing trust boundaries is expensive and complex all by itself. This is because we have different applications interacting with each other. It will always be expensive. In this case, SOA offers a very nice way to look at this type of inter-application communication across trust boundaries, and can actually decrease the overall cost and complexity of the effort.

 

Thursday, April 08, 2004 9:27:35 AM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [0]  | 
On this page....
Search
Archives
Feed your aggregator (RSS 2.0)
October, 2014 (1)
August, 2014 (2)
July, 2014 (3)
June, 2014 (4)
May, 2014 (2)
April, 2014 (6)
March, 2014 (4)
February, 2014 (4)
January, 2014 (2)
December, 2013 (3)
October, 2013 (3)
August, 2013 (5)
July, 2013 (2)
May, 2013 (3)
April, 2013 (2)
March, 2013 (3)
February, 2013 (7)
January, 2013 (4)
December, 2012 (3)
November, 2012 (3)
October, 2012 (7)
September, 2012 (1)
August, 2012 (4)
July, 2012 (3)
June, 2012 (5)
May, 2012 (4)
April, 2012 (6)
March, 2012 (10)
February, 2012 (2)
January, 2012 (2)
December, 2011 (4)
November, 2011 (6)
October, 2011 (14)
September, 2011 (5)
August, 2011 (3)
June, 2011 (2)
May, 2011 (1)
April, 2011 (3)
March, 2011 (6)
February, 2011 (3)
January, 2011 (6)
December, 2010 (3)
November, 2010 (8)
October, 2010 (6)
September, 2010 (6)
August, 2010 (7)
July, 2010 (8)
June, 2010 (6)
May, 2010 (8)
April, 2010 (13)
March, 2010 (7)
February, 2010 (5)
January, 2010 (9)
December, 2009 (6)
November, 2009 (8)
October, 2009 (11)
September, 2009 (5)
August, 2009 (5)
July, 2009 (10)
June, 2009 (5)
May, 2009 (7)
April, 2009 (7)
March, 2009 (11)
February, 2009 (6)
January, 2009 (9)
December, 2008 (5)
November, 2008 (4)
October, 2008 (7)
September, 2008 (8)
August, 2008 (11)
July, 2008 (11)
June, 2008 (10)
May, 2008 (6)
April, 2008 (8)
March, 2008 (9)
February, 2008 (6)
January, 2008 (6)
December, 2007 (6)
November, 2007 (9)
October, 2007 (7)
September, 2007 (5)
August, 2007 (8)
July, 2007 (6)
June, 2007 (8)
May, 2007 (7)
April, 2007 (9)
March, 2007 (8)
February, 2007 (5)
January, 2007 (9)
December, 2006 (4)
November, 2006 (3)
October, 2006 (4)
September, 2006 (9)
August, 2006 (4)
July, 2006 (9)
June, 2006 (4)
May, 2006 (10)
April, 2006 (4)
March, 2006 (11)
February, 2006 (3)
January, 2006 (13)
December, 2005 (6)
November, 2005 (7)
October, 2005 (4)
September, 2005 (9)
August, 2005 (6)
July, 2005 (7)
June, 2005 (5)
May, 2005 (4)
April, 2005 (7)
March, 2005 (16)
February, 2005 (17)
January, 2005 (17)
December, 2004 (13)
November, 2004 (7)
October, 2004 (14)
September, 2004 (11)
August, 2004 (7)
July, 2004 (3)
June, 2004 (6)
May, 2004 (3)
April, 2004 (2)
March, 2004 (1)
February, 2004 (5)
Categories
About

Powered by: newtelligence dasBlog 2.0.7226.0

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

© Copyright 2014, Marimer LLC

Send mail to the author(s) E-mail



Sign In