email article printer friendly

A New Developer Mind-Set
by Chris Haddad

December 10, 2004

We are in the very early stages of a long but inevitable transition to the pervasive, network-centric platform. Enterprise application architects and developers must adopt a new mind-set, both in terms of how they build applications and the division of development labor necessary to support the needs of the business.

Service-Oriented Architecture (SOA) is a style of application design that creates flexible, adaptable, and distributed computing environments. SOA defines a set of principles, patterns, and practices for designing application functionality as shared, general-purpose services. The best practices enable developers to realize the SOA benefits of maximum service sharing, reuse, flexibility, and interoperability. Service design practices will allow organizations to create a more flexible architecture that can more readily adapt to changing business needs while holding down development costs. There are five main design themes that developers and architects must adopt: sharing and reuse, externalization, loose coupling, interoperable service contracts, and composite applications.

SOA is more about a mind-set than it is about technology. First and foremost, a developer must adopt an attitude that it is better to reuse an existing service than it is to build functionality from scratch. In those situations where no preexisting services are available, the developer should implement the service in such a way that other developers may reuse it in the future. Developers must constantly think about reusability and interoperability.

Building Business Processes
The real distinction between client/server architectures and SOA is in terms of how component interdependencies are factored. In client/server architectures, the focus is on building a specific application and factoring that application into logical components. In most circumstances, the developer fully expects to implement the entire application. In SOA, the focus is on building reusable services and then assembling those services to implement a business process. A given service may be used in any number of applications. In SOA, the developer expects to reuse as many existing services as possible and to implement only as much code as necessary to orchestrate the business process.

Each service should implement a particular business task and operates relatively autonomously. Developers can compose and recompose these services into orchestrated applications that implement a variety of business processes. In combination with the proper infrastructure, SOA can allow IT systems to respond rapidly to changing business conditions. Increasingly, core developers will build business logic and infrastructure services as reusable components, while business developers will act more like building contractors, by assembling (and then remodeling) process-oriented systems using standardized services as building materials.

The notion of general-purpose services that can be reused by multiple applications, rather than recreated for every application instance, is the essence of SOA, but it imposes several challenges. A given service implementation may require different operational semantics in terms of security, reliability, or transactions, for example, depending on the application context in which it's used. In traditional application architectures, developers typically implement these operational semantics within the application code, which reduces, if not eliminates, the reusability of the service.

SOA solves that problem by externalizing operational semantics. Instead of baking security semantics (such as identity and entitlement management) into a service, for example, developers rely on an external, general-purpose security framework that enforces authentication and authorization rules based on declarative policies that specify the required security semantics for a particular service within the context of a specific application. Likewise, instead of building their own transaction semantics into a service, developers rely on a general-purpose transaction framework, again governed by declarative properties.