WCF/WS as "rather lame" Client/Server Network Protocol?

WCF/WS as "rather lame" Client/Server Network Protocol?

Old forum URL: forums.lhotka.net/forums/t/959.aspx


FireGarden posted on Sunday, August 20, 2006

Rocky:

"Web Services should not (normally) be used to communicate between tiers of an application"

After reading your comment and realizing how true it is I am left a little dazed and confused. It has been acknowledged that remoting is not the best solution for remote business objects. In your book you spoke about the future support of WCF, yet you comment as follows about WCF not being a client/server protocal:

"Microsoft move further and further from allowing their SOA technologies (like web services or WCF) to provide support for what we think of as client/server"

What options do we have left for client server?

This leads to a question about an application I am building now as a "next generation" business application. For the purposes of this question I will call the application "MX Word". Its a word processing application that understands how to talk to other instances of itself (SOA).

The following companies will all purchase this application:

Company A
Company B
Company C

 The application is a smart client application allowing users from company A to create a word document and save it (from any click once enabled location).

Company B purchases the application because they are tired of getting paper copies of the MX Word documents from Company A. Now company A + B both can update and mantain a single MX Word document (possibly hosted on both servers with replication updates sent between services).

When Company B edits the MX Word document the change is persisted to its local application and the remote instance of the MX Word application hosted by company A. (Q: Client/Server techologies to consider?).

I could complicate it further by allowing company C to view and edit the document but you get the point.

In this world where document sharing passes the point of emailing attachments what happens to the lines between client/server tiers and SOA tiers?

Where would I look to find the approach to architect this kind of application? I was considering using an smtp based channel adapter as the protocal for communication between Company A and Company B. Effectivly making the BO the "message" in an SMTP based SOA.

Regards,

Rob Wheeldon

RockfordLhotka replied on Monday, August 21, 2006

I have blogged about the difference between client/server and SOA quite a bit

http://www.lhotka.net/weblog/CategoryView,category,Service-Oriented.aspx


The key point to remember is that client/server is a model where you have n tiers (each tier running one or more layers) - and these layers are logically all part of a single application. In other words, there's a relatively high level of semantic trust between the layers and thus between the tiers.

SOA is a model where you have n applications (services) - and these services are all logically independent of each other. In other words, there's little to no semantic trust between the services.

The real-world difference is that in n-tier client/server the goal is to minimize duplication of logic. If you validate or calculate a value in one layer, you try very hard not to revalidate or recalculate in some other layer. But in SO the services can not trust each other, and so if your service counts on a given value, it must validate or calculate that value - even if you know for a fact that it is also validated or calculated in some other service.

Obviously my wording there is a bit strong - but that's to get the though process rolling. Certainly it is the case that if you call a PricingService and it calculates a price, then other services won't recalculate that price as well. However, if that price is supposed to fall within certain parameters (it is a double, and must be greater than zero), every service that relies on that price should revalidate those parameters.

Why?

Because those services can't know what other services might have done to the price. Services are, by definition, decoupled. So if ServiceA calls PricingService and then passes the result to ServiceB, the fact is that ServiceB can't just assume that ServiceA didn't do something to the price value. Or that someone didn't use orchestration (through Biztalk or WF) to insert ServiceC between A and B - and then C could have altered the price in a bad way.

These issues, as a general rule, don't exist in client/server because there's this higher level of semantic trust (and also a higher level of coupling beween layers). But they absolutely exist in SO, because of the low level of semantic trust that is mandated by the lower levels of coupling.

