‹cabeçalho›
‹data/hora›
Click to edit Master text styles
Second level
Third level
Fourth level
Fifth level
‹rodapé›
‹nº›
2003 PSS Global Summit
5
Emphasize that the rationale for the architectural decisions is very important.
The history of IT architecture is about making IT more flexible in order to make business more responsive.  In the early days of computing applications were written as monolithic programs that executed every line of code in order.  This gave way to the idea of making applications more flexible by breaking them into callable subroutines and procedure calls.  The idea was then developed to build business objects which could encapsulate discrete business function and execute differently depending on the context.  To this was added the idea of decoupling the connection using asynchronous messaging. 
Where we are today is with the notion of business services and service oriented architectures (SOA).  In many respects SOA is the culmination of all of these styles and concepts of remotes procedures, business objects and messaging in one unified architecture. 
But SOA is not the end game.  SOA is part of a journey into something much more powerful – dynamically reconfigurable architectures which virtualize services and which can truly take us to a world of e-business on demand.
The desire to make IT more flexible is not new.  Indeed, it is as old as the IT industry itself.  Each of these integration techniques has its place and is appropriate for handling certain situations.     SOA blends the best of all these concepts into one new architecture.  But it’s important to recognize that SOA is not the end of the road either,  It’s the next step in the evolution of flexible infrastructures.
The concept of an ESB is not new.  If you have been using products like WebSphere MQ and WebSphere BI Message Broker you have effectively already been implementing an ESB.  These products are designed to decouple applications from one another and to remove a certain amount of the interface logic from the application. 
What is different about the ESB is the degree of interface logic that can be removed from the application.  The ESB enables you to describe the service that you need in much more coarse-grained terms and to dynamically connect to those services.  It unifies the several programming models in one such as message queues, topics, and the idea of a service.  It removes additional logic from the application such as how to co-ordinate a request and reply.
So the question is how do you build an infrastructure that isn’t a convoluted mess? 
Four suggestions:
1) Decouple the interfaces from the business applications so that you don’t have to open the application to change its connection.
2) Reduce the size and complexity of interfaces using standardized middleware
3) Reduce the number of interfaces so that you don’t have so many doing the same thing.
4) Enable re-use of both the business applications and their interfaces.
The ESB allows you to focus on your core business.  It enables you to add new services faster and to change services with minimal impact to existing services.
Instead connect the services together via a higher level of abstraction.  This provides the services listed in the slide.  Important to point out that since the Connectivity Services (aka ESB) provide the list services, the applications (services) don’t have to implement them.
  The SOA reference architecture is a way of looking at the set of services that go into building an SOA.  These capabilities can be implemented on a build-as-you-go basis allowing capabilities and project level solutions to be easily added as new requirements are addressed over time.  Looking at the colors in the graphic, you can see that they’re organized along the same lifecycle we’ve discussed.  On the left in green is model and assemble, in the middle in blue ins deploy, and on the right in darker blue is manage.  The backbone of the reference architecture is the enterprise service bus which facilitates communication between services.  The reference architecture is a great tool for laying out roadmaps for pursuing SOA.
