SOA Governance the key to the success of an SOA


One of the aspects that I consider fundamental to the success of a SOA architecture and governance. Before explaining why I feel it so important to the success of an SOA, let’s explain what is meant by governance.

What is the Governance

For governance, the suits mean number of actions to be implemented for proper management of an IT service. These correspond to a set of procedures that must be implemented and managed to control the progress of the project and therefore can act in a timely manner for all the adjustments needed to realign with the current development plan. Governance therefore is responsible for managing the “people”, the “policies” and “processes” that must be verified and checked for proper operation of the SOA. One of the aspects essential for the effective management of governance is therefore to create the proper leadership structure that has as its primary goal the control and the establishment of rules and education of all actors involved in the management of services. Before going any further we should define the difference between “processes” and “services”, by reading a manual of ITIL V3, we find these definitions:

process: a coordinated set of activities that combine resources and capabilities to produce a result that produces a value for the customer and stakeholders. A process must have some specific characteristics:

  • Must be measurable
  • May provide specific results
  • May provide value to the customer and stakeholders
  • May respond to specific events (triggers)

service: a way to provide value to the customer without that bring increased risks and costs.

Processes and services are so closely related, both should provide a return value to the customer and both therefore are a vital part of the production process of an SOA. To provide a return value that is measurable and therefore provides a precise, specific figures are important two are the owner and the service process owners. Both these figures are needed for service management and process and consequently are one of the primary figures and necessary for the success of an SOA.Let’s explain what these two figures are concerned, always read the definitions in the documentation ITIL V3 we find these two definitions for both roles:

Process owners:  it is the responsibility of improving the product and ensures that the process meets the requirements of the service. He is responsible for the success of the process.

Service owner:  is responsible for the development and deployment of IT service is also responsible for its continued improvement and for management services under its control.

The “product owner” and the “service owner” can also converge to the same people, but both are necessary for the proper management of governance.Let us now define what is an SOA Governance.

What is SOA Governance

Once it is clear what is generally a “governance” to define what we see now is a SOA governance. SOA Governance is the combination of “people” and “policies” and “processes” with which your organization has the security of having desired the return of the SOA. This includes the normal governance procedures of a traditional IT architecture, IT project that identifies the purpose for each of the technology you plan to use and sets out guidelines to help in the development of SOA. Let us now define the different roles that are involved in SOA Governance.

People

The people involved in the management of SOA Governance are the same involved in the management of a normal IT Governance.New artifacts should be introduced only if they are necessary for the proper management of SOA Governance. If there is a governance and the effort is not what you wanted, maybe you should take action by putting new figures for the management of Governance, such as Senior Business Analyst or Lead Architect.In a word “people” are all those figures, technical and otherwise, that are necessary for the proper effort to return from governance.

Policies

For all policies are guidelines that must be followed by the people involved in the management of Governance.The questions must be answered to set policies for the governance must first understand what you want to get the Governance. If you simply want to create services to publish and make available to other SOA will never succeed because it is not clear what you want to get the SOA.

Processes

SOA governance must necessarily involve all the processes that serve to make the SOA measurable, improve communication and deal with all processes concerning the management of SOA. To do this you need to speak with the entire staff and clarify who will manage the processes and then clarify and establish all the processes that come into play in the management of SOA.

Conclusion

In this article we must introduced the concept of SOA Governance, in the next article we speak about SOA Journey and will introduce the pratice of SOA Governance

Web Service Contract


The success of an SOA is the sharing of services at several levels within the entire company. To do this we must of course that the “consumer” of the service know exactly  how the service should use. This exchange of information requires that the “consumer” and who “exposes” the service speak to each other through a “contract” setting out the functions and procedures to use the service.

Anatomy of a Web Service Contract

A Web Service Contract is essentially a collection of metadata that describe a series of basic aspects of the service that should be used including:

  • The purpose and functionality of each operation
  • The message he needs to do
  • The data model used in the message
  • The set of conditions necessary to carry out the operation
  • Information on how to access the service

A Web Service Contract is organized in a structure that exactly meets “Questions” that must be answered and that is:

  • “what” offers that particular service
  • “how” can I use that particular service
  • “where” I find that particular service

When a potential consumer wants to know our service will analyze what the service is capable of doing and under what conditions, where and how they can access the service. This information is basic to the orchestration of services and consequently vital for the success of SOA. There are formal terms to describe the structure of a Web Service Contract, these are:

  • Abstract Description
  • Concrete Description

The “abstract description” describes the interface of the service regardless of its implementation, while the “concrete description” contains specific details implementation of how and where to access the service. Parts of a Web Service Contract let us now describe some of the parts that make up the Web Service Contract, as we have already said is made up of two distinct sections to the “Abstract description” and “Concrete Description” the first thing we see, therefore, identify the parts that are description contained in the Abstract.

Constitution of the “abstract description”

In this section we find the Port Type (Interface) This is the interface for connect to the service, the Port Type Operations This section contains the points operation that the service can perform. Within the Operations section we find the Message that contains three different types of messages:

  • Input the message sent to the service from the service consumer
  • Output the message sent by the service consumer of the service
  • Fault message sent by the service to the consumer in the event of bankruptcy or error

