Definition of a SOA architecture


In the previous article we introduced the architectural change that requires SOA adoption.
In this article we better define what is meant by “Architecture Software “and what are the questions that
guide the execution of an architecture SOA.
Reading the book “The Rational Unified Process – An Introduction” by Booch and Kruchten (1999).
We read this definition:”Software architecture encompasses the Significant Decisions about:The organization of a software system, the selection of the structural elements and Their interfaces by Which
the System is Composed, together With Their behavior as specified in the collaboration among local Those elements, the composition of these elements into progressively larger subsystems, that the architectural style guides this organization, these elements and their interfaces their collaborations, and their Composition. Software architecture is not only Concerned with structure and behavior but also with usage, functionality, performance, resilience, reuse, comprehensibility, Economic and Technological constraints and tradeoffs, and aesthetics”.
Unlike other software architectures SOA as the main focus implementation of a cross-functional solution throughout the company provides the interaction between those who are the customers’ needs with those services are already in the company.
The questions that an SOA architect must answer are:

• What are the important concepts?
• What are the relationships among them? How do these relationships describe the behavior of the system?
• How do the concepts and relationships provide value higher up? How do they serve the purpose of the overall system rather than the purpose of the individual parts?

So while a typical architecture of the Software should be concerned only definition of classes that make up the objects and their interaction among them, an SOA to worry about the definition of service, key concept, and must find and indicate the way to the way that services interact with each other to create what is required by business.
Before going into the definition of SOA we see indicate what are the most important principles to keep in mind for the proper definition an architecture.

• Separation of concepts
• Architectural Vision
• Ease of changes
• Abstraction
• Consistency
• Derived from the business
• Design Patterns
• Ease
• Communication

The separation of concepts is one of the basic architecture of every six concepts remain separate software components are separated from one another allowing a better decoupling of services and consequently increased flexibly to changes.
The architectural vision is another key element for the definition architecture, this view makes it possible to see the component you design will not end in itself but part of a much broader context linked to the whole business.
The ease of changes architecture allows for an extremely flexible and responsive, one of the characteristics of an SOA is the fact flexibility to change. This flexibility is required to permit adaptation to the demands of SOA in the business.
Abstraction is the key to the architectural separation, division of concepts and implementation of flexible architectures. Typically abstraction provides a high-level design of components, for example by making objects that communicate with the database abstraction sees objects as SQL high-level components with specific functionality for each database that will go to use, eg using interfaces for the definition of components and specializing objects for querying a lesser degree.
Consistency is a key to an SOA, along with the reuse when SOA thinks it should see services developed optical use throughout the business application, viewed in its entirety and not just in architectural piece to be undertaken.
The derivation of business is perhaps the most important point of the birth of SOA, an architecture and in particular, an SOA has as main purpose to serve the business this feature increased in case we are talking about SOA
The design patterns are a series of technical solutions to known problems in our case we speak of SOA Design Patterns, which differ by Design Patterns defined by classical GoF patterns, because specifically tailored to definition of an SOA.
Ease requires that the architecture is easy to develop and implement, without requiring too much effort needed for its achievement, a architecture too complicated to implement because, in addition to increasing development cost becomes difficult to maintain.
Communication is another key component for achieving a good architecture, this project provides for the proper communication between all components that come into play in the architecture, particularly among those involved the architectural design and who takes care of business so as not to have a disconnect if minimal between Business and IT.
On important ones are the major items of Architecture, let’s see now to introduce the important concepts that will be used later in a SOA:

Process: a high-level business function that must be represented in our architecture
Service: software module used to create processes
Integration: connection is established between the application / existing services and other applications / services
Existing systems: are all current systems holding to be migrated or integrated into SOA
Documentation: high level document that represents both processes business, both existing applications and services that you want to achieve
Semantics: of the language in which you “talk” systems that want to integrate or services that need to be developed
Processing changes: that need to undergo the process data and services during communication between heterogeneous systems
Communication: The ability of a communication service to communicate with another

What we have on that are the cardinal points around which to develop a SOA an important thing to keep in mind is that an architectural document should not be too large nor too exorbitant, a document of 1000 pages and architectural well, besides being difficult to read and understand, how does that architecture is born already dead, because once the document because the architecture is already old and business processes have already changed.
The documents that make up an SOA and then must be agile and easy consultation should also be divided into several parts in order to be easily accessed by people you work without the risk of losing time looking for what is within its competence.

Advertisements

The Second Rule Change “Architecture”


An architecture defines the functionality to be implemented meet the specific needs of business users.

Typically, an architecture is designed to meet the specific needs of who makes the request to the IT industry, this approach can lead to duplication functionality within the same architecture, such as a registry of

customers.

The role of architecture change radically with the introduction of a Service-oriented architecture, SOA precisely, which makes use of SOA architectures is to align IT to business demands by pushing the parties to definition of architecture not only to think about functionality but in fact develop an entire business enterprise in order to identify functionality required in the company and to extend them to use in their

architecture.

The change of this view is defined by certain characteristics that SOA introduces to drive change, an architecture for SOA must be:

  • Service Based
  • Standards Based
  • Enterprise Focus
  • Business Focus
  • Introducing the “Reference Architecture”

Let us now explain how this would help reduce the distance between IT and Business

Service Based

A service-based architecture, allows sharing between different applications,as already developed, this is

because the identification of a service and future use are written into the WSDL, Web Service Definition

Language,which presents all the methods exposed by the service and how to use these methods In this way, before developing a new service can detect whether another area already offers a similar service to use that service without develop a new one.

Obvious even to do that you can combine multiple services to get what that the business functions require.

Standard Based

