[Michael Chong]

Dear GI experts,
We all know that GI supports various communication protocols such as AS1, AS2, AS3, ebMS, etc. Can we develop and add our own customised protocol to GI such as low-level TCP/IP socket-based client-server communication with GI acting as the server?

Thanks for any response,
Michael

[remery]

Hello Michael,

Interchange does not support plugging in a complete new business protocol. The examples you give below, AS1, AS2, etc, we consider to be business protocols. In the nomenclature of Interchange we separate business protocols from transport. Put another way, we separate S/MIME packaging (or other packaging) from I/O (aka transport). As stated before, Interchange does not support plugging in a complete new business protocol.

Interchange does support plugging in other transports. The Interchange SDK includes a sample for creating a Pluggable Transport. In theory you should be able to create a Pluggable Transport to support your socket based communication. If the requirements also include the need to support customized packager/unpackagers then you could potentially do this work within the pluggable transport. Or, you could create inline processors to perform the packaging/unpackaging work. The feasibility will depend on the complexity of the business protocol you are attempting to support.

There is one limitation of pluggable transports that you need to be aware of. The pluggable transport API is polling based for messages going into Interchange. The API is not really meant to spin off socket listeners. You can however create a socket listener within your pluggable transport. Then have your socket listener/server queue up messages to be consumed by the pluggable transport polling interface. This isn't optimal, but should be possible.

I hope this helps.

-Ric

Dear GI experts,
We all know that GI supports various communication protocols such as AS1, AS2, AS3, ebMS, etc. Can we develop and add our own customised protocol to GI such as low-level TCP/IP socket-based client-server communication with GI acting as the server?

Thanks for any response,
Michael

[Michael Chong]

Hi Ric,
Thanks for the info. Based on your explanation, it looks like having our own kind of transport is possible by using "pluggable transport". You mentioned that "to spin off socket listeners" is not possible, so how would Interchange takes care of load distribution and load balancing when multiple messages are being received at a time by the socket listener? How is it being done presently by the other standard transports like FTP, HTTP, etc?

Hello Michael,

Interchange does not support plugging in a complete new business protocol. The examples you give below, AS1, AS2, etc, we consider to be business protocols. In the nomenclature of Interchange we separate business protocols from transport. Put another way, we separate S/MIME packaging (or other packaging) from I/O (aka transport). As stated before, Interchange does not support plugging in a complete new business protocol.

Interchange does support plugging in other transports. The Interchange SDK includes a sample for creating a Pluggable Transport. In theory you should be able to create a Pluggable Transport to support your socket based communication. If the requirements also include the need to support customized packager/unpackagers then you could potentially do this work within the pluggable transport. Or, you could create inline processors to perform the packaging/unpackaging work. The feasibility will depend on the complexity of the business protocol you are attempting to support.

There is one limitation of pluggable transports that you need to be aware of. The pluggable transport API is polling based for messages going into Interchange. The API is not really meant to spin off socket listeners. You can however create a socket listener within your pluggable transport. Then have your socket listener/server queue up messages to be consumed by the pluggable transport polling interface. This isn't optimal, but should be possible.

I hope this helps.

-Ric

[remery]

Hello Michael,

Within Interchange processing of a message is handled by the node that consumes the message. In the Embedded Server case, this would be the node that accepts the socket connection. Load balancing of embedded server transports, such as Embedded HTTP, Embedded FTP, etc must be handled externally to Interchange. Interchange does not include an external load balancer.

Load balancing is handled differently for "Polled" transports such as MQ Series, filesystem, external FTP server. For "Polled" transports Interchange's consumption framework will distribute load across the cluster. No external load balancer is required for polled transports.

Since you are attempting to implement an embedded server like protocol, you will require an external load balancer to distribute load across the cluster. I suppose you could implement a stand alone server and have Interchange "poll" messages from the stand alone server. This scheme would allow load distribution with the big drawback of introducing a single point of failure.

Regards,
Ric

Hi Ric,
Thanks for the info. Based on your explanation, it looks like having our own kind of transport is possible by using "pluggable transport". You mentioned that "to spin off socket listeners" is not possible, so how would Interchange takes care of load distribution and load balancing when multiple messages are being received at a time by the socket listener? How is it being done presently by the other standard transports like FTP, HTTP, etc?

[Michael Chong]

Hello Michael,

Within Interchange processing of a message is handled by the node that consumes the message. In the Embedded Server case, this would be the node that accepts the socket connection. Load balancing of embedded server transports, such as Embedded HTTP, Embedded FTP, etc must be handled externally to Interchange. Interchange does not include an external load balancer.

Load balancing is handled differently for "Polled" transports such as MQ Series, filesystem, external FTP server. For "Polled" transports Interchange's consumption framework will distribute load across the cluster. No external load balancer is required for polled transports.

Since you are attempting to implement an embedded server like protocol, you will require an external load balancer to distribute load across the cluster. I suppose you could implement a stand alone server and have Interchange "poll" messages from the stand alone server. This scheme would allow load distribution with the big drawback of introducing a single point of failure.

Regards,
Ric

[Michael Chong]

Ric,
So are you saying that this "stand alone server" cannot be implemented as an addition to GI's embedded servers or polled-transport servers (integration pick-up), and enjoy the same clustering features as these servers?

[remery]

I am just saying that you could implement your server to run outside of Interchange. And then author a pluggable transport to speak to the stand alone server you implement. If you went this route - the pluggable transport would enjoy the same clustering features as any other Interchange transport. But the stand alone server (running outside of Interchange) would not be under Interchange's run time control. And, is potentially a single point of failure.

But this solution was a bit off topic. If you implement the server within a pluggable transport, then this discussion is not relevant.

-Ric

Ric,
So are you saying that this "stand alone server" cannot be implemented as an addition to GI's embedded servers or polled-transport servers (integration pick-up), and enjoy the same clustering features as these servers?