From Seo Wiki - Search Engine Optimization and Programming Languages

Jump to: navigation, search

SOALIB is Service Oriented Architecture Libraries used to distribute SOA [1][2] reusable software just like libraries as used in computing. These are loosely coupled interoperable services which uses both SOAP and REST based messaging and operates under Java Application Server. A Library in computing is a set of compiled modules which are usually tested and ready for reuse. A similar concept could be brought to SOA in which whatever technology is used to develop the service can also be distributed in library form. Typically, a Java based SOA library may be distributed in a WAR or EAR form. In C, C++, .NET applications, may be distributed as shared object (for Unix and Linux), Dynamic Link Library (in Windows) or executable.



Service Oriented Architecture is usually tied to redesign of the entire software system and determine how to decompose the single software unit into loosely coupled components, in which each loosely coupled components act as interoperable services. Such a task is enormous and may take 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. Just as an example, all things are built with atoms, yet all things are so different. At the atomic level, they appear to work in the same way. But at the thing level, which we observe, is significantly different. Similarly, all software can be built on loosely coupled services with similar in concept of the atoms. Because, loose coupling are 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 are loosely coupled services, complex applications could be developed by making use of these services. Because new applications depends on all loosely coupled services, as long as we stick 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 due to the fact that all the hierarchy is based on atomic services.


Building SOA require 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 is built only upon atomic services.


  • 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.
  • Building complex software system by 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 service. Alternatives are building applications with full compliance to ANSI C/C++ so that none of the component of code is reliant upon third party libraries. Typically, this means to build the C/C++ applications using GNU tools and GNU C compilers because, GNU compilers are ported to most operating systems and platforms. Third 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.


  • Full platform independence to the extent possible.
  • Automatic tests on each platforms.

Multi-vendor database

The scope of the library 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 various kind of data format in the database into a uniform set of data types which will have equal meaning to all databases. While this is the difficult part, but at most time, JDBC [4], ODBC, ADO and other standards database drivers already do part of the task. Each database may store data in different format. 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.


  • Full support for all major databases - both 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 database is supported, services can be added so that each database may synchronize with any other databases. This will now become possible as all data is now passed through metadata 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. But usually, the native form should be portable, that means, representing it in XML may be the best approach. Because data size tend to be large, incremental change detection should also be added.


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


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-* standards compliance. If based on REST or other form of protocols, then it should follow the respective standards. All library must at least support SSL.


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


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


  • Support all major programming languages: Java, J2ME, C, C++, C#.NET[7], VB.NET.[8], PHP[9]
  • Supplied with all needed client API.
  • All API 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 is read, write, delete, append, etc 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 guideline

In order to keep the integrated services remain 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 become tightly coupled. This is obvious as we see in atomic structure such that if there is just one electron missing, it becomes charged. For this reason, when using third party services, the designer must ensure that a 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 service 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.


Ideally, the following should be the SOA application design approach

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

Structure to avoid

But, in some cases, loosely coupling may not be possible due to reliance on hardware, mechanical systems, specialized instruments, etc. For example, if there is a service built to move a robotic arm, monitor industrial generators, hospital emergency equipment, etc. 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 that is based on tightly coupled services, then all derived services also become tightly coupled. In such a system, if designed, should be limited to the scope of the purpose of the application.

  • Tightly Coupled Service - reliance on a few tightly coupled services. All derived services are also tightly coupled.
    • Integrated Services

External links

See also


  1. Microsoft Corporation, January 2004. [1] Understanding Service-Oriented Architecture, The Architectural Journal
  2. Sun Microsystems, April 2005. [2] Service-Oriented Architecture (SOA) and Web Services: The Road to Enterprise Application Integration (EAI)
  3. Microsoft Corporation. [3] Common Language Runtime
  4. Sun Microsystems. [4] The Source for Java Developers
  5. Oasis [5] OASIS Web Services Security (WSS) TC
  6. World Wide Web Consortium (W3C) [6] Web Services Policy 1.2 - Framework (WS-Policy)
  7. Microsoft Corporation. [7] Visual C# Features Overview
  8. Microsoft Corporation. [8] Getting Started with Visual Studio
  9. [9] Hypertext Preprocessor

Personal tools

Served in 0.463 secs.