(This is the third in a series of articles that attempts to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.)
This is somewhat related to the previous post about trying to be too flexible. However, usually this problem is accidental, where the previous was intentional. This problem also is usually the result of misunderstanding or misusing a Web Services development tool.
XML has an element type called “any.” It basically means, “Anything that is valid XML is OK here.” It’s a way to make your document more flexible without the burden of defining type extensions. It should be used very sparingly though, because the point of a structured data format like XML is to define a structure for a piece of data. When you use the “any” element, it completely ignores that point and allows any structure.
One cause of this problem is misuse of a Web service tool. There are many tools available to ease your creation of Web services. There are tools for most programming languages where you can hand it a business object, and it will generate a WSDL that defines an XML version of that object, and even the code to handle transferring it and converting it into the actual object. You just then need to write the code that does the real work. The tool does all the mundane communication work. Read more…
(This is the second in a series of articles that attempt to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.)
XML is a quite flexible data format. It allows the user many options, such as Choices, Sequences, Complex Types, Type Extension. But the flexibility can very easily be overdone. While it may seem like a good idea to have your service be flexible, it also makes using the service that much harder to use because of all the different formats that need to be handled.
A good example of taking flexibility too far is the SalesForce.com Web Services interface. It takes the idea of Type Extension to the absolute extreme. For those not familiar with Type Extension, see this tutorial. Type Extension can be very useful when you have types that are mostly similar, with just a few extra attributes added onto the extended types. For example, a good usage could be a personnel data model. Read more…
In my last blog, I talked about UDDI (Universal Description, Discovery and Integration) including where it’s been and where it might be going. In this article I’m going to take a different look at UDDI and consider the question, how useful is it to find what you’re looking for? One aspect of UDDI that has been overlooked by OASIS (Organization for the Advancement of Structured Information Standards), the Web Services standards body, is how to find services faster and more efficiently.
UDDI allows service providers to publish data about themselves and their Web Services, and supports simple searching for services. The standard UDDI search uses a single search criterion, such as business location, business name, service type by name, business category or business identifier. This limits the efficacy of UDDI for general service discovery. An example is searching by business category; the search might return the service you want, but you might need to filter the results to find it. Read more…
Since EBI and ESX exchange critical data, administrators must know immediately if there was an error with either processing or transferring of documents. Email notifications can be sent from both EXTOL products when failures occur, but this kind of notification may not be effective when the administrator is away from their PC but still has their mobile phone handy. With small modifications, email notifications can become TXT notifications.
Most mobile carriers provide email to SMS gateways. A list of carriers providing SMS transit can be found here. Simply look up the mobile carrier that will receive the TXT message and change the recipient’s email address with the appropriate email format found in this list. Now all email notifications will be sent as TXT messages.
The minor problem with this approach is knowing the recipient’s mobile carrier. If you want to be agnostic of mobile carriers, then there are commercial Web Services available for sending TXT messages. A reliable SMS service I’ve used for years has been from abctext.com (which is about $0.13 per message). They support delayed TXT’ing, bulk messaging, a control panel displaying which TXT messages that were sent, and more. Unfortunately, since you may only interact with abctext.com through Web Services, only EBI can be used to send TXT notifications in this way.
There are a lot of useful SOAP Web Services. Whether it is a simple zip code lookup service, or a more complex order entry system, a well-implemented SOAP Web Service can make machine to machine communication very reliable, efficient, and best of all, easy.
However, there are also a lot of poorly-implemented SOAP Web Services, and they can cause more problems than they intend to solve. This is the first in a series of articles that attempt to expose some of the more common mistakes and misunderstandings people make when implementing a SOAP Web Service.
SOAP Worst Practice #1: Non-XML Content
One of the main reasons to create a SOAP Web Service over a REST one is that SOAP provides a standardized method to publish the message format for your service. The message is in XML, and its structure is defined in the WSDL, or Web Service Definition Language. If you have an XML document that you want to transfer, embed its format in the WSDL and any consumer will be able to know the format to send to it.
But, if you have non-XML data to transfer, SOAP is probably not your best choice. Read more…
I get asked the same question every couple of months: Is UDDI dead? For years, people have been discussing UDDI and the lack of use that will cause its death. Here’s the back story on UDDI.
UDDI stands for Universal Description, Discovery and Integration, and it is an XML-based standard for publication of service listings and their subsequent discovery by service users. UDDI is often compared to a telephone book with white, yellow and green pages, it and allows businesses to list themselves by name, product, location or the (Web) services they offer.
Read more…
A Web Service is any “service” that is available over the Internet, using a standardized XML messaging system, and is not tied to any one operating system or programming language.
Example Web Service Implementation:
MyCompany receives purchase orders from UPS and during the translation process uses an HTTP connection to interface with an existing UPS Web Service. Through this Web Service MyCompany verifies addresses, retrieves tracking information, sends (SMS) text messages, and performs currency conversions (among other functions). This Web Service provides MyCompany access to information from the UPS tracking database needed inside MyCompany application and is achieved without complex programming. Read more…
The Web Services hype is over and its usage in production software and services is a reality. We implemented both flavors of Web Services (SOAP and REST) in our EBI product because we knew Web Services would be very useful to our customers in the integration world. Users can configure EBI to use Web Services to invoke APIs from public services. The purpose of this blog is to focus on one of these public Web Services: PostalMethods. Read more…
In this blog, the age old discussion of “Which is Better: SOAP or REST?” will be discussed, and challenges associated with your decision. I’m going to list advantages and tradeoffs of each, but first let’s start with a little background information little background information.
What is a REST Web Service?
The acronym REST stands for REpresentational State Transfer, meaning each unique URL represents some object. The architecture was developed by Roy Fielding, one of the authors of the Hypertext Transfer Protocol (HTTP). A REST Web Service uses HTTP and supports the HTTP GET, POST, PUT or DELETE methods. Read more…