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…
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…
There are a number of blogs, discussion groups, podcasts, etc. talking about Service-oriented Architecture (SOA) and Service-oriented Integration (SOI). Instead of focusing on them individually, this blog focuses on using them together for better ROI results.
Service-oriented Integration (SOI) is the practice of using XML over HTTP (e.g. Web Services) to achieve interoperability between applications and services – for example, wrapping a legacy application function and exposing it to other applications, services, and business partners. Service-oriented architecture (SOA) encompasses architecture principles and best practices that guide the design and implementation of SOI, including methods that minimize coupling, complexity, and functional overlap. Most SOA initiatives start with the need to integrate an application; I believe the reason why companies fail and overspend on SOA initiatives is due to the lack of consideration for SOI and SOA together.
Read more…
Categories: Service-oriented Integration Tags: architecture, HTTP, integration, mid-sized business, REST, ROI, service-oriented, small business, SMB, SOA, SOAP, SOI, spreadsheets, XML