What is SOA in Web Services?
Service Oriented Architecture, or SOA, is a way of designing software so that individual services are able to communicate with each other over a network using a communication protocol.
Each service represents a single component of the overall application and should serve a specific purpose, taking an input and transforming it into a useful output. This makes SOA inherently task-specific, with individual services for processes like accepting a payment, retrieving an item like an order statement or managing a registered user account in some way.
It’s a hugely scalable and versatile way to build applications by adding new capabilities to them in a modular way, and it can also help to divide the development process into more manageable units that can be assigned to individuals and small teams. SOA has helped to increase collaboration in this way by allowing large development teams to work together without any harmful overlap between the tasks assigned to them — but all contributing towards a single core application.
However, traditional SOA has its drawbacks — as the total application size scales upwards, it can become difficult to avoid complexity, and provisioning a new version can take longer as the entire program code must be updated at once. This is where microservices help by splitting monolithic program code into many small, agile services that can be deployed independently. A platform like Kong can then define routes for data to take, essentially creating a chain of these input-output containers that take the supplied parameters and manipulate them several times over to achieve a singular goal.
We’ll look in more detail at this below, but it represents the next stage in Service Oriented Architecture — the ability not only to develop new services independently as individuals or small dev teams but also to deploy them in this way. Doing so keeps each microservice separate from the rest, allowing it to be documented, updated and ultimately retired or replaced much more agilely than if it were a function within a single monolithic enterprise application.
Combined with the original advantages of SOA, this evolution makes for a powerful, flexible way to build complex enterprise applications that are capable of working with data from different sources via different protocols and bringing it all together into a single datastore. As we will also see below, this has particular implications for the use of SOA in cloud computing deployments, unleashing the full potential of data that might historically have been siloed and allowing end-users to send requests from all kinds of desktop and mobile devices.
What is SOA?
SOA is not a platform in itself, but it is more a way of thinking about enterprise application development to underpin massive scalability, more simplified future development and flexible intercommunication between components in the application as a whole. Instead of all working within a single application, the different components are coupled loosely together, allowing the outputs of one to serve as the inputs of another, as well as recursive data routes that make use of the same component again and again.
This is still part of an overarching aim — a single enterprise application that takes data inputs from all the necessary sources and transforms them into the outputs you require — but it helps to avoid the inertia and sheer weight of monolithic application design. SOA as a concept has existed for many years, and the term Service Oriented Architecture is commonly attributed to former Gartner Analyst Alexander Pasik in 1994.
Modern SOA has a long list of common characteristics that define architecture as being truly service-oriented. Several of these relate to the granularity, modularity and independence of individual services within the overall application, their isolated responsibilities and the loose coupling between services that are intrinsically dependent on one another. Services should be reusable and should not duplicate other services; they should also be stateless, so that each time a particular service is requested, it starts from the same default state rather than remembering the result from its previous interaction.
They should also be modular — in this way, small services can combine to form larger services, which in turn can be requested or combined further all the way up to a single overall application with considerable complexity. It is important to recognize that Service Oriented Architecture is not the “dumbing down” of enterprise applications to reduce the overall capabilities that the application can deliver; it’s quite the opposite, in fact.
SOA enables fluid scalability and upgrades, allowing the application to grow and evolve with your changing needs, and new components to be added as and when new functionality is required. It is agile and developmentally liquid, ensuring applications can become incrementally more complex without adding exponentially to the development team’s administrative burden. Ultimately, SOA is a way to program the individual building blocks of your application, which can then be assembled, disassembled and reassembled over and over again in many different configurations to achieve the outcomes that are critical to your business success.
What is SOA in Web Services?
SOA and web services are not the same thing, nor are they mutually exclusive. SOA is a way of designing software to leverage the possibilities of programming in individual, independent yet loosely coupled services. Web services are a standards-based way to turn those conceived services into a reality, using web protocols like HTTP to request and get data.
The machine-to-machine interoperability of web services, thanks to their use of common standards, is ideal for distributed networks or for those that must allow public access via a range of different devices, platforms and operating systems. Web services themselves can be built around any one of several different technologies, and services built on different technologies can still interact with one another, again underpinning growth, evolution and complexity in a much more manageable way.
Over time, this allows migration to emerging technologies — such as the shift away from SOAP and towards RESTful APIs, which we’ll look at in more detail later — without the need to immediately replace older modules. Web services can be requested via Uniform Resource Identifiers or URIs — a more general version of Uniform Resource Locators or URLs. The URI can include input parameters, often supplied after a question mark at the end of the URI, making it incredibly easy to implement a way for end-users to supply their input to the web service.
For regular users of the internet and of networks in general, this has become a familiar, universal way to access online services, so whatever your services aim to achieve, the interaction with the end-user can be consistent. Web services, microservices and APIs are all ways to achieve this interactivity with end-users, retrieve the data and process it to achieve some outcome. In principle, the API is the interface itself, while the microservice or web service also includes the elements of program code that are not visible to users.
A microservice deployed online can be a web service; microservices deployed locally may technically not be web services, but in many use cases the terms are fairly interchangeable.
Like microservices themselves, much of the terminology used is connected yet independent and only loosely coupled — and refers to different levels in the software design:
- SOA relates to the overall approach, granularity and deployment of individual reusable services.
- Web services and microservices split monolithic enterprise applications into containers that can be deployed online or locally more flexibly.
- APIs represent the interface shown at the endpoints of these services for user interactions.
- SOAP, REST and other equivalent terms are the technologies used to build and deploy microservices.
- And underlying all of this are the different programming languages used to develop the code for individual services.
It’s a typical many-layered onion from general concepts right down to granular microservice development, and it maps well onto complex enterprise employee hierarchies where you might have individuals working within teams and working within departments, all the way up to the overall organization level. You can think of SOA as the idea and web services as the realization of that idea; however, it’s also important to remember that not all SOA takes advantage of the interoperability of web services or the granularity of microservices, as we’ll see next.
What is the Difference Between SOA and Microservices?
On the surface, the principles and benefits of SOA might sound the same as those of microservices, and the two do share parts of the same overall fingerprint. Like SOA, microservices give you the ability for individual, independent services to communicate with one another via a platform like the Kong API gateway — you’ll hear the term “loose coupling” used in reference to both.
However, SOA is an umbrella term not only for microservices architecture but more commonly for relatively monolithic, large-scale enterprise applications. These generally have a single application layer with multiple dependent Enterprise Serial Buses, or ESBs, and cannot offer the level of flexibility, agility and granularity that you can achieve using microservices.
Because of this, it’s important to understand that while microservices are a form of SOA, not all SOA delivers the significant and tangible benefits that you get with microservices. In fact, conventional SOA specifically does not deliver that level of flexibility; unlike microservices, which are inherently modular, traditional SOA instead integrates numerous services together into a single application.
The result can be complex, heavyweight, and more prone to performance issues and other risks that arise from the variety of different processes, all of which have the potential to slow down the app. Contrast this with the agility of microservices architecture. Unlike this monolithic approach of conventional SOA, microservices are modular, using independent strings of program code to achieve single, specific tasks.
By keeping microservices small and independent of one another, you can work on them separately, making it much easier for large enterprise applications to be broken down into individual services, which different programming teams and individuals can collaborate more easily across. Each microservice can be deployed and updated independently without taking the entire application offline, and a platform like the Kong API gateway allows them to transmit data to one another regardless of differences in programming language and other usually essential characteristics that they do not share.
This allows service-client and service-service communication, so you can create routes that define different data paths and transform that data one or several times in order to turn the initial input into a specific usable output in the desired format. Microservices are a natural evolutionary stage in SOA. Whereas Service Oriented Architecture took huge monolithic enterprise applications and divided them into separate services, microservices take this further for enhanced flexibility.
The result is a system that takes the benefits of SOA to a whole new level, making it easier to build new microservices, deploy them with minimal to zero downtime, scale by adding new microservices — again with minimal downtime — and maintain them for the future. As well as upgrading microservices with new versions as your development teams complete them, this approach also offers excellent redundancy. For example, if one part of an application develops a bug, it’s much easier to take that part offline and replace it quickly without suffering downtime across entire mission-critical enterprise applications.
Improved productivity, reduced programming and maintenance costs, and enhanced business resilience are all hallmarks of microservices that set them apart from the traditional view of monolithic SOA.
What is SOA Architecture in Java?
SOA architecture has plenty in common with “good” Java. Developing in Java benefits from a lean approach, with individual functions separated out from the program code as a whole. By calling these functions when they are needed, they can be replicated at different points in the overall program and supplied with different parameters in order to achieve specific outcomes each time.
However, the program as a whole is still monolithic, and this can mean that in order to install updates or repair bugs, the entire program must be taken offline. SOA and especially microservices, overcome this problem by allowing services to be programmed and deployed independently of one another, enabling different development teams to work on them separately and for fixes and upgrades to be deployed with no downtime for the application as a whole.
Since Java 6, the Java platform has included a web services stack in both the Standard Edition and Enterprise Edition, providing comprehensive support for the development of web services such as those used in SOA. Integrated tools and APIs enabled the development of RESTful web services and also SOAP-based services, which we’ll look at in more detail later.
Enterprise users, in particular, gained the ability to use Java to build web services within container-based environments, a key feature of SOA. Developing SOA web services in Java has several benefits. As mentioned above, the underlying principles of both are similar, with a focus on lean deployment and reusable functionality. Java is a common technology, making it a good choice for consumer-facing web services such as online shopping cart applications.
One example of this could be a system with individual services programmed in Java to provide the different elements of processing an ecommerce shopping cart:
- A graphical front-end service for the customer to access their cart
- Services to process payments and check credit ratings, etc.
- Back-end services to check stock and inventory management
SOA allows these different functions to be programmed independently and can enable rapid deployment of updates — for example, if you change the way you process payments or need to implement new security features. For customers, it can also provide continuity, as back-end updates can be deployed seamlessly with little to no interruption of service and no visible changes at the consumer-facing end.
What is Service Oriented Architecture in the Cloud?
Cloud computing revolutionized the delivery of services from storage to data backup to the way applications are provisioned to end-users, including in an enterprise setting. Some of the advantages of cloud computing are closely aligned with those of Service Oriented Architecture.
For example, cloud computing enables massive scalability. Services can be implemented and billed on the basis of usage, including scalable end-user licenses that can grow as the organization’s demand increases over time. In principle, cloud computing means the end of data silos. Mission-critical files can be stored on remote servers, meaning they are not lost if an individual workstation fails.
This can enhance collaboration by allowing multiple individuals and teams to work on the same instance of the same file — complete with version tracking and tools to prevent one developer from overwriting the work done by another. However, it is important to avoid shifting the problems of silos into the cloud. In the early days of cloud computing, the data moved online was often stored in proprietary ways, which made it difficult to switch provider or to extract that data if the provider went out of business or deprecated that particular service.
Service Oriented Architecture helps to overcome these issues by putting an end to platform-specific data and ensuring that data can be relocated if a specific cloud service ceases for any reason. The versatility and platform agnosticism of SOA, and especially of microservices, makes it easier to integrate external, third-party cloud computing services with those developed in-house, even if they use different programming languages, protocols and policies.
SOA also creates opportunities to overcome some of the related problems of third-party cloud computing, such as concerns relating to security and authentication. All of this is done in a massively scalable way that can grow with your organization and provide enterprise-level performance via low-latency, high-speed network connections. Data is valuable, and breaking it out of siloed storage is crucial to the modern era of business — SOA and cloud computing work together to achieve this by giving you ways to combine data from different sources into a powerful, central datastore.
Incoming information can be authenticated and checked for security policies, allowing company-wide SOA governance to be adopted for more effective administration. Activity can be monitored using real-time analytics, allowing you to adapt and respond quickly to changing demand, as well as track costs and rising demand levels as they scale — all while ensuring your departments benefit from a sense of ownership over their respective resources.
How Does SOA Architecture Work?
SOA architecture allows you to break down complex applications into their individual component parts. In a profit-making enterprise, you can put the focus on developing services that enable you to maximize those profits. They could be back-end tools to boost employee productivity or internal APIs that make it easier to manipulate internal data in a profitable way.
On the customer-facing side, services could be a way to introduce new features and functionality, create opportunities for up-selling, or simply a new API that makes it easier for your customers to interact with your core business.
The great advantage of SOA architecture, especially using microservices and web services, is that these different customer-facing and back-end services can be developed separately from one another, allowing you to adopt the techniques that work best for both. For example, customers might demand faster, more seamless integration of different features into an application that runs for them as an apparently singular entity.
Meanwhile, internally, it may be much more possible to run stripped-down APIs with less decorative interfaces, tools that run individually and independently without a central interface to access them all, and services that take longer to complete their assigned task. With lean programming, it should be possible to complete even internal and resource-heavy tasks much faster, thanks to the ability to define streamlined routes for your data and to reuse modules that must be called more than once in the process.
And it doesn’t stop with internal vs. external APIs — there’s a whole spectrum in between, from distributed wide area networks that need to provision services securely to branch offices to flexible working contracts that create a need for authenticated access for employees working from home, or anywhere else for that matter. In addition to internal employees and external customers, you may need to provide authenticated, authorized and secure access to contractors, third-party suppliers, vendors and affiliates, among an ever-growing list of agents and entities.
SOA allows you to do this using different protocols for internal, external and third-party access as required, with the ability to define different policies for user groups, limits on the number of requests and total traffic transferred, and so on. And this is all without considering the physical hardware advantages of deploying hosted microservices across a cluster of nodes, with load balancing to ensure each physical machine is tasked with an equal share of the traffic.
Platforms like the Kong API gateway play a crucial role in enabling the effective administration of complex applications that run on microservices, web services and APIs.They give you a central dashboard with the ability to define individual services — which map on to the microservices you have deployed — as well as routes that determine how data is transmitted from input, via one or more services, to output. Using a platform like Kong Gateway or Kong Enterprise, you can retrieve requests made by end-users via your web services, complete the necessary data transaction and send a response back in a standards-compliant format that the customer is expecting.
It’s fast, seamless and familiar for individuals who you might have never interacted with before and may never transact with again. Again, SOA is not about making development generic but the opposite, allowing you to develop services to suit internal, external and third-party audiences using the appropriate policies and protocols for each user group.
However, it gives you a way to enable communication between these independent services so that the data they return can be manipulated in versatile and complex ways to achieve the profitable outcomes that your business requires.
What is the Role of SOAP in SOA?
SOAP was (and still is) a messaging protocol used in web services, especially in enterprise web applications. It stands for Simple Object Access Protocol and should not be confused with SOA, despite the similar-looking acronyms.
SOAP was first developed in 1998 and was published as a W3C Note in May 2000; while version 1.1 never achieved W3C Recommendation status, this honor was granted to version 1.2 in June 2003. Because of this, five years after its initial inception, SOAP could be rightfully considered to be a “standard” and was soon adopted as a popular option for enterprise applications. SOAP uses Extensible Markup Language (XML) to communicate between different processes which can run on different operating systems, thanks to the commonality of web protocols like HTTP.
Again, SOAP offers some of the main benefits of SOA:
- Ability to extend functionality by developing extensions
- Ability to operate over different protocols like HTTP, TCP, SMTP and more as needed
- Ability to operate independently of programming model
However, over the past decade, SOAP has largely been replaced by Representational State Transfer (REST) as the preferred way to access and modify web resources via HTTP. Data from Google Trends shows that REST API overtook SOAP API in terms of popularity in Google searches around the end of 2008 and has remained in the lead since 2009.
However, SOAP remained popular for enterprise APIs and especially for private APIs, with no public-facing access outside of the enterprise. Because of this, SOAP continues to play an important role in enterprise SOA, and in many cases, it’s chosen for enterprise development as a matter of personal preference as much as anything else.
One further thing to note is that a SOAP request will typically transfer significantly more data than a RESTful API request. That can have a bearing on performance, especially for networks with limited bandwidth or where huge volumes of requests are transmitted, multiplying that extra data many times over.
While it had its day, SOAP is increasingly obsolete and those enterprise apps — even internal/private enterprise APIs — are seen more and more as a deprecated legacy option, rather than one for active future development. Perhaps one of the most significant benefits in favor of RESTful APIs over SOAP is REST’s ability to interact well with lightweight clients.
Over the past decade, devices like smartphones and tablets have increasingly become the first choice for all kinds of public and private interactions. REST makes it easier to support these devices — one more reason why SOAP has declined in popularity over that time and is likely to disappear from SOA platforms as the existing legacy enterprise applications gradually become obsolete in the coming years.
SOA means that data generated by SOAP web services can be integrated into a datastore for use by other web services and internal microservices. If you have older SOAP services that are still critical to your business and you don’t want to replace them immediately, SOA could provide you with an important stepping stone towards doing so more gradually.
By deploying SOA and a platform like Kong Enterprise, you can start to introduce services and APIs built around more recent technologies like REST without immediately retiring your aging SOAP services. Over time, this can enable you to replace older SOAP services one at a time, with little to no downtime, or simply to retire them as they become obsolete. It’s a great way to future-proof your investment on service development while making it easier for your dev teams to do their job by splitting a single monolithic upgrade into smaller, bite-sized milestones that end with the deployment of a newly developed microservice.
Want to learn more?
Request a demo to talk to our experts to answer your questions and explore your needs.