WebService DIME Bridge

The DIME Bridge transferring a web service response (any serializable object) in the binary format across the Internet. It's a full transparent loosely coupled solution between the web service and its consumer - just injecting the bridge in their config files.

Contents

Communication to the web service over Internet is based on the text formatted protocol, where binary fields are using the Base64 encoded text embedded in the body of the message. The Return object from the web method can be a simple type value or a custom object with more complex types such as binary arrays, etc. The logical connectivity between the web service and its consumer is encapsulated into the proxy/stub infrastructure allowing strongly type access from the business layer. The communication proxy/stub channel provides all magic over wire using the HTTP transport layer, including encoding/decoding binary images in the Base64 text pattern.

Introducing the DIME (Direct Internet Message Encapsulation) in the WSE 1.0 +, the binary images can be sent over Internet as binary attachments. Using the WSE Dime namespace classes, the DIME programming is very straightforward at both ends. Each attachment represents one record behind the first one - record 0 (reserved for a SoapMessage).

This article describes the solution allowing to transfer the web service response (return value) in the binary format using the WSE-DIME feature. This is a fully transparent loosely coupled solution injected into the message process pipeline at the properly stage.

The DIME Bridge encapsulates a tightly coupled programming of the binary attachments from the business layer, which it can be very useful for migrating the business layers to the next communication model such as Indigo. (Notice that the Indigo will not use the DIME feature.)

The concept of the DIME Bridge is based on binary transferring a web service response (return object) via the Attachment. On the server side - before the DIME bridge, the Return value is serialized into the DIME attachment and its reference in the SoapMessage is setup to null, which will produce very lightweight XML text formatted SoapMessage. On the client side - after the DIME bridge, the situation is reversed. The DIME Attachment is de-serialized into the Return object and its reference is set-up in the SoapMessage (replacing the null value). From the client point of view, all processes via the DIME Bridge is fully transparent and loosely coupled in the SoapExtension message pipeline.

The following picture shows this scenario:

The client invokes the WebMethod via the WSClientProxy - at the stage before serialize (1), the SoapMessage is extended for unknown soap header to indicate a server side that the DIME Bridge can be used for the response (4). The SoapServerMessage before the serialize stage is holding the reference of the Return object, so it can be simply serialized and its stream be stored into the DIME Attachment. After that, we can "kill" the return object in the SoapMessage in the same manner like web method, returning value null.

The following flowchart shows the stage (4):

The SoapMessage is encapsulated into the DIME records. In our case, the result value (return object) is first an Attachment, so the DIME Bridge on the wire (5) will have the following pattern, which represents the core of the concept:

As you can see, the above server side stages are straightforward supported by MS WSE-DIME SoapExtension, which has to be plugged into the SoapExtension pipeline close to the wire (priority="1", group="0").

Situation on the client side is a little bit different, because the DIME Bridge can be injected also in the "legacy" client proxy (no WSE features).

Let's look at this scenario.

The SoapClientMessage at the BeforeDeserialize stage has a responsibility to handle a network stream in the case of the "legacy" proxy. The first DIME record represents the SoapMessage and must be passed through the SoapExtension pipeline like in a normal text/XML way. The next (second) DIME record is our stream of the Return value. Its reference is temporarily stored for the next - final stage.

The following flowchart shows the message workflow at the BeforeDeserialize stage:

The following flowchart is a final stage of the SoapClientMessage processing. Based on the existing WSE proxy, the first Attachment is retrieved and temporarily stored. The next workflow is a common part for any type of proxy - replacing the nullvalue of the Return object in the SoapMessage by the deserialized stream. That's the final step, and from now the SoapMessage can go to the business layer like in the case without the DIME Bridge.

That's all there is in the magic of the DIME Bridge.

Based on the above concept, the DIME Bridge can be extended very easily for full duplex included the output parameters or for a message body streaming.

The following picture shows an idea for streaming data without using the DOM, where SoapHeaders are encapsulated from the content (body) based on the described concept. This design pattern allows to scan the SOAP headers and forward content to the proper endpoint.