In this way, the consumer of the service is able to establish all the features offered by the service and then decide if this is the service to use or not.

Constitution of the “Description of Concrete”

The “concrete description” complete the “Description Abstract” by providing the implementation features presented in the “Description Abstract”, this provides details specific on how to call from the Service Consumer. Inside of course find the same subdivision that was present in the “Division Abstract “the difference between the two is that in this section provides service implementations. We find then the Port Type (Interface) Binding, in this section we find the details to reach and use the service, are in the section Operation Binding inside that contains three sections:

• Input Message Binding

• Binding Outpu Message

• Binding Fault Message

The three sections correspond to the physical operations that are described in section “Description Abstract”, these sections are then used to indicate “how” and “where” run operations described in the service. The section where it is represented by the Service that contains within it the Port section, Port section contains the “where” to find the service, this may be a local server or remote, is not important, what matters in this section is to indicate precisely the address where to find the service.

Conclusion

We talked about what the service contract, that is how they serve a consumer to use a service, we will return in the following articles on the subject deepened and presented in more detail the language for the definition of services the WSDL.

Agile Methodologies the “Nirvana” of an SOA


How many of you know the development of an SOA requires lead times ranging from 2 to 5 years, this is because systems need to convert everyone here who maybe are already in use uniformali at the company and under a single structure which is precisely the SOA.

This brings the company to support many high costs that have been be repaid by the same SOA in terms of ROI or the project would fail. To do this you need so that applications that make Our SOA are immediately available in order to have the first economic returns immediately. One of the methodologies that I consider more valuable to achieve this
Agile methodologies are the goal, the choice of using a methodology Agile falls mainly in ways of working that accompany these methodologies.
Two things in particular I find very interesting:

  • The Continuous Integration
  • Test Driven Definition

Only these points are certainly very limiting for the choice of a management methodology over another, but if we go to agile methodologies to analyze lunge find many points that
make, in my opinion, better than a classical technique project management.
In particular, the management of a project “Agile” expects meetings day of no more than 15 minutes in front of the dashboard activities, now that many more may be an unnecessary waste of time reality is revealed in all its importance as soon as a member of the group encounters an unexpected obstacle. Now project managers can say that pure must be the resource raise the issue, which is true even in agile methods, the
difference is that they speak together, this means that the problem can be solved directly by another colleague who has encountered the same problem or similar in other areas
allowing to solve the problem quickly without necessarily need to move a resource from a task to solve the problem.
How many of you have already experienced one of the worst that can happen to a programmer is going to change careers an activity that even if connected to another is still different from what you are doing which necessarily implies a time “Adaptation” to new activities, this is normal in the methodologies Project Management is not allowed in classical Agile methodologies.
So let’s see what it takes to manage an Agile project and what is useful in an SOA.

Characteristics of an Agile project
Let us now describe what and how a project is composed Agilewith particular reference to Scrum.
The roles that characterize the Scrum methodology are 3:

  • Product Owner
  • Scrum Master
  • Teams

There are also 3 artefacts:

  • Product Backlog
  • Sprint Backlog
  • Burn down chart

And finally 4 ceremonies:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Retrospective

I do not want to disclose too much about how an Agile methodology, but I want to step on some points that I consider important for management of an SOA.
One of the highlights is the Daily Scrum, this is a time when the whole team meets to coordinate work and manage the risks pointing out any obstacles during the Daily Scrum, which lasts maximum of 15 minutes are usually 3 questions addressed to each member of the Group:

  • What did you do yesterday?
  • What will you do today?
  • What obstacles you encountered?

This is used to update the Burn Down Chart, ie the graph shows the evolution of the group in terms of Sprint, ie deliveries.
One of the focal points that makes me choose it are the Scrum Sprint In fact, each sprint is releasing a new feature and consequently a brick that goes to build our SOA.
These “bricks” and then allow to begin to use immediately SOA enabling you to have in terms of economic returns short.
These returns are used to increase the ROI of SOA, enabling then the same as “self-financing” thus making it less consideration of the development itself.
Conclusions

The development of an SOA is always a very complex operation, next are flanked by technical problems and project management problems management.
For the success of the project and the success of a SOA is in fact there must be an immediate payback that to increase ROI and justify the choice of Architectural.
One of my favorite methods for this are those Agile and Scrum particular, because this allows me to have returns immediate on what done and what has yet to be done, allowing
then decide what to develop and when to achieve the goals set by the SOA.

Web Service the “block” of a SOA


