SOA

In computing, service-oriented architecture (SOA) provides a set of principles or governing concepts used during phases of systems development and integration. Such an architecture will package functionality as interoperable services. It is an attempt to develop yet another means for software module integration. Rather than defining an API, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation.

In computing, service-orientation is a design paradigm that specifies the creation of automation logic in the form of services. It is applied as a strategic goal in developing a service-oriented architecture (SOA). Like other design paradigms, service-orientation provides a means of achieving a separation of concerns.

Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services[1], which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.

 

SOA implementations rely on a mesh of software services. Services comprise unassociated, loosely coupled units of functionality that have no calls to each other embedded in them. Each service implements one action, such as filling out an online application for an account, or viewing an online bank-statement, or placing an online booking or airline ticket order. Instead of services embedding calls to each other in their source code they use defined protocols that describe how services pass and parse messages, using description metadata.

Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-container. Analogously, the Web Services Description Language (WSDL) typically describe the services themselves, while the SOAP protocol describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will become/remain the favorites in the future, remain open questions. As of 2008[update] SOA depends on data and services that are described by metadata that should meet the following two criteria:

  1. The metadata should come in a form that software systems can use to configure[clarification needed] dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity.

  2. The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.  

SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the n-th application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application.

 

Service Component Architecture: Build systems using SOA

Service Component Architecture (SCA) is a set of specifications which describe a model for building applications and systems using a Service-Oriented Architecture. 

 

SCA divides up the steps in building a service-oriented application into two major parts: 

SCA emphasizes the decoupling of service implementation and of service assembly from the details of infrastructure capabilities and from the details of the access methods used to invoke services. 

SCA supports service implementations written using any one of many programming languages such as Java™, PHP, C++, COBOL, XML-centric languages such as BPEL and XSLT, and also declarative languages such as SQL and XQuery. 

SCA supports bindings to a wide range of access mechanisms used to invoke services. These include Web services, Messaging systems and CORBA IIOP. 

SCA also promotes the use of Service Data Objects to represent the business data 

The SCA specification is divided into a number of documents:  

 

Service Data Objects

Put simply, SDO is a framework for data application development, which includes an architecture and API. SDO does the following: 

The Service Data Objects framework provides a unified framework for data application development. With SDO, you do not need to be familiar with a technology-specific API in order to access and utilize data. You need to know only one API, the SDO API. 

Web Data Objects, or WDO, is the name of an early release of SDO shipped in IBM WAS. 

JDO stands for Java Data Objects. JDO looks at data programming in the Java environment and provides a common API to access data stored in various types of data sources; for example, databases, file systems, or transaction processing systems. JDO preserves relationships between Java objects (graphs) and at the same time allows concurrent access to the data. 

EMF and SDO both deal with data representation. In fact, IBM's reference implementation of SDO, which we'll use later in this article, is an EMF implementation of SDO. EMF code generation was even used to create some of the SDO implementation, based on a UML model definition of SDO itself.