What Software do web modernize ?
Why modernize ?
What are the modernization choices ?
What languages can we modernize ?
Time and cost
Modernization via platformmigration
SOA enablement
Partial Software modernization Web enablement
Data storge mingration
Automatice documentatic
Change impact analysis
End-user computing  
What is SOA?

Service Oriented Architecture is a way of using software modules that exist somewhere else on a network and that are explicitly made available in the form of “services” for use by others.

What SOA is not…

The term Service Oriented Architecture (SOA) is a little bit misleading because SOA is not an “architecture” per se. It is only a particular style of defining and structuring software functionality in terms of services.

Why SOA?

The reason that we want someone else to do the work for us is usually one or both of the following:

  1. They are experts and can do a better job than if we were to do it ourselves.
  2. They are available and already know the job. So instead of us learning to do the job and doing it ourselves, it is easier, faster and cheaper to employ the other person to do it for us.

The same reasons justify the use of SOA:

  1. The “services” already know how to perform a business function that we want to execute.
  2. The “services” already exist and are available. So instead of us learning how to code the business function and doing it ourselves, it is easier, faster and cheaper to simply employ the “service”.
Definition and General Characteristics of SOA

The OASIS2 Group defines SOA as follows:

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

If you cut through all the technical definitions of SOA, it all boils down the following characteristics:

  • It is a form of application integration, software integration, module integration – call it by whatever name, it is about integration! It is software modules provided for integration as “services”.
  • Business functionality is made available to the world over a network in the form of “services” (e.g., invoice printing service) and any external system on that network can utilize those “services” using the proper protocol.
  • The right protocol involves a way of packaging data for exchange (usually XML) and a way of transmitting that package to and fro between the service requestor and the service provider (usually HTTP).
  • “Loose coupling” (i.e., internal knowledge not necessary) is a necessary quality of SOA because how the service is rendered is a blackbox to the requestor of the service. All the requestor needs to know how to request the service and how to get back the results. In this respect, SOA is very similar to the “methods” in object orientation.
  • SOA is another way to re-use software that already exists. From this angle, again, it is an extension of object orientation beyond objects and into services.
  • SOA operates across operating systems and across operating platforms, as long as these platforms are connected via a network. So software running on a Mac computer can utilize a service running on an IBM Mainframe and not even have to know that it is running on an IBM Mainframe.
  • 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.
  • While there are similarities between Object Orientation and SOA, The idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and its processing together.
SOA is Everywhere

SOA is actually everywhere. Let's look at an example of SOA which is likely to be found in your living room: The Compact Disk (CD).

As we have said earlier, the idea of SOA departs significantly from that of object oriented programming, which strongly suggests that you should bind data and it’s processing together. So, in object oriented programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.

But in SOA, you separate the CD from the CD player. If you want to play a CD, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.

SOA is an Architectural Style rather than Architecture itself

We said that before. Now we explain it a little more.SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. So the term SOA is a little bit misleading in this context.

Consuming a service is usually cheaper and more effective than doing the work ourselves. Most of us are smart enough to realize that we are not smart enough to be expert in everything. The same rule applies to building software systems. We call it "separation of concerns", and it is regarded as a principle of software engineering.

The Challenge of Granularity

Granularity means how small or how large do you want to make something?
Take the following business function: “Invoice Printing”. Such a function might typically consist of the following:
  1. Obtain the relevant data from the database.
  2. Compute the Subtotal, Tax and Total Amount Due.
  3. Format the information in the desired manner.
  4. Create a PDF file.
  5. Send the PDF to the designated printer for printing.
We have many choices regarding how to bundle the above as services.
  1. We could bundle ALL of the above as an “Invoice Printing Service”.
  2. We could create two services out of the above:
    • An “invoice creation service” that takes care of Steps 1-3.
    • A “printing service” that takes care of Steps 4-5.
  3. Or, we might even create five different services – one for each step listed above.


  • The smaller (i.e., more granular) we make the services, the greater the opportunity for their re-use.
  • For instance, a generic “printing service” could be utilized by many more programmers than only those looking to print an invoice.
  • Making services more granular also improves separation of concerns. For instance, the service that accesses data from the database can focus only on that task instead of also having to know how to create a PDF and send it to the printer.
  • Smaller services are also promote flexibility of use. The user has greater freedom is combining the mix of services that is just right for his needs.
  • Smaller services make maintenance and governance more difficult. Instead of having to maintain one program, now one has to maintain and govern multiple programs.
  • Smaller services also make testing more difficult.
  • Most importantly, the use of multiple smaller services instead of one large service degrades runtime performance.
  • Smaller services also increase network load, because now many more messages have to exchanged between many more services in order to achieve the same task that might otherwise have been achieved by one service and one message exchange.
Balancing these pros and cons and finding the right granularity is one of the key challenges of SOA and is one of the major success factors.

"Things should be made as simple as possible, but no simpler." - Albert Einstein

