Service Oriented Architecture

Service Oriented Architecture (SOA):

SOA requires loose coupling of services with the operating systems and other technologies that underlie the application. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications.

Services are unassociated, loosely coupled units of functionality. Each service define a protocol / API on how other applications can use that service. SOA is about re-using existing components / services, and structuring your application as a collection of services so that each services can be re-used in other applications over a network

SOA focus on building services. It does not focus on building your application. SOA encourage us to structure our application as a collection of services so that each service can be re-used in our application and possibly in other applications. At some point, we need to implement our application. So, what is the difference between an application and a service? There is not much difference between an application and a service. An application can be a service and a service can be an application. An application is a collection of services with a human-friendly user interface, whereas the interface for a service is more of machine-friendly interface such as an API. We can build our applications using our services. However, we have limited resources and imagination. If we structure our application as a collection of services, and we expose an interface for those services, those services can be re-used in other applications (applications that we couldn't even imagined or thought of) that are developed outside of our organizational unit.

Facebook, Twitter, and Google use the concept of SOA to enhance their ecosystem. They build the services, the platform that host other applications, and let other developers improve their usefulness. This does not mean that we let other developers run wild and do anything they want. Facebook, Twitter and Google all have rate-limiting imposed on their API, and they all define what is the legal-usage of their services.

By exposing an API for our services, and allowing other developers outside of our organizational units to mix and match our services to create applications that are more suitable for their situations or needs, we create more value for our services.

If we structure our application as a collection of services, we should be able to re-face our application / platform to support new devices without having to change our existing services.

The following guiding principles define the ground rules for SOA:

  • re-use, granularity, modularity, composability, componentization, and interoperability
  • standards-compliance (both common and industry-specific)
  • service-identification, categorization, provisioning, delivery, monitoring, and tracking
  • Standardized service contract: Services adhere to a communication agreement as defined collectively by one or more service-description documents
  • Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
  • Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world
  • Service re-usability: Logic is divided into services with the intention of promoting re-use
  • Service autonomy: Services have control over the logic they encapsulate
  • Service statelessness:Services minimize resource consumption by deferring the management of state information when necessary
  • Service discoverability: Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted.
  • Service composability: Services are effective composition participants, regardless of the size and complexity of the composition.

SOA Manifesto:

  • Business value over technical strategy
  • Strategic goals over project-specific benefits
  • Intrinsic interoperability over custom integration
  • Shared services over specific-purpose implementations
  • Flexibility over optimization
  • Evolutionary refinement over pursuit of initial perfection

Within an enterprise, services should be discoverable via some kind of registry (an inventory system for services that are available or deployed within the enterprise). An example of a service contract is available from SOA under the "Programmatic service contract" section.

Business users should be able to quickly view the list of available services. Do business users actually care about this?

An indirect benefit of SOA is that it simplifies testing. Each service is tested separately which lead to higher quality. services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation.

Implementation technology / protocols:

  • SOAP
  • RPC
  • DCOM
  • Web Services
  • DDS
  • Java RMI
  • Windows Communication Foundation (WCF)

Implementations can use one or more of these protocols. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having detail knowledge of the calling application, and without the application having or needing to knowledge of how the service is actually implemented.

These services inter-operate based on a formal definition (or contract, e.g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides the implementation of the language-specific service.

SOMF (Service Oriented Modeling Framwork)
The ossjsa.pdf file within JSR-89
Business Motivation Model (BMM)

WS-I organization has developed a basic profile (BP) and basic security profile (BSP) to enforce compatibility. WS-I has designed testing tools to help assess whether web services conform to WS-I profile guidelines. Another charter has been established to work on the Reliable Secure Profile.

SOMF offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the "what to do" aspects of a service development scheme. The model enables practitioners to craft a project plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.
Service-Oriented Architecture: Concepts, Technology, and Design

UDDI: Universal Description Discovery and Integration
ebXML: Electronic Business using eXtensible Markup Language
MDR: Metadata Registry

One can implement SOA using any service-based technology such as JINI, CORBA or REST.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License