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…
Today, I’m going to take a look at SOA (Service-Oriented Architecture) from a different angle that is often overlooked. SOA governance is sometimes an after thought, though critical to the enterprise.
SOA governance is best defined by Anne Thomas Manes as: “The processes that an enterprise puts in place to ensure that things are done … in accordance with best practices, architectural principles, government regulations, laws, and other determining factors. SOA governance refers to the processes used to govern adoption and implementation of SOA.”[1]
One of the risks that emerge as more and more applications become integrated is the spreading of bad data (e.g. invalid, incomplete, etc.). Misinformation and bad data constantly challenge organizations today. Engaging in SOA activities without consideration for governance is like opening up a four lane highway with no cops to patrol it. Controlling life cycles and versioning, governing people, policies, design-time, run-time and processes to establish and maintain desired behavior are examples of SOA governance. 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
Enterprise Service Busses (ESBs) have become a popular communication mechanism in middleware infrastructures, allowing organizations to implement messaging systems that facilitate collaboration among disparate applications and software services. All communication between components takes place via messaging on a “bus”, removing direct contact and introducing a loosely-coupled architecture into the infrastructure. Messages are published to the bus and received by subscribing to the bus. To avoid all of the messages swirling around in one large pool, the concept of topics (sometimes referred to as channels or queues) provides a degree of separation.
To make messaging effective in this design, a common messaging model must define the messages both sent and received by the ESB. These models usually include specifications for the payload of the message and any control information that is passed along. Messages can be data-centric, containing a payload, or command-level where processing instructions can be carried, such as starting/stopping a service.
ESBs also make an effective core data transport for Service-Oriented Architectures (SOA), although they are not required to implement an SOA. They are, however, a key part of an Enterprise Integration strategy and leverage many of the Message Exchange Patterns (MEPs) in use today, such as Publish/Subscribe (leveraged in communication protocols), Competing Subscriber (often used in load-balancing schemes) and Idempotent Subscribers (ensuring that you only receive one copy of a message).
The strength of an ESB lies in its ability to send/receive messages, route them based on content, transform them into other formats, and/or publish them to additional channels. The ESB becomes the “hub” of your infrastructure, connecting all of your disparate systems and services, allowing them to communicate in new ways.
Read more…