Smart Services
When it was first released in 2003, Remoting SDK introduced the concept of Smart Services™, the idea to combine efficient, proprietary communication methods with open standard systems to make your services available to a wide range of clients without compromising efficiency.
Often times you are implementing a service that you want to open up to third parties – either by making it publicly accessible to any users or by selling access to the service to selective customers. In this scenario, one cannot reasonably expect all clients to use Remoting SDK (or even one of the languages, platforms or operating systems supported by it), so it is reasonable to make the service accessible using open standards such as SOAP Web Services or the simpler XML-RPC.
These communication protocols have known down-sides (such as higher bandwidth consumption and lower efficiency parsing the verbose and text-based XML messages), but in this case, the benefit of enabling access from virtually any platform outweigh these disadvantages.
At the same time, you might be implementing your own client software for your services, using Remoting SDK, and you will of course want to reap the full benefits of using the SDK's fast but proprietary BinMessage protocol, to make sure your client can communicate with the server as efficiently as possible.
Enter Smart Services
Using the Smart Services architecture, Remoting SDK allows you to publish the same service using different protocols at the same time. This way, your own client applications (or any third party using Remoting SDK or the free Remoting Client SDK for .NET) can use the most efficient communication possible, without sacrificing openness to other platforms.
Relevant Message Types
An application that uses Smart Services will usually publish its services using the BinMessage and SOAP Message types, although both XML-RPC and PostMessage provide additional options for open and simple-to-parse message formats that can be easily be handled by non-RO clients.
Support for SOAP Web Services is available in countless different implementations, for every conceivable platform, making it the ideal choice. XML-RPC is a bit less known, but provides a simpler and more streamlined XML based message format than SOAP, making it a good choice for those platforms where an XML-RPC implementation is available.
Of course, Smart Services allow the use of more then two message protocols at the same time, so it is perfectly possible to provide support for SOAP and XML-RPC, in addition to BinMessage.
There are two options for enabling your server for Smart Services, depending on the type of server channel (a.k.a. server) you are using:
Exposing your Service Using Different Message Types
The HTTP based server channels provide the option to support multiple message formats at the same time, using different URL end points. Using the Dispatchers collection property of the server channel component, you can set up multiple message formats and assign them to different paths in your server URL. For example you could make BinMessage available at http://yourserver/bin and SOAP at http://yourserver/soap. The HTTP server channel will automatically process incoming requests using the proper message format, depending on the URL they come in under.
Since HTTP is the de facto standard transmission protocol for SOAP (although the SOAP specification allows for different transfer channels) and XML-RPC, you will not usually make use of the other service types for SOAP and XML-RPC, since most non-RO clients would not be able to communicate with them, anyway.
Exposing your Service Using Different Server Channel Types
While the other (non-HTTP) servers do not support multiple message formats, Remoting SDK allows the use of multiple server components at the same time. For example, you could provide a Super TCP Channel server with BinMessage, in addition to a HTTP server that provides BinMessage and SOAP.