Einstein made that famous statement many decades ago, and it's still relevant today for building superior software systems. Unfortunately, as anyone who has been in the IT industry for long can point out, far too many software systems have failed Einstein's test. Some are made too simple to carry out the duties they are supposed to perform. Others are made too complex, and the costs of building and maintaining them have rocketed, not to mention the nearly impossible tasks of integrating different systems together. It seems that reaching the right level of simplicity is more like a dream than reality. The SOA challenge of achieving the right granularity is a reiteration of the same problem.

Architectural Principles of SOA

Now we are in a position to summarize the following specific architectural principles for design and service definition that are generally recognized as the guiding principles for SOA:
  • Service encapsulation: Business functions are encapsulated as services.
  • Service loose coupling: Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
  • Service contract: Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
  • Service abstraction: Beyond descriptions in the service contract, services hide logic from the outside world.
  • Service reusability: Logic is divided into services with the intention of promoting reuse.
  • Service composability: Collections of services can be coordinated and assembled to form composite services.
  • Service autonomy: Services have control over the logic they encapsulate.
  • Service discoverability: Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.
  • Service relevance: Functionality is presented at a granularity recognized by the user as a meaningful service.

The services themselves are usually written in traditional languages like C#, C++, Java, C, COBOL, etc.

Web Services

A Web Service (or Webservice) is SOA on the web. It is one kind of SOA and not the only kind.A Web service is defined by the W3C1 as "a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically Web Services Description Language WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."

Web services are effectively just Internet Application Programming Interfaces: APIs that can be accessed over the Internet, and executed on a remote system hosting the requested services. Other approaches with nearly the same functionality as web services are Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA), Microsoft's Distributed Component Object Model (DCOM) or Sun Microsystems's Java/Remote Method Invocation (RMI).

Web services generally refer to clients and servers that communicate over the Hypertext Transfer Protocol (HTTP) protocol used on the Web. Such services tend to fall into one of two camps: Traditional Web Services and RESTful Web Services.

Traditional Web Services

