Editing Service-oriented architecture (section)

== Organizational benefits ==
Some [[enterprise architect]]s believe that SOA can help businesses respond more quickly and more cost-effectively to changing market conditions.<ref>Christopher Koch [http://www.cio.com.au/index.php/id;1350140708 A New Blueprint For The Enterprise] {{Webarchive|url=https://web.archive.org/web/20090116015011/http://www.cio.com.au/index.php/id;1350140708 |date=January 16, 2009 }}, ''CIO Magazine'', March 1, 2005</ref> This style of ''architecture'' promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to—and usage of—existing IT (legacy) assets.

With SOA, the idea is that an organization can look at a problem holistically. A business has more overall control. Theoretically there would not be a mass of developers using whatever tool sets might please them. But rather they would be coding to a standard that is set within the business. They can also develop enterprise-wide SOA that encapsulates a business-oriented infrastructure. SOA has also been illustrated as a highway system providing efficiency for car drivers. The point being that if everyone had a car, but there was no highway anywhere, things would be limited and disorganized, in any attempt to get anywhere quickly or efficiently. IBM Vice President of Web Services Michael Liebow says that SOA "builds highways".<ref>Elizabeth Millard (January 2005). "Building a Better Process". ''Computer User''. Page 20.</ref>

In some respects, SOA could be regarded as an architectural evolution rather than as a revolution. It captures many of the [[best practice]]s of previous software architectures. In communications systems, for example, little development of solutions that use truly static bindings to talk to other equipment in the network has taken place. By embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces. Other predecessors of SOA include [[Component-based software engineering]] and Object-Oriented Analysis and Design (OOAD) of remote objects, for instance, in [[CORBA]].

A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of subordinate services.

Reasons for treating the implementation of services as separate projects from larger projects include:
# Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving projects common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates [[agility]]. That is to say, it fosters business innovations and speeds up time-to-market.<ref>Brayan Zimmerli (November 11, 2009) [https://web.archive.org/web/20101105063545/http://www.brayan.com/projects/BenefitsOfSOA/default.htm Business Benefits of SOA], ''University of Applied Science of Northwestern Switzerland, School of Business''</ref>
# Separation promotes the decoupling of services from consuming projects. This encourages good design insofar as the service is designed without knowing who its consumers are.
# Documentation and test artifacts of the service are not embedded within the detail of the larger project. This is important when the service needs to be reused later.

SOA promises to simplify testing indirectly. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. If an organization possesses appropriately defined test data, then a corresponding stub is built that reacts to the test data when a service is being built. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainder of the mesh is test deployments of full services. As each interface is fully documented with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validate that the test service operates according to its documentation, and finds gaps in documentation and test cases of all services within the environment. Managing the data state of [[idempotent]] services is the only complexity.

Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within [[Java Platform, Standard Edition|JSR-89]] exemplifies such a file.<ref>{{Cite web|url=https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=7854-oss_service_activation-1.0-fr-spec-oth-JSpec@CDS-CDS_Developer|title=JSR-000089 OSS Service Activation API Specification 1.0 Final Release|date=July 26, 2011|access-date=May 18, 2024|archive-date=July 26, 2011|archive-url=https://web.archive.org/web/20110726070810/https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_Developer-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=7854-oss_service_activation-1.0-fr-spec-oth-JSpec@CDS-CDS_Developer|url-status=dead}}</ref>