The SOA is based on precise standards, particularly on a standard now widely used XML. Virtually all popular programming languages provide support for XML, so you can achieve the solution without having the required need for personnel with specific skills.

Focus Enterprise

Development and implementation of a SOA provides the vision of the changes are not occurs only at the business unit level but at a higher level. Unlike traditional SOA technologies requires the involvement of all stak-holder and support of the company to be applied. The technical group will go from being localized to an area of business particular, to be centralized in this way the technical choices are not more driven by line of business making the request but are guided entire business. This is reflected in the design of a service is having in mind what is the whole business.

Business Focus

 

In many architectures the execution of a request requires the Business dozens of applications, each specialized in a specific area of belonging.

There are applications ERP, CRM, and perhaps all have a customized database customer often contains information simply organized differently.

Implementing SOA requires a sharing of what are the common components, such as a registry, thus avoiding duplication components.

The Reference Architecture

The “Reference Architecture” is a descriptive document based SOA.The purpose this document is to provide a comprehensive document of all architecture which will then form the SOA.

The reference architecture is designed to break those applications are those legacy applications that are business presentation.

In this document it is good to introduce what will be at the heart of SOA hardware and software level.

Here ends the description of the second level of change, our next discuss your appointment of the Reference Architecture, particularly explain how I designed my way to do that is as common good and possible.

Business Strategy & Proces


IT plays a vital role in achieving the needs of Business unfortunately very often not seen as a partner but rather as a slowdown of what are the processes of achieving these needs.
The gap created between the IT and the business is due to several factors, example the fact that IT and business needs often travel with different “speed”.
This difference in “speed” is due to several factors the first is all the technological factor.
In a software that could be called “traditional” for every need of business is made a specific request then that IT will develop what is required by business, this course often means arriving late on the real needs of  Business and maybe from a technical standpoint duplicate information perhaps already in the company.

Business and IT also often travel with different time horizons, For example, a business decision is viewed in a perspective of development long-term company, aimed at achieving specific business objectives.

IT but in most cases see the project end in same and that is simply in response to a request from the Business delegating to future actions the development of new requests Business.

This creates a gap between those who are the real needs of Business, which perhaps may have changed materially during the implementation software and what IT issues.
Closing this gap is what we strive to achieve SOA this optimization is done by implementing some best practices necessary to achieve all the specific objectives the SOA.
These best practices are feasible mainly due to a change culture within the company, the implementation of what we can define a “SOA Program”, defined by Oracle, provides a change radical corporate culture.
The change is being driven by “SOA Program” in a different number of ways:

  • Promoting information sharing, and changing the view of the problem, no longer looking for a solution to the level Business, but promoting a solution to the enterprise level
  • By the way that each of the six domains of SOA has the needed emphasis in all the years of the development of SOA
  • Defining a type of architecture, dynamic, responding you quickly change, and that is based on standards
  • By measuring the actual costs of development, and identify here business processes can be divided into multiple processes, thus allowing software reuse by eliminating duplication of logical services and reducing therefore the cost of realization of SOA
  • Establishing priorities for services to be developed
  • Establish rules necessary for the proper release SOA
  • Defining the right measures are applied in order to understand exactly the cost benefits arising from the SOA, and providing continuous feedback during the time of completion  SOA

Than on that one senses that SOA is more than a simple Architecture but just a strategy that provides the interaction between Business and IT.
This close interaction leads to a redefinition of what are current business processes to enable the proper alignment between IT and the business itself, this phase of the definition of an SOA occurs in three stages which are repeated cyclically:

  • Analysis and identification of existing business processes and identification of required functionality
  • Extract the features required by those who are the current IT processes across the enterprise, and those who must plan realize
  • Orchestrate services into processes developed easily measures to provide and analyze business opportunities optimize existing processes

The operations described are repeated cyclically throughout the life-cycle of SOA, which allows you to refine more and more business services increasingly eliminating the gap between IT and Business.
In future articles we will talk about the other domains will also introduced all the technologies necessary to the implementation of SOA.

Introduction to SOA


SOA (Service-Oriented Architecture) is an IT strategy, which aims to organize the discrete functions contained in enterprise architecture, in services interoperable, standards-based, which can be combined to facilitate reuse and to answer you quickly change business.
SOA is therefore, despite the name, a strategy more than a simple architecture, this implies a radical change in thinking about IT.
Oracle’s definition of SOA identifies six areas of interest to be considered for implementing an SOA.
The six areas are:

• Business Strategy & Process
• Architecture
• Building Blocks
• Project & Applications
• Organization & Governance
• Costs & Benefits

Each of these six areas covering a business environment allowing precise alignment of the entire company to the required change of SOA.
The interaction of the six areas of interest, or as domains are defined by Oracle, can cover all business areas that must interact together to drive change.
Let’s identify what are the different areas to cover and that they aim:

Business & Stategy Process: The goal of this domain is to support the Business and all the changes they need

Architecture: the goal is to drive all IT projects with the business, respect for values and business integration processes must be considered necessary to change and not as an obstacle

Building Blocks: This is probably one of the fundamental domains, the goal of this domain is to promote consistency and availability of services, thus avoiding non-repeatable processes developed.

Project & applications: the goal of this domain is to create a register of all applications and present projects to reuse as much as possible existing projects to avoid duplication of functionality

Organization & Governance: The objective of this domain is to create documents and necessary to manage IT projects, the task of this domain is to standardize all the IT processes necessary changes and you meet with the business.

Cost & Benefits: The goal of this domain is to identify all the costs of various IT projects, including identifying the benefits that the adoption of SOA will lead the entire IT industry.

Here concludes our brief introduction to SOA in the next articles will deepen the six domains and their practical implications in the development of a SOA.