NGWS SDK Documentation  

This is preliminary documentation and subject to change.
To comment on this topic, please send us email at ngwssdk@microsoft.com. Thanks!

Applications, Messages and Objects

Applications can be thought of as communicating at two levels. At one level messages are sent between applications.

Figure: Applications and Messages

At another level objects in one application are communicating with objects in other application. The Applications at either end could be NGWS Applications, NGWS applications in Windows 2000 Component Services, a PERL script running on UNIX, a Mainframe Application running on MVS, etc. The important thing to note is that either application can replaced and the other application would continue to function correctly, as long as the messages communicated are consistent with the transport, encoding and pattern the application is able to process.

The Applications could be communicating through a set of one way messages or other patterns such as request-response. The Applications could be communicating in an asynchronous or synchronous pattern.

SOAP

Applications that communicate using SOAP message can achieve this “loosely coupled” interoperability. SOAP is an industry standard protocol for encoding and transporting messages. The messages are encoded using XML and can be transported over a number of transports including but not limited to HTTP, SMTP and Message Queues such as MSMQ.

Figure: Applications, Objects and Messages

NGWS runtime remoting natively supports SOAP in the HTTP Channel. Since NGWS runtime remoting channels are pluggable, additional channels with unique transport and encoding requirements can be written and plugged in without changing application code. This is an extensibility point that corporations and 3rd parties can maximize to integrate heterogeneous applications.