WSDL/SOAP/XML-RPC HELP

[Harry George]

Tomislav Lepusic <lepi--REMOVE-THIS-FROM-HERE at fly.srk.fer.hr> writes:

> Hello,
> 
> I don't know if this is the right group (I'm more in Perl, know
> nothing about Python), so if you can help me thanks, if not, sorry to
> bother you.
> 
> 
> I'm working on my student project and I'm totally lost and don't have
> any idea how to continue, and the deadline is 1.9.2004. Please help,
> 'couse i'm loosing myself in this XML/SOAP/RPC/WSDL things......
> 
> A little discription.
> I have to define and make something like virtual driver for serial
> port (RS232), only it isn't really a driver. The server has to be on
> Linux box (physical port(s) is/are there), and the other side (client)
> is not inportant. It is not important what is connected on serial
> port. Also, there is no need to work on any kind of drivers on Windows
> or something, becouse that is not the point. I have to make an
> universal way to send/recive/control serial port on that server
> computer from anywhere. I know how to program for serial port on Linux
> (in C), and I have made some progress there. That low-level programing
> isn't the problem. The problem is how to make it work over the net, so
> that someone who wants to write a program on Windows or Mac can use
> something universal to access it (like XML). I HAVE TO USE XML-RPC or
> SOAP or WSDL or something like that. The problem is that I don't know
> how to use those technologies. I read some tutorials, guides on
> XML-RPC, SOAP and WSDL, and I'm totally lost now.
> BTW, I was planning to use Perl becouse I know something about it. (I
> don't know Java)
> 
> So, if you can help me in any way (advice, similar example or
> something), please do. This is very important to me. I forget,
> everything must be secure (SSL or something).
> 
> Thank you
> 
> Tom

1. Many of us spent time in perl-land, and feel the move to python is
   worth your while, especially if you are currently confused.  Python
   is an excellent environment ofr learning new problem spaces, even if you
   later implement in other languages.

2. To learn more about XML, there are zilions of books.  I find
   E.R. Harold's "XML Bible", IDG Books to be useful -- enough
   examples to get going, but not so much detail you get lost.  You
   still have to visit the specs at: 
   http://xml.coverpages.org/xml.html
   http://www.w3.org/TR/1998/REC-xml-19980210.html

   You probably don't need to know this to use XMPRPC.  Just follow
   the examples.  For SOAP, you probably do need a good sense of XML
   and XSchemas.

3. To learn more about SOAP/WSDL, see James Snell et al "Programming
   Web Services with SOAP", O'Reilly, 2002.  There are enough examples
   to get the feel for it.  If you are working in python, see
   http://pywebsvcs.sourceforge.net/

4. In the opinion of many sensible people, SOAP/WSDL is a monster that
   started as an MS .COM extension of XMLRPC and got totally out of
   control.  Or more to the point, got out of the control of standards
   efforts to "play well with others", and got into the control of
   corporations seeking a new mechanism for proprietary lockin.

5. XMLRPC is the quick/cheap way to get web services.  In Python it is
   pretty straightforward.  See
   http://www.python.org/cgi-bin/moinmoin/XmlRpc

6. Assuming you are new to programming as well as XML/SOAP/WSDL, here
   are some std approaches to learning new problem domains:

5.1. Do a literature search, get tutorials, ask for help -- you are
     doing this.

5.2. Setup a small testbed to learn the mechanisms.  Typically start
     with a known good source or server, and read/parse/process that.
     Then learn to write/generate/serve.  In this case, you should
     probably follow the XMPRPC example above.  This is NOT your
     actual classroom exercise -- it is just a learning environment.
     Once you understand the mechanisms, you can architect and develop
     your project.  You can even grow them side-by-side (learn some
     more, then code some more, etc.)

5.3. In a system with several interacting parts (sounds like your
     exercise), the biggest problem is system integration.  This can
     be a nightmare if you've left it to the last phase.  Instead, get
     the whole thing connected with minimal functionality right from
     the start.  E.g., a simple query at one end gets to the other end
     and is acknowledged.  Build an automated regression test process
     around this (ask when you get to this point in python).  Then add
     functionality feature by feature, testing as you go.



-- 
harry.g.george at boeing.com
6-6M21 BCA CompArch Design Engineering
Phone: (425) 342-0007