If you’ve ever dealt with changes to a working version of a schema, whether it is database, EDI, XML, or whatever format your data may be in, then you know how painful it is. In most shops in the typical data processing scenario, either a tool or a custom program is used to process the data in one format and convert it to another format to be piped off for further processing somewhere else. The most difficult to deal with example can be changes to an XML schema. The reason is that XML is so extensible and just about anything can be done with it. The contrasting example would be EDI data where the changes are usually miniscule and the structure itself does not vastly change. The typical example that most IT shops face is a change in a database which could be the addition of a table or column, the deletion of a table or column, the moving of a table or column, or a change in table/column properties.
If we look at this from the perspective of a model, a schema is really a tree or graph (depending on whether it’s recursive) with entities representing the schema structure. Continue reading →
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. Continue reading →
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. Continue reading →
In my previous post, I gave a brief introduction to Web Services and started to discuss PostalMethods, one of many public Web Services available that can be invoked by EBI. Today’s blog will focus on how I configured EBI to use the PostalMethods API along with some useful features that can taken advantage of in their control panel.
Before constructing an Invoice spreadsheet that I was going to use for this proof of concept, I still needed to know how to submit the recipient’s address to PostalMethods. PostalMethods supports two methods of submitting the recipient’s address Continue reading →
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. Continue reading →