Wiki Home


Namespace: WIN_COM_API
SOAP: Simple Object Access Protocol

SOAP, a WC3 consortium proposal (under review now) supported by Microsoft, IBM and several other big players, is an XML based RPC protocol aimed at simplifying remote code activation over HTTP, to provide intraprocess communication across machines.
Question: I've noticed a slight change in how VFP9 registers and consumes SOAP based web services. Have the FFC classes changed to use a more accepted method of packaging the SOAP calls vs. the SOAP 3 Toolkit (which is being deprecated and will not be supported)? (I could probably go look for myself, but I'm a lazy bastard) -- Randy Jean

I'm Confused by this also. From what I gather, SOAP is being updated with WSE within Microsoft. but this doen't go into any details about how other companies intend to support SOAP or whether they have an alternative technology to fill the gap. Just as I was getting into it as well, good old Microsoft ; Tim Hustler

Just checked... it does look like VFP9 FFC still relies on Soap Client 3.0 - Oh well, I guess as long as it works, but yeah, everything you read says stop using the Soap 3 toolkit -- Randy Jean

You can find a more detailed explanation of SOAP at:
Microsoft has released the SOAP toolkit to preview SOAP technology integration with Visual Studio and COM clients. Download the SOAP toolkit 3.0 from:
  • Take note: The ReadMe.TXT buried in the beta, surfacing only after installation, states that you need Windows2000 and IIS5!
  • Take note: WindowsServer2003 supports only the client side activities of the SOAP toolkit.
  • Take note: The SOAP Toolkit SDK support will be retired by July 1, 2004. It is "deprecated" by the .NET framework. Question: does this mean I can still deploy COM based web services using .NET as the soap "wrapper"? I sure in the heck hope so!! -- Randy Jean
    Here's a first overview of Simple Object Access Protocol with Visual FoxPro clients.

    I've installed and played with the SDK and for once I have to say Microsoft has put out a really impressive package. The kit is well documented and includes source code for almost everything which is a real treat if you're into digging in to see how things work behind the scenes. The documentation is extensive and contrary to most other MS offerings offers some insight into how the technology is put together. There's a lot of it, and although there's no quick start guide, the docs are readable enough and a few sections outline how to get started within a few pages.

    The SOAP toolkit consists of some key components: The MS specific ROPE component that acts as a middleware piece that wraps and unwraps SOAP XML messages and provides a client side proxy interface that essentially imitates a standard COM object reference. On the client side ROPE calls always mimic a COM method call. The other pieces are a couple of server side SOAP implementations (one ISAPI interface and one ASP interface) that use the ROPE client to unwrap the SOAP inputs coming from the client, manage running the COM component statelessly (ie. creating the object running the method destroying the object) and wrapping the results back up into SOAP XML resultmessage. Another piece, the SOAP Component Wizard, creates the equivalent of a type library in an XML format called an SDL file. The ROPE client reads this type library to decide on what services (ie. methods and objects) are available to call using the syntax provided.

    The client side code for SOAP calls using the Proxy is almost trivial and nicely implemented. The following shows how make a SOAP call against a server side component:
    *** Load SDL file
    o = CREATEOBJECT('wwIPStuff')
    lcXML = o.HTTPGet('http://localhost/soapdemo/services.xml')
    *** Load the SDL into Proxy
    oProxy = CREATEOBJECT('Rope.Proxy')
    ? oProxy.LoadServicesDescription(2, lcXML)   && .T./1
    *** Make the method call
    ? oProxy.getstockquote('MSFT','any company')

    Actually, there's also a built in WireTransfer component that can handle what HTTPGet does above, but the above code is easier to use. The SDL file comes down as a string and is then loaded into the Proxy object which, based on that, 'extends' the proxy with the methods provided in that interface.

    There's a VFP gotcha here: VFP can only process lowercase method names because that's how VFP's typelib parsing works. The default SOAP samples won't work unless you do the following:
    • Go into the SDL file (services.xml in the samples)
    • Change every method name listed there to lower case
    This is kind of a bummer for VFP as it will lock VFP out of a lot of implementations. However, you can also programmatically go through the XML returned and automatically lowercase the method names before actually passing the methods to LoadServiceDescription(). VB has no such limitations.

    The SDL files are based on relatively easy multi-part schema that describes the methods, parameters and return values of any objects, but all inputs and outputs so far need to be simple COM types. Complex types like arrays and objects are not supported at this time although you can pass stuff like that via XML messages easily enough.

    SDL files can be generated using the SOAP Wizard and pointing it against a COM object on the server. The Wizard generates the SDL file, which you can then use to load the description in the proxy.

    The ROPE client also supports posting RAW SOAP messages and loading SDL definitions with more low-level interfaces although I've not had a chance to look at that yet.

    On the server side a little more work must be done. Basically, SOAP provides a standard ASP based template that handles loading the COM object. You include the base ROPE access service into an ASP page and the ASP page then proceeds to create the various method call implementations. The SOAP Wizard creates this page for you as well, which is slick. Because it's plain ASP code you can modify it as you see fit.

    The basic idea is that you have some ASP code that's remotely called in a function that bears the signature that matches the class method. For example the GetStockQuote method is implemented as follows:
    < !--#include file='listener.asp'-- >
    < %
      Function getstockquote(symbol,description)
        Dim oWire
        Dim sBuffer
        Dim n
     Dim i
     GetStockQuote = '???'
     set oWire = Server.CreateObject('Rope.WireTransfer')
        sBuffer = '' & Symbol
        sBuffer = oWire.GetPageByURI(CStr(sBuffer))
        if err then
          LogMessage 'Err: ' & err
        end if
        if err then
          LogMessage 'Err: ' & err
        end if
        n = instr(sBuffer, 'iPage=qd&Symbol=')
        GetStockQuote = '????'
        if n then
          n = instr(n, sBuffer, '< TD ALIGN=RIGHT NOWRAP >')
          if n then
            n = instr(n, sBuffer, ' ')
            if n then
              n = n + 6
              i = instr(n, sBuffer, '<')
              if i then
                GetStockQuote = mid(sBuffer, n, i - n)
              end if
            end if
          end if
        end if
        set oWire = nothing
      End Function
    % >

    Note the reference to listener.asp which is included at the top. Listener.asp handles the main entry point to the ASP page which deals with parsing the SOAP message and calling the function entry point.

    This is a fairly clean design that leaves open a lot of options for the user. For example, you could, in place of this ASP code, simply instantiate a real COM object and make a passthrough method call to process the logic.

    Listener.asp contains a lot of code that deals with the internals - it's very interesting reading to see how this is implemented.

    For those of you that have played with Web Connection before and the wwHTTPCom object you will notice a lot of similarities. wwHTTPCom is considerably simpler to implement and more lightweight (no COM objects anywhere) and the XML spec is much simpler as well. But SOAP is obviously more complete and follows an official spec that is gaining momentum, with Microsoft and IBM being the major supporters at this time.

    There are a couple of issues that are not clear at this time. SOAP doesn't provide security directly. Microsoft's ROPE implementation also doesn't provide anything in the way of security. This means once a service is there you can potentially be open to attack, especially since the SDL may give away interfaces. Since you do get an ASP hook though, you can implement your own authentication if necessary. At this point it's not clear to me how the ROPE client would handle the security issue and Basic Auth request.

    There are a couple of serious problems with the SOAP toolkit which decrease its usability at this time. The internal wiretransfer object doesn't support SSL nor proxies, so it doesn't work in many situations. In addition the SOAP Packager can't deal with embedded XML from either the client or server, especially if CDATA is part of the passed XML. This means you can't reliably pass XML parameters to function calls.

    Anyway, thought I post this here, because it's interesting technology. This is one of those times when i can get excited about something new MS has put out that really hits the spot.

    So check it out. This technology will be around for a while to come (it's the base for Microsoft's Web services and HTTP COM services) so this won't be a waste of time.

    -- Rick Strahl
    See also eb XML
    Contributors: Rick Strahl
    Category XML Category 3 Star Topics Category DotNet
  • ( Topic last updated: 2008.06.02 06:42:33 PM )