Query on DPWS role reversal & retry logic
sathya sai
Hi ws4d-gSoap forum, My wholehearted thanks for all your contributions on DPWS world.
This is Sathya, and I have the following queries related to DPWS technology. Could you please help me out on this,
1. I know that With the present DPWS standard,the client uses Probe/Resolve/Get metadata sequence to get the interfaces/service supported by the server. And then, uses these interfaces to perform the desired operations in the server.
Now my doubt is; in my product I would need the server to also know the interfaces supported by the client so that server can also request for some operations to be performed on the client. Could you please let me know if this is possible with present DPWS standard (i.e) client to call server's interfaces & server to call client interfaces. In simpler terms, is role reversal feature available with present DPWS standard.
If yes, could you please let me know on how the endpoints are exchanged in this scenario.
2. Suppose the server is down for sometime. Then, does the existing standard take care of any logic with which the client can retry its request after considerable amount of time.
Could you please help me out with your thoughts on this.
Thanks and regards,
Sathya |
S. Poehlsen
concerning your first question: Yes it is possible and it is not a
DPWS-related thing. It just depends on how you define web service client
and server. You just have to switch roles and have a normal web service
communication again. As you already mentioned "some operations to be
performed on the client" typically describe what a service/server does.
Therefor the clients also have to be a DPWS device with a UUID, a
metadata description with their interfaces and so on. In the ws4d-gsoap
stack this is called "peer" instead of client or device.
In case both sides are peers - and not only a client and a device - both
peers announce their existence with WS-Discovery hello messages. Thus
both peers are aware of the other peer and can continue with further
information retrieval.
You second feature request/question is bit more complicated, since it is
not part of a typical dpws-compliant stack. You requested a feature that
is available with WS-ReliableMessaging. DPWS is designed to be
compatible with "richer" web service implementation, so it should be
possible to enhance dpws with reliable messaging.
ws4d-gsoap is based on gsoap. Since gsoap 2.7.16 a ws-ReliableMessaging
plugin exist but ws4d-gsoap currently only supports gsoap up to version
2.7.13. So two task have to be done: add support for gsoap 2.7.16 or
later and include support for the WS-ReliableMessaging plugin.
In case you are also using other dpws stacks you may have to implement
WS-ReliableMessaging on top of it, but I cannot guarantee that it works
with all dpws stacks. Especially with close source stacks it would be
more problematic.
Hope this helps,
Stephan
sathya sai
Hi Stephan,
Thanks a lot for your quick response on this.
To be more clearer on your answer to my first question, could you please explain on how the peers can exchange uuid with WS-discovery.
Does it mean, both the peer needs to issue multicast Probe to understand about each other (which I think would be complicated).
Is there any easier and standard way in WS-discovery with which both the peers can know about each other's services/interface ?
Regards,
Sathya |
|
S. Poehlsen
both peers (client and server) have to announce themselves with a Hello
message (which includes their uuid). The client peer receives this hello
message and is able to use the service normally. If the client misses
the hello it has to probe for the service. Everything is a normal dpws
discovery process.
When the "service" wants to call a service on the "client" it has to
probe for the "client". The "client" probematches to that discovery
probe request. That's why the "client" must be a device as well.
A problem might arise in case you have multiple clients, then you have
to decide on the "server" which client (probematches) corresponds to the
original service requests.
If you give a more detailed scenario it would be easier to answer your
questions.
Stephan
sathya sai
Hi Stephan,
Thanks a lot. Your explanations were very nice..And clearly got my deployment scenario as well.
Maybe, during the client's discovery phase itself, the server can record the client's identity (IP address). Then, whenever server needs any info, it can directly send a "Directed probe discovery" instead of "Multicast probe discovery".
Does this approach makes sense?
Is there any standarad specification explaining this interaction? If not, do you know on how we can standardize such interactions in DPWS?
Thanks and regards, |
|
S. Poehlsen
to send a directed probe you must know the http transport address of a
device, that includes the port number and maybe some path information.
Thus it is not sufficient to record the IP address. You must use the
multicast probe.
Another possibility is, that the "client" provides its own uuid to the
"server". Then it is sufficient to resolve the uuid and you do not get
any problems with multiple clients (that may even share an ip address).
Stephan
sathya sai
Stephan,
Yes, your proprosal would be a complete easier solution for this problem.
But I hope with the present dpws specification, there is no standard way by which the client's XAddr (http transport address for the service) can be conveyed to the server as a part of the client's discovery of the server phase itself.
Could you please let me know there is already a way to do this? If not, how can we standardise this as well?
Please let me know if you feel that I am missing anything on this regards.
Regards, |
|
Sathya
|
|
S. Poehlsen
in WS-Addressing exists the possibility to add a replyTo header block to
a message. This header block indicates, that the reply should be send
back to the giving EPR or in the back channel.
Do you meant that? It is not specific for DPWS.
Without a specific scenario, it is not clear what you really want to
achieve.
Stephan
sathya sai
Hi Stephan,
Thanks for all your responsive and valuable information on this.
I am actually designing a dpws based control system, only for some cases I would want my server to also request and perform certain operations on the client (i.e) server to invoke the interfaces on the client. Need the role reversal only for certain operations.
Based on your suggestion, I could understand that this can be achieved by just filling the client's ReplyTo header with service endpoint for the client. The server can then cache and in future use this endpoint to get the service supported on the clients and invoke them..
Do our dpws stack support this?
Thanks and regards, |
|
Sathya
|
|
S. Poehlsen
> Do our dpws stack support this?
I don't think that it is already implemented, but it should be "easy" to
add since the stack already allows for callbacks to the client for
WS-Eventing.
Typically the wsa:replyTo is used for asynchronous transport in web
services. A web service might close the incoming HTTP request and opens
a new HTTP connection for the response to the replyTo EPR. This is very
interesting in cases where the processing might take longer than HTTP
keeps the connection alive.
Stephan