Home arrow Web Services arrow Page 3 - Forget the DCOM Pain and Use Remoting or Web Services
WEB SERVICES

Forget the DCOM Pain and Use Remoting or Web Services


In this latest article, Ahm introduces us to the differences between DCOM and .NET Remoting, as well as the benefits of using .NET Remoting for your Web Services needs.

Author Info:
By: Ahm Asaduzzaman
Rating: 5 stars5 stars5 stars5 stars5 stars / 22
September 29, 2003
TABLE OF CONTENTS:
  1. · Forget the DCOM Pain and Use Remoting or Web Services
  2. · Questions
  3. · Questions
  4. · Conclusion

print this article
SEARCH DEVARTICLES

Forget the DCOM Pain and Use Remoting or Web Services - Questions
(Page 3 of 4 )

Which Marshalling is Better for Me?

The better rule is the technique, which places fewer demands on the transport between servers and clients. With Marshal by value you need to copy the whole object to the client.  With large sized objects the communication overhead is significant. With marshal by reference, it does not require a copy of the entire object, it requires either one-way or round-trip information; this may put huge demand on transportation. The best practice is to do some performance testing to aid the decision. Which activation model is superior? Single call or Singleton, read about these issues here.

What Are Those Activation Models in .NET Remoting? And Which One is the Better Choice?

 Client-Side Activation ModelServer-Side Activation Model 
 When the client is allowed to pass parameters to the constructor of a remote object when it gets created. Client activated models correlate calls from the same user and they maintain state per client. This is the closest parallel to the classic DCOM activation model. The object will be subject to garbage collection once it's determined that no other clients need it. In this model, clients control lifetime lease (DCOM uses ping to maintain lifetime which is inefficient in terms of bandwidth and processors cycles)

 Single Call: each remote method call into the server will create a new instance of the object on the server which means there will be no state kept for that object on the server between method calls. This is more like Web Services. This model is easy to implement and highly scalable.

Singleton: Singleton types have only one instance of an object at any time. All client requests are serviced by that single instance. This allows you to "share" data between requests or, more likely, maintain state between requests. Threading can be a pain in this model; scalability can be the biggest challenge. If workload is not big and performance is not an issue, use this model. In other words, if response time is not an issue but server memory is an issue, use this model of activation. Default lifetime of the object is 5 minutes; however, you can override it.

What is a Channel? Do I Need to Recompile My Application if I Change Channels?

A channel is an object that implements communication between objects across the Application Domain. In the .NET framework there are two default channel classes: HTTPChannel class that uses HTTP protocol and formats messages using SOAP protocol and encodes communication as XML, TcpChannel Class uses TCP protocol and uses binary format for messages. Microsoft .NET is architected in such a way that remotable components can change channels without being recompiled. You can place the channel information in a configuration file and change from TCP to HTTP or vice versa without recompiling the application. Similarly, you can change a configuration file for the client to match the channel that the host is using. In addition, the TcpChannel or HTTPChannel can be extended, or a new channel created if you determine the existing channels do not meet your needs.

Microsoft is currently working on another type of channel, which is called In Memory channel (IPC type channel).

Can .NET Remoting Be Used to Communicate with PHP NuSOAP?

The answer is No and maybe YES. You can build Web Services with .NET Remoting, anyone will be able to use it (who is not using .NET Remoting, but uses other Web Services toolkits, for example PHP NuSOAP), if we can describe the endpoint to bare data types and semantics, we are also restricted to use .NET framework types and we must avoid client activated objects and events. In that situation, why not build Web Services for interoperability with PHP?

You might have read that using .NET Remoting with the SOAP formatter opens the doors of interoperability. This is not true. The SOAP formatter (despite its name) is CLR–centric and not XML Schema–centric. This means that only the Windows-based systems out there are capable of understanding your .NET Remoting XML payload.

What About the Security and Performance Issues in .NET Remoting?

When you move your data across the wire, security is the most important issue. So, what does 'security' mean? This is the process of authentication, which is determining who the caller is. Authentication is about proving that you are who you say you are, in other words, it should be certain that the caller is who he says he is.

To apply a protection from unauthorized sniffing and tampering, data must be encrypted.  How does authentication work in a Remoting scenario?

DCOM has a good security infrastructure. Click->Start and type dcomcnfg. Play with it, use the context sensitive help to understand what the settings all mean.  It is also good for understanding what is exposed on your system. COM+ adds an additional application-level security mechanism: role-based security (do not confuse with .NET role-based security).

There is no built-in security in .NET Remoting. You can use Internet Information Services (IIS) as the hosting process for your Remoting services to be exposed. So you can use IIS security features, authorization such as Basic, digest, digital certificates etc. and HTTPs (guarantees privacy integrity and server authentication), but it has set backs; you can use only the HTTP channel (instead of the faster binary formatter over the TCP channel).  .NET Remoting does not secure cross-process calls.

Note, that if you are using a TCP or HTTP channel in a process outside IIS, then you will need to implement your own authorization and authentication mechanism.

Now lets draw a conclusion from this discussion.  In terms of raw performance, .Net Remoting provides the fastest communication when using the TCP channel with the binary formatter. Tests have shown that Web Services outperform .NET Remoting for endpoints that used SOAP formatter with either the HTTP or TCP channel.  If you never foresee the need to “talk” to non-Microsoft systems, a pure .NET Remoting infrastructure will provide performance benefits that you simply can’t achieve with a SOAP-based infrastructure. Read this article, which provides a good starting point to get deeper into these related technologies. You can also attend the web seminar by Russ Ruggia.

How to Draw a Comparison Analysis Between These Distributed Computing Approaches

 Web Services .NET RemotingDCOM 
 Hosted by Only Web servers  
 Uses only HTTP:// protocol

Any Application
    IIS
    WinForms
Windows Services
Console Applications
Supports Multiple Protocols
HTTP://
Tcp://

Custom 

 -RPC style protocol and tightly coupled.
-Not firewall friendly
-Pings for lifetime
Uses WSDL to expose to external requestsSOAP or Binary  


blog comments powered by Disqus
WEB SERVICES ARTICLES

- Dealing with Loose Coupling in a Service-Ori...
- Loose Coupling in a Service-Oriented Archite...
- Safety, Idempotence, and the Resource-Orient...
- The Resource-Oriented Architecture in Action
- Features of the Resource-Oriented Architectu...
- The Resource-Oriented Architecture
- Getting Started with Flex
- Automated Billing and Faxing for the Web
- An Introduction to Web Services
- The Foundations of Web Services: From Novice...
- Web Services Reengineering: Finishing Touches
- Fault Handling with Web Services
- Flow and Web Services
- Process Lifecycles and Web Services
- Business Processes and Web Services

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2017 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials