Enterprise IT infrastructure today consists of what are generally referred to as “silos”, or “stovepipes”. An effective approach to achieving integration and enabling the rapid development of new business offerings is to interpose a “services tier” between client devices and back-end resources. Through this approach, back-end resource functionality is made available via well-defined, network-callable components. These components can make back-end functionality readily available to clients, but unlike the silo approach, provide building blocks for combining simple services into fully featured, value-added services.

The service-oriented architecture (SOA) establishes a standard middle-tier platform across the enterprise that allows for easy discovery and integration of information resources. Services-oriented architecture involves standardizing middle-tier interface technology such that once implemented, a middle-tier component is available for use by other middle-tier components without complex message reformatting and protocol conversions. Such standardization transforms the middle-tier from being a collection of silos and elevates it instead to being an enterprise-wide services tier.

The rationale for choosing the SOA architectural style can be summarized as follows:

• It embodies best practices for the technology to be used
• It satisfies short- and long-term architectural needs
• It reduces risks associated with ambiguous specifications and rediscovery of standard patterns
• It makes divide-and-conquer approach in the evolution of existing systems practical
• It provides the foundation for integration between various enterprise services

The important consequences of adoption of that architectural style are the following:

• It is the interaction of services and assembly of components that creates “applications” and “systems” as opposed to a singular monolithic application.
• Distribution and scalability is built-in and not an afterthought.

Attributes of Service Oriented Architecture
A service-oriented architecture is an architectural style that emphasizes functionality built using standard component-container technologies.
Conceptually, the service-oriented architecture is unified yet it is not monolithic, that is, it is a collection of coarse grained, loosely coupled business services and has the following important characteristics:

• Service-based – Not Just Code-Based: The unit of re-use should emphasize reusable generic service functionality, be readily available, deployed as components across the enterprise and capable of being centrally managed and controlled to achieve the desired quality-of-service (QOS) levels.

• Assembled – Not Built: Using services as building blocks, systems should be formed, to the extent that it is possible, by assembling existing services, not by starting from scratch. Some of the parts may even be provided by resources from outside the corporate boundaries. Assembly should be rapid and efficient, not a costly process of custom integration. This however does not preclude from building the service blocks from beginning if it makes business sense to do so.

• Physically Distributed: It should be possible to distribute processing across multiple physical network devices. This allows spikes in demand to be met using horizontal scaling techniques.

• Quality of Service (QoS) Driven: The services framework must be implemented in a manner which takes into account management, security and other systemic qualities.

• Implemented in Layers: Layering maximizes the independence of processing components from their underlying platform implementations.

Layers provide a way for logical organization of components in the system from the point of view of their technical – rather than business-related – functions.  In a layered organization of a system, the emphasis is placed on the following:

• Reduction of interactions between layers – the typical rule is that a given layer interacts only with its immediate neighbors.
• Reduction of dependencies between layers – a given layer is ideally directly dependent upon a single layer that provides services to it.
• In addition to providing a clean logical decomposition of the system (in addition to components), layering reduces impact of changes or replacement of frameworks used to construct a given layer.
• Functionally isolated: Functionality should be partitioned according to logical function, enabling services to evolve independently of one another in response to ever-changing requirements without impacting other services.

Components and System Decomposition
The main building block of the SOA is a software component or service. Software components are units of composition with contractually specified interfaces and explicit context dependencies. A component has the following attributes:

• It provides services using well-defined interfaces, ports and protocols

It encapsulates state and behavior
It depends only on a component framework or operating system to be started up and to communicate with other components

• It can be constructed, tested, and deployed independently of other components

In general, there are two types of components:

• Functional components – they realize designated business functionality
• Infrastructure components – they do not introduce any business-specific functions but are required for functioning of the system (and are still independently deployable components) or support of enterprise concerns such as auditing or monitoring.

The approach for determining the scope of top-level components is based on the following:

• High cohesion of functions within a given component – as e.g. in case of a security component or a client management component
• External usability of a service – the determination of functional components is to include consideration of systems external to a given application that may use facilities provided by these components in order to execute specific parts of the overall business process.
• Reduction of the overall number of components through abstraction and refactoring – For example, components in an application should consider abstracting small differences between related functions in a number of areas to provide a common customizable service or its reusable implementation. This effort, however, will be limited in practice by delivery timeframes and availability o
  f business specifications from potential clients outside the application project.  Refactoring existing code may be separate from service delivery.

Given that the architecture uses J2EE technology, software components are implemented as Enterprise Java Beans (EJBs) or Servlets. This choice leads to the following view of the overall system:

• The actual implementation and functionality of an EJB or Servlet component is obtained from interaction of a number of instances of Java classes.
• A business service is provided either by a single physical component or a group of interacting components.

The main elements of system decomposition are classified in the following:

• Functional components

Infrastructure and ancillary components

The system will also utilize a number of frameworks (persistence, presentation, workflow, etc…) and even though those frameworks will be important parts of the system they are not components in the sense discussed above.

The rationale for the above form of decomposition is the following:

• Focusing on functional services creates an architecture that can be understood by non-technical people. It facilitates mapping between business processes and technological infrastructure that supports those processes.
•  It provides a natural unit of encapsulation that reduces dependencies and unnecessary interactions with other services or systems: service is the main unit of public reuse (follows functional decoupling)

www.bestitdocuments.com