If the server is invoking operations back on the client, then you really have a peer-to-peer relationship, rather than a pure client/server one. This requires having the interface that the client will present back to the server described in WSDL. This WSDL should contain a <port> element for the client, as well as a <soap:address> element specifying the URI at which the client will be listening for callbacks.
With these two WSDLs in hand, both client and server have specified where to talk to each other. In a more dynamic application, the client can specify its URI to the server as part of the first message. Alternatively (and this is more complex to support), the server and client can continue to talk back and forth over the same connection, but it is probably best to avoid a full-duplex connection. It is not directly supported in the Web services model and any solution would be platform dependent.
Arranging for client and server to talk to each other in a peer-to-peer fashion is really the easiest part of this. The more substantial concerns is that, unless carefully controlled, the complexity of your application has now jumped. For example, the client may need to be multithreaded with critical sections. So give thought to whether or not the more common SOAP request/reply model won't actually fulfill your purpose.