The Benefits of a Service-Oriented Architecture
A service-oriented architecture has services that developers create in a service layer. The services that they develop have published interfaces. These interfaces support a distinct business domain. Organizations that focus their development effort around the creation of services, will realize many benefits. The most common scenario for development organizations is to have some experience with component-based development. The use of application servers such as J2EE or .NET for hosting applications is becoming more common. If your organization is using component-based development practices and application servers for business logic, then you are already service-oriented. By following the service-oriented mind set with even more rigor, combined with the component-based approach to software development, your organization will realize many benefits.
Focused Developer Roles
A service-oriented architecture will force an application to have multiple layers. Each layer has a set of specific roles for developers. For instance, the service layer needs developers that have experience in data formats, business logic, persistence mechanisms, transaction control, etc. A client developer needs to know technologies such as SWING, JSP or MFC. Each layer requires a complex set of skills. To the extent that developers can specialize, they will excel at their craft in a particular layer of the application. Companies will also benefit by not having to rely on highly experienced generalists for application development. They may use less experienced developers for focused development efforts.
Better Return on Investment
The creation of a robust service layer has the benefit of a better return on the investment made in the creation of the software. Services map to distinct business domains. For example, a company might create an inventory service that has all of the methods necessary to manage the inventory for the company. By putting the logic into a separate layer, the layer can exist well beyond the lifetime of any system it is composed into. For example, if your organization needs to create a credit card authorization service, there are basically two options. Developers will either develop the functionality as part of the application that needs it, or they will develop it as a separate component. If credit card authorization is developed as a separate component and used as a service, then it is likely to outlive the original application.
The creation of a service layer by definition means that developers have created an additional network interface that can be used by multiple applications. When systems were built using monolithic or client-server methods, security was normally handled on the front-end. Companies often did not even implement database security because it is too hard to maintain multiple security lists. Services on the other hand are used by multiple applications, so they have their own security mechanisms. An application will therefore have multi-level authentication at both the client level and at the service level.
Better Testing/Fewer Defects
Services have published interfaces  that can be tested easily by developers by writing unit tests. Developers can use tools such as JUnit for creating test suites. These test suites can be run to validate the service independently from any application that uses the service. It is also a good practice to run the unit tests during an automated build process. There is no reason for a QA tester to test an application if the unit tests did not complete successfully. More and better testing usually means fewer defects and a higher overall level of quality.
Support for Multiple Client Types
As a benefit of a service-oriented architecture, companies may use multiple clients and multiple client types to access a service. A PDA using J2ME may access a service via HTTP, and a SWING client may access the same service via RMI. Since the layers are split into client and service layers, different client types are easier to implement.
Also because of location transparency, multiple servers may have multiple instances of a service running on them. If a network segment or a machine goes down, a dispatcher can redirect requests to another service without the client's knowledge.
The services that developers create will evolve into a catalog of reusable services. Customers will come to understand this catalog as a set of reusable assets that can be combined in ways not conceived by their originators. Everyone will benefit from new applications being developed more quickly as a result of this catalog of reusable services.
Since location transparency is a property of a service-oriented architecture, code mobility becomes a reality. The lookup and dynamic binding to a service means that the client does not care where the service is located. Therefore, an organization has the flexibility to move services to different machines, or to move a service to an external provider.
Software archeology  is the task of locating and correcting defects in code. By focusing on the service layer as the location for your business logic, maintainability increases because developers can more easily locate and correct defects.
Code reuse has been the most talked about form of reuse over the last four decades of software development. Unfortunately, it is hard to achieve due to language and platform incompatibilies. Component or service reuse is much easier to achieve. Run-time service reuse is as easy as finding a service in the directory, and binding to it. The developer does not have to worry about compiler versions, platforms, and other incompatibilities that make code reuse difficult.
Better Parallelism in Development
The benefit of multiple layers means that multiple developers can work on those layers independently. Developers should create interface contracts at the start of a project and be able to create their parts independently of one another.
One of the requirements of a service-oriented architecture is location transparency. To achieve location transparency, applications lookup services in a directory and bind to them dynamically at run-time. This feature promotes scalability since a load-balancer may forward requests to multiple service instances without the knowledge of the service client.