Summary
Sometimes it seems that the true value of something in our business is inversely proportional to the hype. When programmers come up with a good idea, they don't seem very good at hyping it.
Advertisement
But when someone other than a programmer comes up with an idea, it often becomes another example of something that has lots of noise but no content.
I spent about 3 weeks learning about and programming a secure, automated Paypal payment system. It encrypts and passes information to Paypal, and when a transaction completes, Paypal calls a program on my server, which verifies the transaction and then does something appropriate, like deliver a product to the customer.
Although in this case Paypal is providing me a service through the web, from my understanding of Web Services, it isn't. There's no XML involved, for one thing (it seems closer to REST), and no SOAP or any of those other things that are part of Web Services buzzwords.
Fast-forward to today, when I'm working on creating a site that will deliver a physical product. I think "perhaps I can just quickly bash something together to query the Fedex site using Web Services." Not only had I heard that Fedex has Web Services, just about every book and article gives Fedex as an example.
You can find information about Web Services on the Fedex Site. But the docs are not very clear about how to make an actual call, and I couldn't find any examples. Apparently there's a single C function that you can call with arguments representing your call, but when you look at the document for this, called "FedEx API Client Libraries Developer’s Guide", it's two pages long and incredibly vague -- and this is supposed to be the simple solution. The purpose of the function is "To connect to ATOM and send a FedExAPI transaction to the FedEx Internet Server," which makes it sound like ATOM is somewhere else, but the first argument to the C function is "the host name or IP address of your system that is running ATOM." Nowhere in the document does it say what ATOM is.
I tried googling for FedExAPITransaction, which is the function name, and got 11 hits, either empty pages or handwaving on the Fedex site, or one code example in VB that used COM. In fact, googling for "Fedex" and "Web Services" primarily got either books or articles which were using Fedex as an example of how great life will be with Web Services.
But after an hour or so of hunting, I didn't find any real examples of using the Fedex Web Services API with, for example, Java, which they included as one of the supported languages. I did come across several products that said they provided this functionality, but the one that I looked at required me to say what application it would be used with -- like, Outlook or Quickbooks, which made me wonder if I had misunderstood something.
Just to be clear, I'm imagining that the average user of Fedex Web Services will have, like me, a product and they know the weight and the dimensions of the shipping box. They know where it's shipping from, and they'd like to put in a Zip code for the destination and find out how much it will cost to send it ground, priority, standard and 2-day. Now that seems like, if Web Services are so great, it ought to be something one could bang out in a couple of lines of code, and voila, instant calculation of shipping costs! But if Web Services aren't real, then clues could be incomprehensible docs like the one mentioned above (if people were actually using it then someone would complain and they would fix the docs) and if you google for examples you don't find any.
I'd like Web Services to make my life easier, and I'll be perfectly happy if someone posts a comment that says "hey, Bruce, you didn't look far enough: here are the magical few lines you were looking for." But if it takes rocket science and another three weeks to figure out how to do the simple transaction in the previous paragraph, then I'm ready to wave goodbye to the Web Services bandwagon and wait for the Next Big Thing that will solve all my problems.
PS: I'm happy to buy a product -- that runs under Linux -- that will do the Fedex calculations for me. I wouldn't consider such a product a fulfillment of the promise of Web Services, but at least it would solve my immediate problems.
Here are a few documents, all one or two clicks from http://fedex.com/us/solutions/wis/index.html. Forgive me if I'm covering some ground you already have, but, from your post, it didn't look like you'd found these ones yet.
* The Fedex PDF document, "Web Integration Solutions (WIS) Seven-Step Implementation Guide", (http://fedex.com/us/solutions/wis/pdf/FedExAPIImplementationOverview.pdf) says "Note: If you are registering for the FSM Direct solution there will not be a download of software. You will receive appropriate documentation in email to begin development of this solution." So, if you didn't register before, now would be a good time.
Another point that may cause confusion is that Fedex are offering two interfaces here:
1. "FedEx Ship Manager API", which offers a programmatic interface and has a client side library component that must be installed, and only works on Windows, Linux and Unix.
2. "FedEx Ship Manager Direct", which offers a network level interface and is specified in terms of the XML messages that must pass back and forth over the network.
I'd be very surprised if the "API" software didn't use the "Direct" protocol, but, as a user, you don't need to look at C APIs if you want the network interface, and you don't need to understand XML messages if you want the programmatic interface.
On a slightly pedantic note, Fedex don't appear to be calling this a "Web Service". Rather they refer to it as a "Web Integration Solution", which is helpful as Web Services normally means SOAP and WSDL, and the Fedex interfaces use neither.
Finally, judging by the documentation, these interfaces to Fedex' systems are addressing the needs of large businesses with complex shipping needs. You can expect significant programming overhead in order to use it for apparently simple use cases.
While written in Perl, a port to Java might not be too bad. I have not used the module, so I can't tell you if it really works. It looks like it's almost two years old, but it's a good bet that the Fedex API has not changed much if at all in that time period, especially if no one is using it as you reason in your post. I hope this helps some.
I can thrash through/tolerate small bits of Perl now and again, and this looks fairly well thought out. And I couldn't find anything in the Python Cheeseshop (They had web services APIs for accessing Amazon S3 and Yahoo, but that's all). I also found a reference in a newsgroup to a Python module that apparently does exactly what I want -- get rate quotes.
You should be able to simply look in a public UDDI registry. Here you'll find everything that you need. The SOAP APIs, the XML schema...probably even some WSDL stuff.
But sorry...I can't point you to a UDDI registry...only the specs.
It's not the concept of web services that's the problem. It's not XML that's the problem. It's SOAP and WSDL. The concept of having a self-describing service is a good one but you shouldn't need a tool to make sense of it. The other big secret about Web Services is that different vendor implementations are not interoperable. I know this from experience. I even work with two tools from the same vendor that don't produce compatible WSDLs i.e. they can't communicate.
Gabriel Cooper has created a very nicely written Python package, posted about 1 year ago (relatively recent) to interact with Fedex and UPS. I haven't used it yet but the code is quite pleasant to read, so I suspect this may be my best solution: http://opensource.pseudocode.net/files/shipping.tgz However, this confirms my suspicion that there's nothing simple about getting a quote from Fedex.
I do find it interesting that one commenter pointed out that what Fedex offers isn't actually a Web Service, yet virtually everyone who writes an article or book about Web Services uses Fedex as an example. Seems like a disconnect there -- as if those authors didn't actually try it?
well atoms are a windows API (which mean you are using the Windows SOAP). But your comment about documentation, just read the javadoc for any product and you will see something like this:
public void foo(String arg)
arg the argument
now what parameter I suppose to use? justkillme is a good argument
Sorry to say that the title of this article is a bit on FUD side, and I respectfully disagree with Bruce on his question of "whether web services are real". In particular, his arsenal seems empty.
The key point is that any "service" or "interface" needs a semantic description of the service. When a service is fine grained (e.g. a Java class to calculate hashCode), the semantics may be self-explanatory. Things get harder with coarse-grained semantics. A WSDL saying that it can consume message M1 and return message M2, is not self-explanator. Documenting such semantics is not a technology problem but is a human problem.
> The key point is that any "service" or "interface" needs a > semantic description of the service. When a service is > fine grained (e.g. a Java class to calculate hashCode), > the semantics may be self-explanatory. Things get harder > with coarse-grained semantics. A WSDL saying that it can > consume message M1 and return message M2, is not > self-explanator. Documenting such semantics is not a > technology problem but is a human problem.
I agree with the esteemed Mr. Eckel that the hype may be a little out in front of web services.
However, I also feel your point is correct. I also think that web services don't eliminate the problem of design. A bad design is a bad design, regardless of the technology. I think a lot of times people either put all their faith in the new technology and assume it will make their beds, walk their dogs, and make them breakfast in the morning OR they don't believe in the new technology but are being ordered to use it so they don't use the technology as intended. Sometimes, they just don't know how to design APIs.
Flat View: This topic has 26 replies
on 2 pages
[
12
|
»
]
Previous Topic
