> access="Remote" was WSDL - a flavour of SOAP.
To be precise, WSDL isn't SOAP. SOAP (Simple Object Access Protocol) is an
XML language used by services and their clients to exchange data. If this is
done over HTTP, those services are web services. WSDL (Web Service
Description Language) is the language used by many web services to describe
their interfaces. Essentially, WSDL is just documentation for the service.
When you create a web service with a CFC, it will produce both SOAP and WSDL
when asked. When you give out the URL to the web service, you're actually
giving out the URL that will generate WSDL. The web service client will
fetch that WSDL, and use that to figure out how to generate an appropriate
SOAP request.
> Ben's book CFWACK led me to believe it was easy to share
> information by means of a web service. So also did
> Macromedia's Robin Hilliard at the CFUG meeting when I first
> heard about web services. "Piece of cake!" he enthused.
> "Nothing to it! Once you learn how to do CFCs, it's a
> no-brainer!" HAH!
>
> So like a bloody fool, I accepted Ben, Macromedia, Robin
> Hilliard as experts in the field, and went ahead. I used
> that web service myself in my own sites, I tested it by
> moving a query across between my dev server, and my
> production server, and between two sites on different
> production servers.
> It WAS a piece of cake. Nothing to it. Follow the
> instructions in Ben's book and no problem.
As you've no doubt discovered, there are few no-brainers in the programming
arena! In general, web services are usually pretty simple, but there are
quite a few interoperability issues between various platforms. There are two
common SOAP encodings, rpc and document/literal, and they don't always play
well together.
In general, if you keep your web services simple, they'll usually work
across platforms. In this case, "simple" would mean avoiding complex data
types like queries. There's no SOAP-specific way to describe a query, so
each SOAP implementation does it a little differently, and they don't
understand each other's way of doing it.
> Now I move that exact code, and it doesn't work.
Others have mentioned that they get the code for the CFC when they visit
that URL. To me, that sounds like a web server configuration error. Are you
sure the production server is running CFMX? If so, do other CFCs generate
WSDL or regular documentation correctly if you browse them directly? What
web server are you using on that machine?
> I get abusive mail from PHP developers telling me that
> my page produces invalid RSS code (it's not RSS so that
> explains that!)
If this is a big deal, maybe you should consider offering an RSS feed. If
that's what people are expecting, you can certainly do that using CFMX.
There are plenty of people here (Jochem and Roger Bennington come to mind)
who are using RSS quite a bit. If you're just returning data, RSS might be a
better fit anyway.
On the other hand, if they're that abusive and they're not paying clients,
you might just tell them to go screw.
> I try to find out how to help the PHP users and the PHP people
> wont help, the web sites I've been shown and have found in
> google, all tell me how to create a web service in PHP, but
> no one gives any instructions I can understand on how to
> consume a WSDL web service. I thought WSDL produced SOAP
> output and that's why I used it. NO one until you, Jochem has
> suggested any different. I don't even know what REST is.
>
> So where do I go now?
In all honesty, if you plan to offer SOAP services, I'd recommend that you
test them out from different platforms to see if you have any
interoperability issues. This doesn't mean that you have to become an expert
with PHP or other languages, but you'll at least have to make sure that they
work adequately.
This is actually one of the advantages of going with RSS - valid RSS is
simply that, and you don't have to test it with every RSS client in
existence. (I'm oversimplifying a bit here, given that there are multiple
RSS standards.) SOAP is a little more complex, consisting of SOAP requests
and responses.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
