Re: SOAP-over-UDP

Wed, 01 Jun 2005 02:31:54 -0700

Unlike TCP, UDP does not provide any contract. Therefore, sending data that doesn't fit in a single packet is not guaranteed to be received in the correct order, and no acknowledgement is returned to the sender. UDP is great in broadcasting atomic information, but unreliable for exchanging consistent pieces of data, such as a SOAP message. 


Le 1 juin 05 � 10:48, Francesco Munari a �crit :


Mark,




Yes, that's seems to be great idea, I would even say elegant.




...and it seems to work very very well!! ;)

It all works! It seems very efficient.
Saving the URLs send as a reply by the servers in a hash eliminates
also possible duplicates because the add(Object o), if it finds an
equal Object inside the hash, replace the old one with the new one.
So, if erroneously some service was published into more tha one UDDI
registry present in the LAN, the result hash, at the end of the
"request round", will have only one WSDL URL representing that
service.

Wow! It has been very cool solving my problem with you all! A parte of
my thesis is your merit!

But now the very last question (^_^): why (apart the difficult that I
had in implementing it) the use of SOAP or XML-RPC broadcast message
over UDP are so unsuitable?

Thank you very much!

Francesco
2005/5/31, mdonaghue <[EMAIL PROTECTED]>:


Francesco,




In this way the

proxy receives the message, ask its UDDI registry for that  
service and
reply with a byte[] containing the URL of the service's WSDL  
file. Uh?




Yes, that's seems to be great idea, I would even say elegant.

Regards,
Mark


-----Original Message-----
From: Francesco Munari [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 31, 2005 4:54 PM
To: [email protected]
Subject: Re: SOAP-over-UDP

Great Mark!

You have explained your point of view as well as you could.
So the point is to give a proxy to every server that has an UDDI
registry. This proxy, written in Java, waits for UDP datagrams. Maybe
the broadcast UDP message sent by the client could also contains the
key of the service that the client is searching for. In this way the

proxy receives the message, ask its UDDI registry for that service  
and
reply with a byte[] containing the URL of the service's WSDL file.  
Uh?


Should be a good idea instead of retreiving the IP address and having
also to ask the registry for the service?


Thank's again to you all!! You're help me more than you think!  
Thank's.


Cheers

Francesco

2005/5/31, mdonaghue <[EMAIL PROTECTED]>:


Hi Francesco,


My original suggestion was to use DNS to identify the URL of the  
UDDI



server


in the local subnet. The advantage to this is that no broadcast  
message is
needed and it's using a common solution. The disadvantage is it  
requires



an


entry in the DNS server database, some knowledge of how to  
administrate



it,


and isn't automated.


So, I tend to agree with Eric's solution (except for the last  
step which I
believe should be unicast, not broadcast).  The basic idea is to  
have the
client broadcast a "who has a UDDI Server" message when it comes  
online.



XML


will be ok, because since the broadcast only happens once,  
verbosity is



not


an issue. However, a simple text message would also do the trick and

eliminates the need to parse XML. In either case, a simple UDP  
server
process listening on over a known port on the UDDI server machine  
will
respond, identifying itself to the client. At that point the IP  
address of
the UDDI server is available to the client and the UDDI request  
can be

unicast to it.

This message sequence is identical the ARP protocol, which allows an

end-host to determine the MAC address of system with a known IP  
address.



The


end-host broadcasts a "who has this IP address?" message to the  
subnet. If



a


host with that IP address receives the message, it unicasts an "I  
have it"

message, enclosing its MAC address along with it. From then on, all
communication for that flow can be unicast.


The actual messaging discussed above should be handled outside of  
SOAP,
since SOAP is not intended for this kind of functionality. It  
could be

easily implemented as with Java using UDP datagram sockets.


This approach handles the potential problem of multiple servers  
on the



same


subnet, since the client can just choose one. It also solves the  
problem



of


the UDDI server not being architected around a possible broadcast


scenario,


typically running over TCP.  You won't need SOAP over UDP. It  
minimizes
network overhead since only a single broadcast is made, when the  
client

comes online.

Regards,
Mark


