Remote Data Portal (with Remoting) vs. Remote Data Portal (with Web Services)?Remote Data Portal (with Remoting) vs. Remote Data Portal (with Web Services)?
Old forum URL: forums.lhotka.net/forums/t/1880.aspx
brembot posted on Friday, December 01, 2006
Hello All,
I'm now currently developing a web application. What would be the best approach or practices in implementing the data portal channel?
Any ideas? And also what will you recommend, remoting or webservices?
Thanks,
Marlon
jspurlin replied on Friday, December 01, 2006
Are you providing a service that needs to be platform independent? Webservices can be platform independent and serialized as xml. If I understand correctly, remoting serializes the data in binary format and sharing your data with another application might require that other application to use the same or similiar api's or technology for serialization and deserialization of a binary stream. If I understand correctly, binary serialization may be a more proprietary technology.
I am new to CSLA myself. I currently do not use webservices, until I see a need to provide a service that is not tightly integrated with my application. Service Oriented Architecture is something I am reading about, and here Webservices are king.
Service Oriented Architecture emphasises Platform Independence: you need to use standard protocols like xml, soap and WSDL. Loose Coupling (webservices make calls, do messaging (including messaging for failure conditions, message queing, etc... think of an online credit card transaction where failure isn't an option), and your services can be Discovered via a directory service like UDDI.
SOA kind of takes things of topic, but only a little bit. I would personally use webservices if these things are criteria or functional specifications relevant to your task.
Another neat thing that can be done with webservices, if you are experimenting with ATLAS, is that you can use them to "GET" instead of "HTTP POST" data. HTTP POST is the default for ATLAS or asp.net ajax. It transfers significantly more information that the "GET" method.
So another reason to take a close look at webservices, besides SOA (Service Oriented Architecture) is if you are implemented asp.ajax methods (I use Telerik controls and let them handle those details for me). But here is a "great" series of articles, "caveats", about asp.net ajax and how webservices are relevant.
http://msmvps.com/blogs/omar/archive/2006/09/22/Atlas-2_3A00_-HTTP-POST-is-slower-and-it_2700_s-default-in-Atlas.aspx
http://msmvps.com/blogs/omar/archive/2006/09/22/Atlas-1_3A00_-Try-not-to-use-page-methods.aspx
http://msmvps.com/blogs/omar/archive/2006/09/23/Atlas-3_3A00_-Atlas-batch-calls-are-not-always-faster.aspx
Hope this helps,
jspurlin
DansDreams replied on Friday, December 01, 2006
Check out Rocky's blogs on the topic too. The crux of them basically is that web services are probably not the best intranet inter-layer protocal and are better considered as a UI on top of your business layer.
I'm predicting this is going to become one of those religious wars in the .NET community when the 3.0 framework (which includes WCF) is released. From what I've seen the SOA zealots believe that remoting as we know it today is archaic and the idea of passing smart objects around is inherently wrong.
RockfordLhotka replied on Friday, December 01, 2006
I've discussed this before, but finding old links is hard.
The data portal hides all the details, so from a functional perspective it doesn't matter which channel you use: remoting, web services, enterprise services or WCF. They all work identically as far as CSLA and your code are concerned.
Enterprise Services might offer some performance benefits, but that's debatable. It does have the most complex deployment requirements, but on the upside your code runs in COM+, which is Microsoft's oldest and most stable app server platform.
Web Services only passes XML on the wire. Serialized objects are binary blobs, so that data must be base64 encoded to pass through XML. That encoding/decoding overhead, plus the increased size of the data on the wire, means web services won't perform as well as the other channels. However, some organizations insist that only web service traffic be on their networks (which I find silly), so this is sometimes the only valid option.
Remoting avoids the deployment issues of ES and offers better performance than WS, so it should be the default choice imo.
EXCEPT that .NET 3.0 has been released, and so arguably the WcfChannel should be the default choice. It has similar deployment and performance characteristics to the Remoting channel and so is an obvious successor.
If you can deploy .NET 3.0 in your environment, then I'd lean toward using the WcfChannel, otherwise I'd recommend Remoting.
Regardless, your code doesn't change due to the data portal channel you chose, so the question isn't one of functionality as much as deployment, managability and so forth.
Copyright (c) Marimer LLC
