Scenario – Asynchronous Web Services
Implement a web service to make two systems communicate. The “client” system is interested in events that are generated on the “server” system. But the “client system” is itself a server for a different app. The server is Java (WAR in tomcat). The client is .Net.
- Server is running.Client initiates conversation, “registers” to the server, and requests some initial data.
- Server keeps a list of registered clients’ endpoints
- In the server there is a listener that is notified when certain events happen. It will then go through the list of registered clients and forwards the event to each of them
- At some point, the client can “unregister” no notify the server that it doesn’t want to receive events any more.
- SOAP/HTTP communication path for requests from server-to-client – not guaranteed when firewalls exist
- The client needs to be aware of your notification schema – in fact the client needs to act as a Service endpoint to recieve the SOAP notification request.
- Many clients are “just clients” – they might not have a HTTP server to accept SOAP requests.So both sides need to servers and both need to publish their SOA interfaces. Alternatively, you can pull the notification to the client. The client can use a notification request to the server that is either blocking or polling. The server can respond with the notification or nothing or error.
An async callback mechanism is defined in JAX-WS 2.0, where the service obtains the endpoint reference of the client. SOAP payload schemas and message exchange pattern should
be custom developed as per requirement.
Incase of Arbitrary anonymous client SOAP would not be a appropriate solution. But with few changes and challenges it could be customized as below
- HTTP servers (i.e. the SOAP server) do not support blocking requests, as a rule, meaning you must poll
- the client needs to be aware of your notification schema – in fact the client needs to act as a Service endpoint to recieve the SOAP notification request. That’s two very big assumptions for an arbitrary anonymous client – that’s not something SOAP “just supports” both ends need to design all this in detail. In fact to do this in a service typesafe manner, the client should actually declare it’s own service WSDL interface so that you can invoke it.
Other options for above scenario
WS-addressing data in SOAP headers to inform either side of the other’s endpoint address.WS-addressing addresses will help you intelligently route SOAP messages to the right URL address, but no more.
WS-notification WS-BaseNotification sub-standard would meet your needs. It provides WSDL port definitions for notification producers and consumers. It provides a WS- standards compliant solution for subscription from a consumer to a producer, and a notification from producers to consumers.
- It does NOT define the format of notification payloads. The Notification payload is application-domain specific (proprietary design). The standard does not define any “standard” or “built-in” notification situations or messages.
- It has the same problems with HTTP notifications passing through firewalls as mentioned above.
- WS-Notification is not a supported standard of Java EE/JAX-WS
Use a Message queuing solution (e.g. JMS) with traffic encapsulated in HTTP This requires proprietary design of payloads passing between client and server and back – forming contracts between the two sides. An advantage is that the client can be a pure client, with a message listener invoked in a thread when a message is recieved.It has the same problems with HTTP notifications passing through firewalls as mentioned above and do-it-yourself implementation.