Using the DIME Bridge requires installing the WSE 2.0 in prior. After that, the downloaded DIME Bridge MSI file can be run. The setup will install the DimeBridge assembly into the GAC including its source code in the specified location. Note that the DIME Bridge must be installed on both sides: the server and its consumer (client). The next step is to plug the bridge into the SoapExtension pipeline.

Note that the priority of the DIME Bridge has to be properly set-up in the case of using multiple SoapExtensions. On the server side, the bridge's priority should be behind the WSE, but on the client side, must be close to the wire (NetworkStream).

The following DIME Bridge properties can be configured in the appSettings section:

After this configuration step, the DIME Bridge is ready to transfer the web service result in binary manner. Of course, there is also capability to set-up the "private bridge" attributing the specific method. Note that this is a tightly coupled solution - incorporated (hard coded) into the client/service implementation.

Trace Output

The trace of the checkpoints in the DIME Bridge can be displayed, for instance, on the DbgView program (http://www.sysinternals.com/). Here is its result, for attaching the result (338656 bytes) to the DIME record:

Performance

Using the DIME Bridge for Return object with embedded binary images can significantly increase a performance over Internet. For instance, the streamed Return object with the length 5MB can be transferred ~300% faster than the XML formatted one. On the other hand, the small streamed return object like 2KB increase performance approximately about 12%.

Implementation of the DIME Bridge is encapsulated into the base class - NopSoapExtension and its overrides. The base class represents the "empty" SoapExtension class with virtual public methods for each SoapMessage stage. If this class is plugged into the SoapExtension pipeline, the SoapMessage is processing though all stages without any action (nop operation).

Overriding a proper stage method by the derived class, the SoapMessage workflow is modified based on the application logic. The DimeBridge class inherited this base class to perform the described flowcharts overriding the following methods - stages:

As you can see, the implementation of the DIME Bridge at the message stages is straightforward using the classes from the Microsoft.Web.Services2.Dime namespace. As I described earlier, the "concept core" is based on overwriting the reference of the Return value. This reference is obtained using reflection.

In this article, I showed you a SoapMessage encapsulation into the DIME records based on the message content, for instance, a return value from the WebMethod. The WSE-DIME feature allows to split the SoapHeaders from the message body and handle them separately (like Indigo messages). This concept can be used also for creating your own protocol for router, streaming, etc. in a loosely coupled manner. Included DIME Bridge is the example of this concept, how to significantly increase the response from the web service without touching either the client or server. I hope you will enjoy it.

Hi,
I have some problems with web services .
i wanna design a system based on SOA Architecture that contains a consumer(client) and service provider and web services that connect these two.
how can I do ?
my project must be loosely coupled .
can you help me ? (example ,...)
any help appreciated

Hi,
I'm working with Mobile Devices like Pocket PC or Smarth Phones with Windows Mobile and I need to transfer large binary files from the Mobile Device to a PC; therefore I tried to send a binary file (752 Bytes) over POST and the length of the complete message including the file's information is 1186 (753 File's Bytes + 434 Header's Bytes). And using SOAP the complete message has a length of 1127 bytes (752 File + 375 Header).
This file is just an example, because I'll work with larger files.

Now I want to try with DIME, but I read that it's neccessary to install WSE, is it right? or is it possible to use DIME without WSE?.

I'm looking for the way to send the binary file that has the smallest lenght of bytes, because the message will travel by CDMA or GSM, that I have to pay for each sent byte.
What is the best way to send the binary file by POST, SOAP or DIME?.

I have benn following some of your postings about sending files over.
I am using WSE 2.0 for DIME support.
I have been trying to send files by using DimeReader and DimeWriter classes.
the Problem comes when I call the web method to send the dime memory stream.
It accepts only proxy type arguements and not even allowing any type casting.
Please help in case you have done programming on these classes.

I'm so sorry if i have posted in wrong topic. But I have a problem with using SOAPMessaging. If you don't mind, please give me a hand. Thank you.

My new assignment in VB.NET is as the following steps:
- Creating one XML file with employees' info. This must include picture field.
- I have to use WSE to attach images.
- Then building Client side in windows form

I don't know how to carry images and XML data together. In XML file, in picture field, is it a must to state pictures' paths? If so how can i use them later on?