27 July 2010 Leave a comment
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
• Derived from the business
• Design Patterns
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.