Service-Oriented Architecture

Service-Oriented Architecture (SOA) is considered a piece of cohesive integration glue that ties all the available computing services together across an organization. In enterprise integration, SOA is essentially a set of design and implementation principles that can guide integration practitioners to design and develop interoperable support services that are derived from individual enterprise applications in an organization, facilitating smart integration across distributed applications so that all business domains in the organization can strive for a common business goal in a competitive way. This chapter first discusses SOA fundamentals, covering all the design principles and underlying supporting technologies. As organizations would have different business priorities in integrating their distributed applications, different practical integration entry points to SOA design and implementations are then articulated. Finally, Malvern iStore’s SOA attempts to meet the dynamics business needs are an illustrative example presented in this chapter.

Author(s):  
José Carlos Martins Delgado

The Service-Oriented Architecture (SOA) and Representational State Transfer (REST) architectural styles are the most used for the integration of enterprise applications. Each is more adequate to a different class of applications and exhibits advantages and disadvantages. This chapter performs a comparative study between them. It is shown that SOA and REST are dual architectural styles, one oriented towards behavior and the other towards state. This raises the question of whether it is possible to combine them to maximize the advantages and to minimize the disadvantages. A new architectural style, Structural Services, is proposed to obtain the best characteristics from SOA and REST. As in SOA, services are able to offer a variable set of operations and, as in REST, resources are allowed to have structure. This style uses structural interoperability, based on structural compliance and conformance. A service-oriented programming language is also introduced to instantiate this architectural style.


Author(s):  
Raghav Goel and Dr. Bhoomi Gupta

Are you a software engineer/developer/coder or maybe even a tech enthusiast who is thinking of agility, parallel development and reducing cost. In the early twentieth century, we witnessed the rise of Service Oriented Architecture (SOA), which is a software architecture pattern that allows us to construct large-scale enterprise applications that require us to integrate multiple services, each of which is made over different platforms and languages through a common communication mechanism, where we write code and multiple services talk to each other’s for a business use case, but sometimes we end up with one big monolithic code base whose maintenance becomes difficult. Nowadays clients are using cloud and paying for on-demand services without effectively utilizing resources. These problems invite micro-services. In this paper, I am going to discuss how one should use scale application in a production environment and local machine


Author(s):  
Vinay Raj ◽  
Ravichandra Sadam

Service oriented architecture (SOA) has been widely used in the design of enterprise applications over the last two decades. Though SOA has become popular in the integration of multiple applications using the enterprise service bus, there are few challenges related to delivery, deployment, governance, and interoperability of services. To overcome the design and maintenance challenges in SOA, a new architecture of microservices has emerged with loose coupling, independent deployment, and scalability as its key features. With the advent of microservices, software architects have started to migrate legacy systems to microservice architecture. However, many challenges arise during the migration of SOA to microservices, including the decomposition of SOA to microservice, the testing of microservices designed using different programming languages, and the monitoring the microservices. In this paper, we aim to provide patterns for the most recurring problems highlighted in the literature i.e, the decomposition of SOA services, the size of each microservice, and the detection of anomalies in microservices. The suggested patterns are combined with our experience in the migration of SOA-based applications to the microservices architecture, and we have also used these patterns in the migration of other SOA applications. We evaluated these patterns with the help of a standard web-based application.


Author(s):  
Surya Nepal ◽  
John Zic

In the Service Oriented Architecture (SOA) model, a service is characterized by its exchange of asynchronous messages, and a service contract is a desirable composition of a variety of messages. Though this model is simple, implementing large-scale, cross-organizational distributed applications may be difficult to achieve in general, as there is no guarantee that service composition will be possible because of incompatibilities of Web service contracts. We categorize compatibility issues in Web service contracts into two broad categories: (a) between contracts of different services (which we define as a composability problem), and (b) a service contract and its implementation (which we define as a conformance problem). This chapter examines and addresses these problems, first by identifying and specifying contract compatibility conditions, and second, through the use of compatibility checking tools that enable application developers to perform checks at design time.


2010 ◽  
Vol 2 (2) ◽  
pp. 38-50
Author(s):  
Tony Polgar

Web Services for Remote Portlets (WSRP) provide solutions for implementation of lightweight Service Oriented Architecture (SOA). UDDI extension for WSRP enables the discovery and access to user facing web services provided by business partners while eliminating the need to design local user facing portlets. Most importantly, the remote portlets can be updated by web service providers from their own servers. Remote portlet consumers are not required to make any changes in their portals to accommodate updated remote portlets. This approach results in easier team development, upgrades, administration, low cost development and usage of shared resources. Furthermore, with the growing interest in SOA, WSRP should cooperate with service bus (ESB).In this paper, the author examines the technical underpinning of the UDDI extensions for WSRP (user facing remote web services) and their role in service sharing among business partners. The author also briefly outlines the architectural view of using WSRP in enterprise integration tasks and the role Enterprise Service Bus (ESB).


Author(s):  
Wail M. Omar

Web 2.0 is expected to be the next technology in the interaction between the enterprise applications and end users. Such interaction will be utilized in producing self-governance applications that are able to readjacent and reconfigure the operation framework based on users’ feedback. To achieve this, huge numbers of underneath resources (infrastructures and services) are required. Therefore, this work proposes the merge of Web 2.0 technology and grid computing overlay to support Web 2.0 framework. Such merge between technologies is expected to offer mutual benefits for both communities. Through this work, a model for managing the interaction between the two technologies is developed based on the adapting of service oriented architecture (SOA) model, this model is known as SOAW2G. This model manages the interaction between the users at the top level and resources at the bottom layer. As a case study, managing health information based on users’ (doctors, medicine companies, and others) experiences is explored through this chapter.


Sign in / Sign up

Export Citation Format

Share Document