Traditional Web Services use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks (frameworks such as Spring, Apache Axis2 and Apache CXF being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web service.

RESTful Web Services

More recently, REpresentational State Transfer (RESTful) Web services have been regaining popularity, particularly with Internet companies. By using the PUT, GET and DELETE HTTP methods, alongside POST, these are often better integrated with HTTP and web browsers than SOAP-based services. They do not require XML messages or WSDL service-API definitions.

Exception Handling

A highly dynamic and loosely coupled environment increases not only the probability of deviation situations that occur during the execution of composite services, but also the complexity in exception handling. Due to the distributed nature of SOA and the loosely coupled feature of web services, the monitoring and exception handling issues about web services in the SOA context is still an open research issue.

When running composite web services, each sub service can be considered autonomous. The user has no control over these services. Also the web services themselves are not reliable; the service provider may remove, change or update their services without giving notice to users. The reliability and fault tolerance is not well supported; faults may happen during the execution. Exception handling in the context of web services is still an open research issue.

The Relevance of SOA in Today’s World

The service-orientation ideal has sparked a movement that has positioned SOA as the next phase in the evolution of business automation. In the same manner in which mainframe systems were succeeded by client-server applications, and client-server environments then evolved into distributed solutions based on Web technologies, the contemporary, Web services-driven SOA is succeeding traditional distributed architecture on a global scale.

All major software manufacturers and vendors are promoting support for SOA—some even through direct involvement in the development of open standards. As a result, every major development platform now officially supports the creation of service-oriented solutions.

The Top 5 SOA Adoption Pitfalls

[This section contains excerpts from “Service-Oriented Architecture: Concepts, Technology, and Design” by Thomas Erl (ISBN: 0131858580, Prentice Hall/Pearson PTR, Copyright 2005). For more information, visit www.soabooks.com.]

Although articulated in 2005, the following SOA pitfall observations by Thomas Erl still hold true.

1. Not understanding SOA Performance requirements

Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data processing as well as the associated performance overhead imposed by these layers. When starting out small, it is easy to build service-oriented solutions that function and respond as expected. As the scope increases and more functionality is added, the volume of message-based communication predictably grows. This is when unprepared environments can begin experiencing significant processing latency.

Critical to building a successful service-oriented solution is understanding the performance requirements of your solution and the performance limitations of your infrastructure ahead of time. This means testing (and, if necessary, strengthening) the message processing capabilities of your environments, and paying close attention to service design so as to achieve an acceptable balance between transmission rates, transmission sizes, and other service characteristics that can negatively affect solution performance.

2. Not starting with an XML Foundation Architecture

In the world of today’s SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of today’s SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form the de facto data representation architecture. It is this core set of standards that has fuelled the creation of the many Web services specifications that are now driving SOA.

So much attention is given to how data is transported between services that the manner in which this same data is structured and validated behind service lines is often neglected. This oversight can lead to an improper implementation of a persistent XML data representation layer. This layer is foundational to SOA and its weaknesses will have repercussions across any solutions built upon it.

3. Not creating a Transition Plan

The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an environment’s infrastructure, the affects of a poorly executed migration can be significant.

Transition plans allow you to coordinate a controlled phasing in of service-orientation and SOA characteristics so that the migration can be planned on a technological, architectural, and organizational level.

Typical components of an SOA transition plan include an impact analysis (that predicts the extent of change SOA will impose on existing resources, processes, custom standards, and technology), transition architectures (that map out a series of planned hybrid stages toward a target SOA), and a speculative analysis (that takes into account the future growth of Web services and supporting technologies).

4. Not Standardizing SOA


SOA, like any other architecture, requires the creation and enforcement of internal design standards for its benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighboring applications it may be required to interoperate or share agnostic services with one day. This can lead to many problems, including incompatible data representation, service contracts with irregular interface characteristics and semantics, and the use of non-complementary Web services extensions (or extensions being implemented in different ways). SOA promotes a development environment that abstracts back-end processing so that it can execute and evolve independently within each application. However, standardization is still required to ensure consistency in design and interaction of services that encapsulate this back-end logic.

5. Building SOA like Traditional Distributed Architecture

The number one obstacle organizations have been facing when attempting to achieve SOA is building service-oriented solutions in the same manner in which traditional distributed solutions have been built, under the pretence that SOA is actually being achieved.

SOA is not CORBA + XML, nor is it ASP.NET + WSE. Service-orientation is not object-orientation, nor is it “close enough” so that building object-oriented component logic will always “fit right into” service-oriented solution environments. SOA is a distinct architectural model based on service-orientation, a distinct design paradigm. Understanding these distinctions is critical to building automation logic that is truly service-oriented and in alignment with where the SOA industry is moving on a global scale.

The Service Oriented Architecture Maturity Model (SOAMM)

Early Stage

Companies are at different levels of maturity in the adoption and incorporation of Services Orientation. Some are just beginning to explore the world of SOA using its technology instantiation: Web services. They are wrapping legacy functionality and exposing it for invocation for third-parties, clients, and business partners. This gets them into the game: they ramp up the development team, start the process of changing the corporate culture to better support SOA, and take the first steps in the exploration of new technologies and the business capabilities that may be impacted.

Advanced Stage

The next step of SOA adoption is when the initial testing of Web services has been successfully overcome and now the organization is beginning to integrate systems and applications using services. As proprietary protocols, glue code, and point-to-point connections give way to more open, standards-based protocols and interaction based on service descriptions that each system externalizes, we step into the realm of Service-Oriented Integration (SOI). In this world, the enterprise service bus reigns supreme: a mechanism for mediation, routing, and transformation of service invocations irrespective of the target service provider. It helps overcome many of the shortcomings associated with point-to-point connections.

Web 2.0 vs SOA 2.0

Tim O'Reilly coined the term "Web 2.0" to describe a perceived, quickly-growing set of web-based applications. This directly relates Web 2.0 with Service-Oriented Architecture (SOA) because SOA may be considered as the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus cannot be regarded “parallel philosophies”, whereas others consider the two concepts as complementary and regard Web 2.0 as the Global SOA.

The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, As of 2008 use-cases demonstrated the potential of combining technologies and principles of both Web 2.0 and SOA.

In the vision of an "Internet of Services" covering the globe, all people, machines, and goods will have access via the network infrastructure of tomorrow. The Internet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. Those services will require a complex services infrastructure including service-delivery platforms bringing together demand and supply. Building blocks for the Internet of Services include SOA, Web 2.0 and semantics on the technology side; as well as novel business models, and approaches to systematic and community-based innovation.

Gartner analysts call this Advanced SOA and refer to it as "SOA 2.0".

The Grand Vision

SOA implementations have also been described as representing a piece of the larger vision known as the Digital Nervous System or the Zero Latency Enterprise. Only the future will tell whether this grand vision will ever be realized.

  1. The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web (abbreviated WWW or W3). Founded and headed by Sir Tim Berners-Lee, the consortium is made up of member organizations which maintain full-time staff for the purpose of working together in the development of standards for the World Wide Web. W3C also engages in education and outreach, develops software and serves as an open forum for discussion about the Web.

  2. The Organization for the Advancement of Structured Information Standards (OASIS) is a global consortium that drives the development, convergence and adoption of e-business and web service standards. Members of the consortium decide how and what work is undertaken through an open, democratic process. Technical work is carried out under the following categories: Web Services, e-Commerce, Security, Law & Government, Supply Chain, Computing Management, Application Focus, Document-Centric, XML Processing, Conformance/Interop, and Industry Domains.

USA, Germany, india, UK, Holland, Sweden, France,Belgium, Switzerland, Singapore, China
ADA Companies Worldwide - TSRI
AltiSAP - Quantum Capital
Contact: 888-453-0014
Email: info@adasoftusa.com