通过已知端口进行服务器间通信

Question

Our product system consists of an IIS 6.0 server, behind which is a Java SOA server, behind both of which is an Oracle database server.

For various reasons, we need a windows service running on the Java SOA server that stores opaque blobs associated with GUIDs. Here is a simplified version of the interface:

interface IBlobService
{
    void PutBlob(Guid key, byte[] data);
    byte[] GetBlob(Guid key);
}

The main user of the IBlobService is the web front-end running on the IIS server. We could use WCF or .NET remoting over a custom port for communication between the servers. However, our application is subject to strict accreditation requirements. We would highly prefer to use a known port for communication, rather than a custom port.

We can't use named pipes, because we need to communicate between the servers. We had considered using MSMQ, as it uses a known port, but MSMQ limits message size to 4 MB. We need to transfer far more than that -- up to 60 MB at least.

What other capabilities (if any) does .NET expose that would allow communication between servers via a known port?

Answer 1

Well if you are using WCF you could use HTTP/HTPS. You could also use raw tcp on whatever port you like. eg just because port 80 is the standard http port doesn't mean you cannot run some other protocol on that port, so long as the server isn't using it already.

Answer 2

This answer does not address the problem in the question but presents an alternative approach that avoids the problem.

After deliberation, it is not a requirement that the blob service run as a windows service. Instead, a plain Java servlet that implements a RESTful interface to the data could be hosted in the Java application server. This would bypass the SOAP stack and XML overhead, yet leverage the supervisory capability of the Java application server.

Data can be stored with a

PUT https://java-app-server.example.com/blobService/b12a0403-... HTTP/1.1
Content-Length: <LENGTH OF BLOB>
Content-Type: application/octet-stream

<BLOB>

And later retrieved with a

GET https://java-app-server.example.com/blobService/b12a0403-... HTTP/1.1

Which returns

Content-Length: <LENGTH OF BLOB>
Content-Type: application/octet-stream

<BLOB>

Answer 3

If MSMQ is the facility of choice, I would chunk the data and reassemble it.

The contents of your message body is opaque, so including with each chunk data such as id, sequence, size, and a CRC is all possible.

You might want to consider WCF binary streams. See this article from MSDN: http://msdn.microsoft.com/en-us/library/ms733742.aspx