| Service-oriented architecture (SOA) is a software development model for distributed application components that incorporates discovery, access control, data mapping and security features. There are three major objectives of SOA, all which focus on a different part of the application lifecycle: The first objective aims to structure procedures or software components as services. These services are designed to be loosely coupled to applications, so they are only used when needed. They are also designed to be easily utilized by software developers, who have to create applications in a consistent way. The second objective is to provide a mechanism for publishing available services, which includes their functionality and input/output (I/O) requirements. Services are published in a way that allows developers to easily incorporate them into applications. The third objective of SOA is to control the use of these services to avoid security and governance problems. Security in SOA revolves heavily around the security of the individual components within the architecture, identity and authentication procedures related to those components, and securing the actual connections between the components of the architecture. SOA is a broad architectural model that defines the goals of an application, as well what approaches will be used to meet those goals. Developers must define specific implementation specifications, usually linked to the formal Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP) specifications. The emergence of SOA For decades, software development required the use of modular functional elements that perform a specific job in multiple places within an application. As application integration and component-sharing operations became linked to pools of hosting resources and distributed databases, enterprises needed a way to adapt their procedure-based development model to the use of remote, distributed components. Simple models like the remote procedure call (RPC) were a start in the right direction, but RPC lacked the security and data-independent features needed for truly open and distributed operations. The solution to this problem was to redefine the old operation model into a broader and more clearly architected collection of services that could be provided to an application using fully distributed software components. The architecture that wrapped these services in mechanisms to support open use under full security and governance was called the service-oriented architecture, or SOA. SOA was introduced in the late 1990s as a set of principles or requirements; within a decade, there were several suitable implementations. WS and WSDL models Initially, SOA implementations were based on the RPC and object-broker technologies available around 2000. But SOA quickly split into two camps. The first is the web services (WS) camp, which represents highly architected and formalized management of remote procedures and components. The second is the representational state transfer (REST) camp, which represents the use of internet technology to access remotely hosted components of applications. The WS model of SOA uses the WSDL to connect interfaces with services and the SOAP to define procedure or component APIs. WS principles were used to link applications via an enterprise service bus (ESB), which helped businesses integrate their applications, ensure efficiency and improve data governance. A whole series of WS standards were developed and promoted by industry giants, such as IBM and Microsoft. These standards offered a secure and flexible way to divide software into a series of distributed pieces. However, the model was difficult to use and often introduced considerable overhead into the workflows that passed between components of an application. The WS model of SOA never reached the adoption levels that advocates had predicted; in fact, it collided with another model of remote components based on the internet: REST. RESTful application program interfaces (APIs) offered low overhead and were easy to understand. As the internet integrated more with applications, RESTful APIs were seen as the future. SOA and microservices The tension between SOA as a set of principles and SOA as a specific software implementation came to a head in the face of virtualization and cloud computing. The combination of virtualization and cloud encourages software developers to build applications from smaller functional components. Microservices, one of the critical current software trends, was the culmination of that development model. Because more components mean more interfaces and more complicated software design, the trend exposed the complexity and performance faults of most SOA implementations. Microservice-based software architectures are actually just modernized implementations of the SOA model. The software components are developed as services to be exposed via APIs, as SOA would require. An API broker mediates access to components and ensures security and governance practices are followed. It also ensures there are software techniques to match diverse I/O formats of microservices to the applications that use them. But SOA is as valid today as it was when first considered. SOA principles have taken us to the cloud and are supporting the most advanced cloud software development techniques in use today. | 
Posts
No comments:
Post a Comment