The CSLA .NET data portal is very much an enabler of mobile objects. And mobile objects, by their very nature, are tightly coupled (you have the same objects on both sides of the network call - you can't get tighter coupling Smile [:)]). So the data portal is not a way of doing SO, and doesn't pretend to do so.

But if you read Chapter 11, you'll see that CSLA .NET does fit very nicely into an SO world. The reason is that you need to create those services - and CSLA is a great way (imo) to build services and applications that call services.

The data portal is absolutely a terrible idea between companies btw. The reason is that both companies would have to have the same DLL (same version even) on both sides. This level of cooperation between companies is almost unheard of, and isn't a constraint I'd want to impose on any enterpirse application integration (EAI) project. Message-based SO is a far superior model for EAI in my view, and so I'd recommend following that approach - very possibly creating both the services and the callers using CSLA - but passing neutral XML messages between them rather than serialized objects.

FireGarden replied on Monday, August 21, 2006

Thanks Rocky. I appreciate your time and direction. I will follow it.

Regards,

Rob Wheeldon.

p.s. I have been meaning to send you a picture of my 2005 BO book. I preordered the book and received one of the first copies to find something peculiar. Page 207 of my book has a piece of tape on it and the tape is printed on. Also the page has been folded before it was bound. I am guessing it was the first piece of paper from the roll. Anyway maybe one day I will get you to sign the book!

 

RockfordLhotka replied on Wednesday, August 23, 2006

One of my hobbies is that I collect comic books. In the comic industry such a misprint would result in a very high value comic (if it could be established that it was a printing irregularity and not the buyer being clever). Somehow I doubt that the same is true for a computer book :)
 
I'll happily sign the book given a chance - maybe you can make it to one of the conferences or events where I'm speaking at some point.
 
Rocky
 
(regarding the original reply - it is important to note that I wasn't commenting on WCF in specific. I don't think the technology itself is overly relevant other than that asmx and WCF make it easier to do message-based SO, and asmx makes it harder to do client/server. But WCF has good client/server support and there'll be a data portal channel for WCF early next year. There are some deeper changes required to CSLA .NET to make it completely support the DataContract concept though. Those changes will be part of that release as well.)
 

Thanks Rocky. I appreciate your time and direction. I will follow it.

Regards,

Rob Wheeldon.

p.s. I have been meaning to send you a picture of my 2005 BO book. I preordered the book and received one of the first copies to find something peculiar. Page 207 of my book has a piece of tape on it and the tape is printed on. Also the page has been folded before it was bound. I am guessing it was the first piece of paper from the roll. Anyway maybe one day I will get you to sign the book!

vivus replied on Saturday, August 26, 2006

i have to be a geek and ask which comics as an off topice question. 

on topic, i would have to suggest people higher up having better naming conventions than soa or even Net Framework 3.0 (.net Fx 2.0 would have been better.)  The naming confuses people in what they imply and encompass.  rocky is right that messaging is probably the way to go, keep in mind different companies do not always use MS technologies. Companies use a good deal of other technologies such as sun and so you limit your application's abilities to talk to other systems that are not running on microsoft based technologies. 

RockfordLhotka replied on Sunday, August 27, 2006

I've collected a number of things over the years, but at the moment my subscription is for all the Dark Horse Star Wars titles (which I've been collecting forever), Astro City (which rocks!), anything by JMS (creator of Babylon 5, and current author of Amazing Spider Man, Squadron Supreme, Rising Stars and misc other stuff), The Tick (again, collecting forever - since the originals). I'm also getting all the Transformers at the moment, mostly for my kids, but that's getting to be a lot now that they are building up to the movie.

JHurrell replied on Monday, August 28, 2006

RockfordLhotka:
anything by JMS (creator of Babylon 5..


Man I loved B5. I got hooked on it during the second season when I learned that he'd already had the entire arc of the show planned. I loved the idea of a show with a beginning middle and end. Not one that keeps going on and on forever with no real idea where it was going.

Any 24 fans here? That show is like crack for my wife and I and some friends we've hooked.

- John


xal replied on Monday, August 28, 2006

Ok, since the thread has clearly changed the course....

I'm a 24 fan too... I've been told that the next season will be on NY. (that was Chris Denslow, another csla / 24 fan). Smile [:)]

Andrés

FireGarden replied on Monday, August 28, 2006

Television is bad for your mental and physical health!

JHurrell replied on Monday, August 28, 2006

FireGarden:
Television is bad for your mental and physical health!


It sure is. I mean, I can't even count the numbers of times I yelled at the screen in anger about how stupid Kim Bauer was.

- John

Copyright (c) Marimer LLC