Service-Oriented Architecture and web services
If you would ask ” what SOA is ? ” you would likely receive two very different, possibly conflicting, answers. Some relate it to the use of Web Services and WSDL, although other technologies like CORBA and DCOM existed a long time before webservices as approches for implementing a loosely coupled architecture. Others confuse the concept of Service Oriented Architecture with Service Oriented implementations , which leads to chaotic and unpredictable results!
If you’re reading this article, I can tell you’re searching for the less confusing definition or explanation for SOA. For, we’ll have a first initiating-to-SOA section about human-centric and application-centric web, interoperability and middlewares, and a second section about the gist.
Human-centric web vs Application-centric web
Humain-centric web is a notion indicating that users are the principal initiators of the requests between themselves and the web application. While application-centric web is a term that refers to web apps where a communication between different multiple applications is allowed inorder to serve the user as an endpoint.
Integration vs Interoperability and Middlewares
There is no better way to explain what system integration and system interoperability are than the real life example of charging our cellphones ! If you needed to charge your phone, you’ll take your charger, connect it to the power source on one end and to your phone on the other and you are served ! In this case, the two interfaces are designed in such a way that they work together. That’s how Intergration works: connecting different computing systems, software applications, and communication infrastructure together to get one whole system.
Now if you travel to a different country, that’s when you’re in trouble! You’ll find a different type of power sources! a complete interface mismatch. These components were not designed in a way that allows them to be integrated right away. The solution is to get a power adapter, an element of mediation. That’s how interoperability works: architecting a solution that allows to integrate different systems together.
The power adapter simulates what’s called Middlewares in software.
Putting it all together!
In the few previous lines we’ve seen that we can build software by putting together different systems or components. Which can be realised through a middleware and using certain paradigms in programming the whole system. Also we went briefly through human-centric web and application-centric web . With web services, we move from a human-centric web to an application-centric web.
Simply defined, web services are business and consumer applications, delivered over the Internet, that we can select and combine through almost any device from personal computers to mobile phones. By using a set of common protocols and standards. These applications will permit disparate systems to “talk” with one another and to share data and services without requiring human beings to translate the conversation.
Unlike traditional client/server models, web services do not provide the user with a GUI. They instead share business logic, data and processes through a programmatic interface across a network. Developers can then add the web service to a GUI (such as a web page or an executable program) to offer specific functionality to users. So web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, web services are not tied to any one operating system or programming language. For example, Java can talk with Perl and Windows applications can talk with UNIX applications.
It exists two main families of webservices: SOAP (Simple Object Access Protocol) webservices and REST (Representational State Transfer) webservices. We’ll go through each in the coming posts/tutorials.
Service oriented architecture
A service-oriented architecture is basically a collection of services. Services carry out some small function, such as producing data, validating a customer, or providing simple analytical services. So conceptually SOA is, a software implementation approach of loosely coupled and reusable services. Technically, SOA is the integration of these services or artifacts through a wide variety of platform independent service interfaces. Therefore, each service has an implementation and an interface which allows it to communicate with other services.
SOA has three elements: service consumer, service provider and service broker. In the following tutorials about webservices we will explain the role of each element.
SOA lowers implementation costs by increasing reusability; services can easily be shared across multiple applications. It enables incremental development, deployment, and maintenance, increases organizational agility and has much other characteristics which we’ll study in the following set of posts/tutorials.