-----Original Message-----
From: Eric VERGNAUD [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 31, 2005 7:58 AM
To: [email protected]
Subject: Re: SOAP-over-UDP

It depends on what you mean by continuous. a 16 bytes packet every 5
seconds certainly won't.

If you need a higher reactivity, you can do the following:
 - have the client broadcast a message on a port
 - have the server listen on that port
 - when the server receives a connection, have it broadcast as
suggested in my previous email

Le 31 mai 05 � 13:17, Francesco Munari a �crit :



But there isn't the risk of flooding the LAN with these continuous
broadcast messages?

2005/5/31, Eric VERGNAUD <[EMAIL PROTECTED]>:



Have your server regularly broadcast its address on a port.
Have your client act as a server on startup and listen on the same
port.

When the real server broadcasts its address, the client will  
receive

a connection request.

One you have the server address, ask the server for the  
information

you need (what you call the context).

Le 31 mai 05 � 11:41, Francesco Munari a �crit :




Hi, Eric.

Ok, but how can I do this? I think I'm a newbie in this kind of
operation, sorry. How can I look to a port of servers in a LAN
without
knowing their IP? And in this way may I keep the context-
awareness of
the communication?

thank you for you reply

Cheers

francesco

2005/5/31, Eric VERGNAUD <[EMAIL PROTECTED]>:




I'm afraid that is a very verbose way of doing things. The  
typical

way to do this is determine a port, have your server broadcast
its IP
address on that port, and your clients look on that port to grab
the
address.


Once the address is found, you can safely interact with the  
server

using SOAP over HTTP.

Le 30 mai 05 � 22:19, Francesco Munari a �crit :





I'm alredy using UDDI4j. The idea is that I don't know where  
the

UDDI
registry can be in the LAN.
I assume that the client knows only two things:
1) the network (of course)
2) a "search key" for a particular tipe of service

and that's all.
The client should send a broadcast SOAP (or XML-RPC) request

containing the search method to call on the server with the  
"key"

passed as a parameter and somewhere into the LAN should be a
server

(or more) with its private UDDI registry that should reply  
with a

response containing the result of the invoking of the method
contained

in the sender's RPC request. The response should contain  
just the

URL
of the WSDL file related to the service found.

The need of the broadcast message is that the client don't know
where

(or if) there could be any UDDI registry in the network.  
With this
framework a client can change network configuration (for  
example,
going from a floor to another with a Palm in a wireless LAN)  
and,

after leaving the service provided in the first network, find
anothe
one similar on the other network only by pressing the button
"Refresh"
:)

Francesco

2005/5/30, Martin Gainty <[EMAIL PROTECTED]>:





The side effect of a broadcast without authentication is
flooding the
network with unwanted disovery packets
I guess this is OK if you're utilising a high datarate
transmission i guess

In your case your SOAP Request should look like

<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"; >
 <SOAP-ENV:Body>
   <getTest>
     <Test>Test</Test>
   </getTest>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>


If you want to discover a "SOAP based" web-service based on  
some

characteristic such as Business Service Category why not use
UDDI4J?
Take a look at
http://sourceforge.net/projects/uddi4j

Martin-

----- Original Message -----
From: "Francesco Munari" <[EMAIL PROTECTED]>
To: "Martin Gainty" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Monday, May 30, 2005 12:44 PM
Subject: Re: SOAP-over-UDP

Martins,


It is for this reason that I'd like to broadcast a SOAP  
request

instead of a simple XML-RPC message. The goal of my framework
is to
keep the "context awareness" offered by XML language.
If you are sure that there is no way to send a broadcast SOAP
request,
the last solution, I think, it could be XML-RPC.

So, two questions:


1) are you sure ther's no way to send a broadcast SOAP  
request?
2) In order to send a broadcast XML-RPC message I've to  
cerate a

StringWriter like this (for example)?

<?xml version="1.0" ?>
  <methodCall>
      <methodName>getTest</methodName>
      <params>
          <param>
              <value>
                 <string>Test</string>
              </value>
          </param>
      </params>
</methodCall>

Thank's Martin.

Francesco

2005/5/30, Martin Gainty <[EMAIL PROTECTED]>:





Francesco-

You can Broadcast XML-RPC assuming you dont mind flooding  
your

network
The question is can you confine your application to using the
more basic
datatypes supported by XML-RPC

vs implementing SOAP features (user-defined datatypes,  
namespace

URI)?
Anyone else?
Martin-
----- Original Message -----
From: "Francesco Munari" <[EMAIL PROTECTED]>
To: "Martin Gainty" <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Monday, May 30, 2005 6:45 AM
Subject: Re: SOAP-over-UDP

Grazie! :)