Additional detail:
The SOA Reference Architecture outlines the key capabilities that are required for comprehensive, enterprise wide SOA solutions.  These capabilities can be implemented on a build-as-you-go basis allowing capabilities and project level solutions to be easily added as new requirements are addressed over time.
Tools are an essential component of any comprehensive integration architecture.  The SOA Architecture includes both Development Services which are used to implement custom artifacts that leverage the infrastructure capabilities, and Business Innovation & Optimization Services which are used to monitor and manage the runtime implementations at both the IT and business process levels.
At the core of the SOA Reference Architecture is the Enterprise Service Bus. This delivers all of the inter-connectivity capabilities required to leverage the services implemented across the entire architecture.  Transport services, event services, and mediation services are all provided through the ESB.
The SOA Reference Architecture also contains a set of services that are oriented toward the integration of people, processes, and information:
Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences.
Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes.
Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways.
Many of the services in an SOA are provided through existing applications; others are provided in newly implemented components; and others are provided through external connections to third party systems.
Existing enterprise applications and enterprise data are accessible from the ESB through a set of Access Services that provide the bridging capabilities between legacy applications, pre-packaged applications, enterprise data stores and the ESB.
The SOA Reference Architecture also contains a set of Partner Services that provide the document, protocol, and partner management capabilities required for business processes that involve inter-actions with outside partners and suppliers.
Business Application Services provide runtime services required for new application components to be included in the integrated system.
Underlying all these capabilities of the SOA Reference Architecture is a set of Infrastructure Services which are used to optimize throughput, availability and performance.
IT Services Management Services include capabilities that  relate to scale and performance, for example edge services, clustering services, and virtualization capabilities allow efficient use of computing resources based on load patterns.
The SOA Reference Architecture is a complete and comprehensive architecture that covers all the integration needs of an enterprise. Its services are well integrated and are delivered in a modular way, allowing SOA implementations to start at a small project level. As each additional project is addressed, new functions can be easily added, incrementally enhancing the scope of integration across the enterprise. 
Background:
The IBM SOA Foundation delivers the capabilities you need to adopt SOA through a comprehensive architecture. These capabilities can be implemented on a build-as-you-go basis, and yet, because of the architecture and its service orientation, capabilities and project level solutions can be easily added as new requirements are addressed over time.
The SOA Reference Architecture shows the key capabilities that are required for comprehensive, enterprise wide SOA solutions. 
Development Services are an essential component of any comprehensive integration architecture. The SOA Architecture includes development tools, used to implement custom artifacts that leverage the infrastructure capabilities, and business performance management tools, used to monitor and manage the runtime implementations at both the IT and business process levels. Development tools allow people to efficiently complete specific tasks and create specific output based on their skills, their expertise, and their role within the enterprise. Business Analysts who analyze business process requirements need modeling tools that allow business processes to be charted and simulated. Software Architects need tool perspectives that allow them to model data, functional flows, system interactions, etc. Integration Specialists require capabilities that allow them to configure specific inter-connections in the integration solution. Programmers need tools that allow them to develop new business logic with little concern for the underlying platform. Yet, while it is important for each person to have a specific set of tool functions based on their role in the enterprise, the tooling environment must provide a framework that promotes joint development, asset management and deep collaboration among all these people. A common repository and functions common across all the developer perspectives (e.g. version control functions, project management functions, etc) are provided in the SOA Reference Architecture through a unified development platform. 
The Business Innovation & Optimization Services incorporate monitoring capabilities that aggregate operational and process metrics in order to efficiently manage systems and processes. Managing these systems requires a set of capabilities that span the needs of IT operations professionals and business analysts who manage the business operations of the enterprise. These capabilities are delivered through a set of comprehensive services that collect and present both IT and process-level data, allowing business dashboards, administrative dashboards, and other IT level displays to be used to manage system resources and business processes. Through these displays and services, it is possible for LOB and IT personnel to collaborate to determine, for example, what business process paths may not be performing at maximum efficiency, the impact of system problems on specific processes, or the relationship of system performance to business process performance. This collaboration allows IT personnel and assets to be tied more directly to the business success of the enterprise than they traditionally have been.
One key feature of the SOA Reference Architecture is the linkage between the Development and the Business Innovation & Optimization Services. The ability to deliver runtime data and statistics into the development environment allows analyses to be completed that drive iterative process re-engineering through a continuous business process improvement cycle.
At the core of the SOA Reference Architecture is the Enterprise Service Bus. This architectural construct delivers all the inter-connectivity capabilities required to leverage and use services implemented across the entire architecture. Transport services, event services, and mediation services are all provided through the ESB. Transport services provide the fundamental connection layer; event services allow the system to respond to specific stimuli that are part of a business process; and mediation services allow loose-coupling between interacting services in the system. The ESB is a key factor in enabling the service orientation of the SOA Reference Architecture to be leveraged in implementing service oriented solutions and can be implemented today to meet the quality of service requirements of any integration solution.
The SOA Reference Architecture also contains a set of services that are oriented toward the integration of people, processes, and information. These services control the flow of interactions and data among people and automated application services in ways appropriate to the realization of a business process:
- Interaction Services provide the capabilities required to deliver IT functions and data to end users, meeting the end-user's specific usage preferences.
- Process Services provide the control services required to manage the flow and interactions of multiple services in ways that implement business processes.
- Information Services provide the capabilities required to federate, replicate, and transform data sources that may be implemented in a variety of ways.
Automated application services, implementations of business logic in automated systems, are a critical part of any integration architecture or solution. Many of these services are provided through existing applications; others are provided in newly implemented components; and others are provided through external connections to third party systems. Existing enterprise applications and enterprise data are accessible from the ESB through a set of access services. These Access Services provide the bridging capabilities between legacy applications, pre-packaged applications, enterprise data stores (including relational, hierarchical and nontraditional, unstructured sources such as XML and Text), etc and the ESB. Using a consistent approach, these access services expose the data and functions of the existing enterprise applications, allowing them to be fully re-used and incorporated into functional flows that represent business processes. Existing enterprise applications and data leverage the Business Application and Data Services of their operating environments such as CICS, IMS, DB2, etc. As these applications and data implementations evolve to become more flexible participants in business processes, enhanced capabilities of their underlying operating environments, for example support of emerging standards, can be fully utilized.
The SOA Reference Architecture also contains a set of Business Application Services that provide runtime services required for new application components to be included in the integrated system. These application components provide new business logic required to adapt existing business processes to meet changing competitive and customer demands of the enterprise. Design and implementation of new business logic components for integration enables them to be fully re-useable, allowing them to participate in new and updated business processes over time. The Business Application Services include functions important to the traditional programmer for building maintainable, flexible, and re-useable business logic components.
In many enterprise scenarios, business processes involve inter-actions with outside partners and suppliers. Integrating the systems of the partners and suppliers with those of the enterprise improves efficiency of the overall value chain. Partner Services provide the document, protocol, and partner management services required for efficient implementation of business-to-business processes and inter-actions.
Underlying all these capabilities of the SOA Reference Architecture is a set of Infrastructure Services which provide security, directory, IT system management, and virtualization functions. The security and directory services include functions involving authentication and authorizations required for implementing, for example, single sign-on capabilities across a distributed and heterogeneous system. 
IT Services Management Services include functions that relate to scale and performance, for example edge services and clustering services, and the virtualization capabilities allow efficient use of computing resources based on load patterns, etc. The ability to leverage grids and grid computing are also included in infrastructural services.
While many of the Infrastructure and IT Service Management services perform functions tied directly to hardware or system implementations, others provide functions that interact directly with integration services provided in other elements of the architecture through the ESB. These interactions typically involve services related to security, directory, and I/T operational systems management.
The SOA Reference Architecture is a complete and comprehensive architecture that covers all the integration needs of an enterprise. Its services are well integrated and are delivered in a modular way, allowing SOA implementations to start at a small project level. As each additional project is addressed, new functions can be easily added, incrementally enhancing the scope of integration across the enterprise.  In addition to supporting SOA strategies and solutions, the architecture itself is designed using principles of service orientation and function isolation.