SOALIB

Service-oriented architecture library (SOALIB) is used to distribute reusable service-oriented architecture (SOA) software^[1][2] 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 ^[3] 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.

Multi-vendor database

The scope of the library is limited if it does not have support for databases. Composite and integration services should be built to take advantage of loosely coupled atomic services which operate on databases. Once the support for database access is added, a metadata layer should be added to map the various kinds of data format in the database into a uniform set of data types which will have equal meaning to all databases. This is the difficult part, but at this time, JDBC,^[4] ODBC, ADO and other standards database drivers already do part of the task. Each database may store data in different formats. Some data may be encrypted, some may be stored in little endian Endianness, or others in big endian, and so on. Therefore, data must be transformed at some point by the services and they have to be done at runtime due to the changing nature of data. All databases are different, therefore, no single API can take advantage of all the features of all databases. Therefore, services should use database specific features as well.

Steps

• Full support for all major databases - mobile, PC, and server-based.
• Creation of a metadata layer for uniform data access.
• All database access through the service libraries.
• Automatic runtime data transformation.
• Support internal database specific features.

Data synchronization

Once multi-vendor databases are supported, services can be added so that each database may synchronize with any other database. This will now become possible as all data is now passed through a data layer and data is represented in some intermediate form. The intermediate form may be any native form and does not have to be standards-based. Usually, the native form should be portable, that means, representing it in XML may be the best approach. Because data sizes tend to be large, incremental change detection should also be added.

Steps

• Any-to-any synchronization.
• Change capture engine.
• Uni- and bi-directional data synchronization.
• Custom mapping with referential integrity.
• Heterogeneous synchronization.

Security

All libraries must be secure. If the libraries have SOA implementation as web services, then it should have WS-Security,^[5] WS-Policy^[6] and other WS-type standards compliance. If based on REST or other protocols, then it should follow the respective standards. All libraries must at least support SSL.

Steps

• Support all major standards-based security architectures.
• Secure Socket Layer support.
• Option for encrypted storage on the server.

Interoperability

Interoperability is one of the most important reasons why SOA has been so important. A SOA library must also include the required API that could be used for rapid platform specific development.

Steps

• Support all major programming languages: Java, Java ME, C, C++, C#.NET,^[7] VB.NET.,^[8] PHP^[9]
• Supplied with all needed client APIs.
• All APIs must be tested against the binding SOA services.

Building applications atom by atom

An atomic service is a loosely coupled service which is independent of any assumptions, absolutely predictable and have no other dependencies on services or other atomic services. As an example, a disk file operation may be considered as an atomic service in which the only operations performed by the service are read, write, delete, or append file operations. Because the only information the disk file would need is the full path to the file and possibly some access parameters (like username and password), there would be no other dependencies. If a composite service is designed based on atomic services, it is still loosely coupled, but not an atomic service. Each integrated service can then be built together to make a larger SOA application. By building layer by layer, a large SOA application may be created which will remain loosely coupled.

General guidelines

To keep the integrated services loosely coupled would require all the services to be built on atomic and composite services. As soon as the integrated service uses another service that is somewhat tightly coupled, the entire service application becomes tightly coupled. This is analogous to atomic structures becoming "charged" if there is just one electron missing. For this reason, when using third party services, the designer must ensure that the service remains loosely coupled.

• If the service is reliant on third party services, those services must also be loosely coupled.
• If third part offers atomic services, then composite services may be built by mixing service-oriented architecture libraries as well as third party atomic services.
• If any of the services is deemed to be tightly coupled, which may become necessary when there is an industrial appliance involved (e.g., Robotic Arms, Consumer Appliances, etc.), this should be the final service and no service should be derived from them. If other services are built on tightly coupled services, the derived services are tightly coupled as well. These derived services may be used in specialized applications where tight coupling is required (e.g., in precision machines).

The following is the hierarchy in which all service-oriented applications should be designed.

Hierarchy

Ideally, the following should be the SOA application design approach:

• Integrated Services - based upon composite and atomic services
  • Composite Services - based only upon atomic services
    • Atomic Services - no dependency, this service is the atom

Structures to avoid

In some cases, loose coupling may not be possible due to reliance on hardware, mechanical systems, or specialized instruments. For example, if there is a service built to move a robotic arm, monitor industrial generators, or emergency hospital equipment. Then, tightly coupled services are required. Tightly coupled services should be the top in the hierarchy such that no other service may reuse tightly coupled services, if possible. If there are derived services based on tightly coupled services, then all derived services also become tightly coupled. Such a system, if designed, should be limited to the scope of the purpose of the application.

See also

• Loose coupling
• Web service
• Atomic operation

References

External links

• Web Services Specification Up-to-date information about Web Services Specifications
• Representational State Transfer Architectural Styles and the Design of Network-based Software Architectures, PhD Dessertation, Dr. Roy Thomas Fielding