As we have already said that SOA is not just architecture but also an approach
methodological development.
SOA is a fundamental characteristic of the low cohesion between the services and the strong  expandability of the system, one of the key components for the realization of  this is the Web Service.
A Web Service is a set of communications standards that enable different applications to exchange data and application services.
The ideal scenario is that of large-scale deployment of a service, such example of a registry, making it available to all players that fit in system, thus avoiding any time to re-create the same application part.
Web Services have not been the first distributed architecture, CORBA and just think COM+, unlike the Web services are based on the precise standards that allows the use and portability to any platform hardware / software. The basic architecture of web services, provides the service to be “exposed” on a network, recorded in a registry, UDDI, where you can find all the information communication, exchanges, and finally a “contract” that governs use. A client must use a Web service so it will first observe the “Contract” of communication of the Web Service, this contract is within the WSDL Web Service Definition Language, which describes all the operations supported by Web Service and what parameters it needs to function properly. The exchange of information between the Web Service and the Client is using the SOAP, Simple Object Application Procotoll, this standard means that the client uploads an XML file that contains all the data requested by the client and processed from the server. The XML format is described in the WSDL, here we find another element that is the XML Schema, XML Schema allows the definition of the XML format that will be exchanged between client and server. You can create Web services across different platforms, such as Apache Axis, Apache CXF, or Microsoft WCF, but all will be fully integrated with each them, the characteristics of Web services makes them so fundamental to good success of an SOA. One of the basic steps for the realization and the good is the output of an SOA “Building Blocks” that is the basic set of services that provide the entire heart SOA. Create Web Services to expose the common core services, such as, the business registry, or the billing system, allows you to create the heart of  services that can be accessed and consumed by all applications that part of the SOA thus allowing the success of SOA.

Conclusion

In this article we spoke briefly of the Web Service over the next few articles we focus on management techniques for the management of applications that are part of the SOA, especially it will introduce the methods “Agile”, which I personally think you are best suited to meet the changes that the adoption of  SOA brings in the company.

What is Service


Each business process, as well as any process, is none other than a series of operations that run up to perform some specific operations.

Each business process, as well as any process, is none other than a series of operations that run up to perform some specific operations.

The idea behind the logic of an SOA is to make so that each specific business task is performed by a specific component called service.

A service can be defined as a unit which carries out work optimally configured for ease in access and is in the same issue. The task that performs a service defines operations, an operation intended to provide a specific output value for that operation.

Usually an input and output value is the result of the functionality provided the transaction itself.  A simple addition operation is not a good candidate for creating a service, service it is done to contain more complicated operations to ensure its existence.

The figure below shows the classic life cycle of a service:

Service Lifecicle

Figure 1 Service life-cycle

The life-cycle  represented on refers to the life cycle of a “Synchronous” and ie a service that is a response to any request, such as life-cycle of a service that makes a sum.

A service usually does not make the sum of numbers, but performs transformations of objects performing specific business rules. The idea behind this is that each service may use an object to perform more complex operations, the object is referenced for the properties of without including completely within the service.

But what is the advantage of using the services, the services allow course implement a mechanism of abstraction, so you can put together more services just make all the demands of business. This capability is provided by interfaces, using interfaces fact allows to extend the service by extending the service.

Service Interface

Figure 2 Service Interface

The services themselves do not provide any benefit, the real benefit is when you use the service throughout the corporate structure, the real benefit in fact reuse the service. The interaction of services is done using different architectural patterns, these patterns are called “Service interaction Pattern” and collect the whole family patterns that serve to determine how services interact. The main pattern of this family are:

  • Synchronous Request-Reply
  • Asynchronous Request-Reply
  • Subscription
  • Unsolicited Notification

Let us describe the various types of patterns in more detail.

Synchronous Request-Reply

This is one of the simplest patterns that exist, the pattern is very much like simple to that presented in figure 1

Figure 3 Synchronous request-reply

This is one of the easiest pattern ever, and the service needs of a single interface that is invoked to run the service, and also provides the answer service through the same interface.

Synchronus request Reply Interface

Figure 4 Interface Request-Reply

Asynchronous Request-Reply

This pattern is similar logic as above, except that the other is of type this synchronous is asynchronous. Unlike simple fact of the Request-Reply, this pattern does not wait for the answer the service provider, but will the same service provider to notify the service user the result of the operation once completed.

Figure 5 Asynchronous Request-Reply

The interface of this pattern of interaction provides two call, one by Service users who exposes for receiving the result, one by the service component to call the service method as shown in the figure.

Figure 6 Asynchronous Request-Reply interface

Subscription

The pattern that provides the subscription service user is registered with the service provider for receiving the result of the operation, the result can be only one or a series of values.

Figure 7 Subscription pattern

Once a service is registered for each service is the outcome that will be sent to the service. The interface provides this pattern as the asynchronous pattern of exposure both services are an interface for a subscription and one for reception response by the department.

Figure 8 Subscription Interface

Unsolicited Notification

The pattern Unsolacited Notification allows a service to send a message notification to a service without the need for this to halt processing for the preparation of result, a classic example of this is the junk mail.

Figure 9 Unsolacited Pattern

The interface is very easy this pattern provides a single interface, the delivery service user interface.

Figure 10 Unsolacited Interface

Conclusion

We finished the quick overview of the main patterns of interaction, as shown these patterns are very simple, but combined can provide many features complex for a SOA. In the next article we will see in detail how to implement these patterns in particularly in how interfaces can be exposed and used.

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.

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.