Service-oriented architecture library (SOALIB) is used to distribute reusable service-oriented architecture (SOA) software in a manner similar to other computing libraries. SOA consists of loosely coupled interoperable services which use messaging based on both Simple Object Access Protocol (SOAP) and Representational State Transfer (REST). A library in computing is a set of compiled modules which are tested and ready for reuse. A similar concept is used for SOA, in that whatever technology is used to develop the service can also be distributed in library form. A Java-based SOA library may be distributed in Web ARchive (WAR) or Enterprise Archive (EAR) file formats. C, C++, and .NET applications may be distributed as a shared object (in Unix and Linux), a Dynamic Link Library (in Windows), or as an executable file.
History
Service-oriented architecture is usually tied to the redesign of an entire software system and determines how to decompose the single software unit into loosely coupled components, in which each loosely coupled component acts as an interoperable service. Such a task is enormous and may take a significant amount of time, while on the atomic level (where atom is defined as a single loosely coupled service that is self-contained), most services are reusable regardless of the application. As an example, all matter is built with atoms, yet all material things are different. At the atomic level, however, they appear uniform. Similarly, all software can be built on loosely coupled services which serve as the "atoms" of the redesign process. Because loose coupling is difficult to determine, the opposite is not true. That means it is easier to build a complete software system by using available loosely coupled services.
By building service-oriented architecture libraries, each of which is a loosely coupled service, complex applications can be developed by making use of these services. Because new applications depend on all loosely coupled services, as long as one sticks to loose coupling, the final application is also loosely coupled. While it is true that the final application depends on many hierarchical loosely coupled systems, it remains loosely coupled because all the hierarchy is based on atomic services.
Objectives
Building SOA requires the loose coupling of services as a starting point. They are termed as atomic services. The first step is to determine the atomic services. Then build these atomic services for reuse. A large number of such atomic services could be created, upon which composite services will be built. Composite service are services that are built only upon atomic services.
Steps
Identify, build, and test loosely coupled atomic services. Identify, build, and test loosely coupled composite services, where each composite services is made up of atomic services only. Build integrated services, where each of the integrated services are made up of composite and atomic services. Build complex software system via the reuse of atomic, composite, and integrated services. This complex system remains loosely coupled.
Platform independence
Consideration for cross platform is important. Presently, there are many ways to make the services host platform to be platform independent. Examples are building services in Java, where JVM is available for the host in which the server will run as a service. Alternatives are building applications with full compliance to ANSI C/C++ so that none of the components of the code is reliant upon third party libraries. Typically, this means building the C/C++ applications using GNU tools and GNU C compilers because GNU compilers are ported to most operating systems and platforms. Another alternative is to use C# .NET as the language of the web service where the Common Language Runtime is ported to the target operating system and platform. Many other options are available, but the most common approaches to the platform independence has already been mentioned.
Steps
Full platform independence to the extent possible. Automatic tests on each platforms.