Could someone tell me if a simple XML-RPC message may be sent
to a
broadcast address? A simple message with the medthod to be
invoked. In
this way I should be able to send a broadcast XML-RPC request
with the
appropriate UDDI inquiry method; a server (containing a UDDI
registry)
should receive it, invoke that method and send a reply in XML
format
to the sender.

It could be a good idea?

thank you again!

Francesco

2005/5/29, Martin Gainty <[EMAIL PROTECTED]>:





benvenuto!
Martin-

----- Original Message -----
From: "Francesco Munari" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Saturday, May 28, 2005 5:41 PM
Subject: Re: SOAP-over-UDP

Thank you all for your very quick reply!

I've heard about this SOAP-over-UDP spec

(http://msdn.microsoft.com/library/default.asp?url=/ 
library/en-

us/dnglobspec/html/soap-over-udp.asp).

So, Martin, you say that it could not be a solution?  
Perhaps it

should
be an idea using Mark's solution (with DNS).


I thought to resolve the problem putting a SOAP envelope  
into

a UDP
datagram, send the datagram to a broadcast ip and that's all
folks...but I don't know how and, as you, Martins, wrote, I
was not
able to find anybody who has implemented this yet.

Can you suggest me another solutions?

Thank you very much again!!

Cheers,

Francesco

2005/5/28, Martin Gainty <[EMAIL PROTECTED]>:





Mark/Francesco
I would caution on use of UDP as the SOAP Portocols (e.g.
HTTP)
is/are
decidely not UDP but instead a connection-oriented TCP

To date I have not seen UDP Ports used for SOAP  
transmission

although
since
there is no requirement for verifiable connection and or
handshakes

I would venture to guess UDP is available as the  
transmission

medium
but
I
have not seen any UDP Ports used for SOAP thus far
Anyone else ???
Ciao-
Martin-

----- Original Message -----
From: "mdonaghue" <[EMAIL PROTECTED]>
To: <[email protected]>; "'Francesco Munari'"
<[EMAIL PROTECTED]>
Sent: Saturday, May 28, 2005 3:14 PM
Subject: RE: SOAP-over-UDP






Hi Franceso,

I've worked briefly with the apache soap api, not that
familiar with
it.
Typically a soap message is sent to a single soap server
address,
which
is
specified by a url or an ip address, as well as a port. So
your
server
address on the LAN might be something like
192.168.100.2:8080.
(I'm
not
sure

what the port is for UDDI, so just using standard  
TomCat Web

Server
port).

IIRC, you there's a point at which you specify that
address in
the
setup
for
your soap call. One thing you could try is to change the
address to
the
subnet's broadcast address, 255.255.255.0:8080, assuming a
class c
network
where the first 3 quads specify the network portion of the
submask.

However, this may not a scalable solution, since the
broadcast
wouldn't
carry beyond the physical subnet on which you are located.
Using
UDDI
to

discover services is one thing, but dynamically  
discovering

UDDI
servers
is
obviously a different problem. It also doesn't address the
issue of
more
than one UDDI server running on the same subnet.

A more generalized solution might involve a distributed ip
lookup
service,

namely DNS. For example when DNS looks up the ip  
address of

Yahoo.com,
at

some point the actual ip address that serves the  
request is

dynamically

assigned to one of dozens (or hundreds) of servers  
based on a

scheduling

scheme.  You could locally enable DNS lookup, and  
create an

entry
based
on

some url like "myuddpsever.com", and give it your local  
UDDI

server's
ip
address, and the rest would be handled within the network.
The
advantage
to

this is your UDDP server could be anywhere and your  
message

would
still
reach it.

hth,
Mark





-----Original Message-----
From: Francesco Munari [mailto:[EMAIL PROTECTED]
Sent: Saturday, May 28, 2005 4:58 AM
To: [email protected]
Subject: SOAP-over-UDP

Hi, I'm desperate!

I'm trying to find out how to send a broadcast SOAP  
request

to a
UDDI

registry in a LAN, but I'm not able to do this. I've  
looked

for some
example but I've not found anithing.

Please...could anybody help me?
I'm making a thesis for the University of Florence (Italy)
and I
have

to discovery dinamically web service published in some  
UDDI

registry
somewhere in a LAN. I have to send a broadcast SOAP
request to
these
UDDI registry (as I wrote few lines above).
Of course I'm using Java language.

Thank you very much for your help...I'm in a great
hurry...thanks
very
very much to everyone could help me!

Best reguards,

Francesco



























































































					Reply via email to