SOAr en v1.0

SOAr v1 http://www.soarframework.
org/
Cook Book.
Definitive guide to understand, design and implement SOAr
1st Issue
Page 1 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

info@gurulab.org, http://www.gurulab.org/
SOAr v1 http://www.soarframework.org/
SOAr v1
(SOA reloaded) A pragmatic approach to Service-Oriented Architecture (SOA) for Enterprise Application Integration (EAI)
Author Csar Obach-Renner March 2007

Copyright 2007 Cesar Obach-Renner Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with the Invariant Section being Prefacio, no Front Cover Texts, and no BackCover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License.

1 Table of Contents
1 2 3 Table of Contents .................................................................................................................................... 4 Foreword.................................................................................................................................................. 6 Preface ..................................................................................................................................................... 7 3.1 3.2 3.3 3.4 3.5 3.6 4 5 About Gurulab .............................................................................................................................. 7 Who has to read this book?........................................................................................................... 8 Website support and contact information..................................................................................... 8 About English Terms .................................................................................................................... 9 watermark ..................................................................................................................................... 9 Acknowledgements....................................................................................................................... 9
Introduction ........................................................................................................................................... 11 What is SOAr?....................................................................................................................................... 18 5.1 SOAr as EAI fourth generation .................................................................................................. 22 5.1.1 First generation: Point-to-point integration................................................................ 22
Figure 7 EAI First Generation: Point-to-point................................ 22

5.1.2 Second generation: Broker Integration ....................................................................... 23 5.1.3 Third generation: SOA ................................................................................................. 24 5.1.4 Fourth generation: SOAr ............................................................................................. 26 SOAr Benefits............................................................................................................................. 29 SOAr and BPM........................................................................................................................... 31 Key Elements for a SOAr successful implementation ............................................................... 32 BSI Quality ................................................................................................................................. 33 6.1.1 Sifting Phenomenon...................................................................................................... 34 6.1.2 Criteria to generate a good quality BSI....................................................................... 36 Functional inheritance ................................................................................................................ 37 6.2.1 Addition of orthogonal functionalities ......................................................................... 38 6.2.2 Addition on non-orthogonal functionalities................................................................. 38 Industry standard specifications ................................................................................................. 38 6.3.1 Telecommunications ..................................................................................................... 39 6.3.1.1 eTOM ............................................................................................................. 40 6.3.1.2 TAM ............................................................................................................... 41 6.3.1.3 SID.................................................................................................................. 42 6.3.1.4 MTOSI............................................................................................................ 43 6.3.1.5 OSS/J .............................................................................................................. 44 Other industries........................................................................................................................... 47 Level 1 ........................................................................................................................................ 50 Level 2 ........................................................................................................................................ 52 Ideal implementation .................................................................................................................. 53 Enterprise Nerve System ............................................................................................................ 55 Implementation strategy ............................................................................................................. 56 8.2.1 Example of Iterations ................................................................................................... 56 Pragmatic approach..................................................................................................................... 60 Service model.............................................................................................................................. 63 Hiring of professional services for application integration........................................................ 64 Methodology............................................................................................................................... 64 8.6.1 Premises........................................................................................................................ 64 8.6.2 Some definitions............................................................................................................ 65 8.6.2.1 Interchanges vs. Services vs. Interaction ....................................................... 65 8.6.3 Macro Process.............................................................................................................. 67 8.6.3.1 Documentation for requesting........................................................................ 68 8.6.3.2 Analysis .......................................................................................................... 68
1.2 5.3 5.4 6 6.1 6.2 6.3
Business Services Interface (BSI) ......................................................................................................... 33
6.4 7 7.1 7.2 7.3 8 8.1 8.2 8.3 8.4 8.5 8.6
Integration Platform Anatomy............................................................................................................... 49
How is SOAr implemented? ................................................................................................................. 55
8.6.3.2.1
Integration Scope Criteria............................................ 69
8.6.3.3 Architecture.................................................................................................... 69 8.6.3.4 Design............................................................................................................. 69

8.6.4 9
8.6.3.5 Construction and Testing ............................................................................... 70 8.6.3.6 Proceeding to Production ............................................................................... 70 Free Software Tools ..................................................................................................... 71
GNU Free Documentation License ....................................................................................................... 73

2 Foreword

3 Preface
After being in the process of conceptualization, basic and detailed engineering of Service-Oriented Integration Architecture for three years, I have summarized an approach to enterprise application integration (EAI) on the basis of the implementation of a Service-Oriented Architecture (SOA). Throughout this document, the reader will have the opportunity to understand the distinguishing value of this approach to SOA which I call it SOA redefined (SOAr), in respect to any other application integration approach. You will learn the reasons that will justify, not only from the technical but also from the economic and business point of view, the implementation of this approach, and, additionally, you will have at hand a proven methodology that will help you run a project regardless of how large or ambitious it may be. At the end of 2005, after SOAr creation phase and the construction of the architecture fundamental elements, the time came to put it into practice in the first project with real scope, deadlines, and budget. To face such a project, an important search for methodologies was carried out in order to establish SOA through the main international consultancy and IT integration companies. It was concluded that there was no methodology or the necessary experience at hand to implement a service-oriented architecture. In view of this situation, I created a methodology that was used during the analysis, design, and construction phases of the integration required by the project, which has been documented in this book. Such methodology is part of the SOAr integration framework (http://www.soarframework.org/), and as it is one of its components, it is called SOAr Methodology. This framework is constantly improved thanks to Gurulabs contribution and its user's community, who share their experience and improvement opportunities. Adding to conceptualization and methodology, SOAr framework has tools that help implement an integration project based on SOA.
3.1 About Gurulab

Gurulab is a technology innovation laboratory coordinated by Cesar Obach-Renner whose purpose is the development of information and communication technologies or innovative uses related to them, leveraged by the imagination and knowledge of its members. Apart from the innovations of the last 10 years, Gurulab has accomplished a good experience in the execution of technological deeds for several of its customers.

The laboratory operates throughout the world and its members have several meetings during the year where they present their projects. The laboratory strategic plan consists of building an operation base that allows developing, with a base budget, initiative research, development and training of technical specialists in the fields of Architecture, Technology and Innovation. The vehicle used by Gurulab to deliver its innovations is the GNU project licenses (http://www.gnu.org/), GPL for software, and FDL for practices and documents like SOAr. Among its initiatives, apart from SOAr framework, there is free ESB software for SOA and SOAr implementation called Mula, and a fast application development framework called Jasolina. In addition to its development and research processes, Gurulab provides education and consultancy services to ensure the adequate implementation of the technologies it masters.
3.2 Who has to read this book?

This book is aimed at those who are seeking a pragmatic implementation of SOA, who are striving to achieve a stable system platform that will enhance their business value. Although this book is aimed at System Managers and Information Technology Architects, it provides an introduction to SOAr. The reader is not required to have previous knowledge beyond Enterprise Application Integration (EAI) practice. This means that every system and/or information technology professional will perfectly understand the concepts and approach laid out here. The purpose is to explain clearly the concept of SOAr, its benefits, and how to monitor the technological platform to be implemented. Another important purpose is to provide initial guidance on how to perform an implementation project using this practice. Due to its introductory nature, this document can serve as reference material for anyone willing to improve his knowledge as regards SOA and Enterprise Application Integration.
3.3 Website support and contact information

This release is the official document of SOAr concept belonging to SOAr Framework. Both are available under free document license GNU (http://www.gnu.org/).

The official SOAr Framework URL is http://www.soarframework.org/, where you can find a clear description of its price and each of its components. SOAr Framework is a group of resources available to the Information Technology community that help achieve SOAr successful implementations. Particularly, SOAr Framework components are as follows: SOAr Cookbook Business Services Interface (BSI) Courses and Workshops Successful Cases Experienced Members Integration Platforms (ESBs)
3.4 About English Terms

The Spanish version of this document uses the acronyms for the English terms in a standard way. This is so because concept references are kept in their source language so as not to create a translation that may lead to misinterpretation to the reader. Probably, as these concepts begin to be adapted in Spanish speaking communities, their translations will be better known and then it will be purposeful to revise this document to include those factual translations.
3.5 watermark
Minor Earth Mayor Sky @AHa Thought That It Was You @AHa She's Madonna @Robbie Williams The 80's @Robbie Williams
3.6 Acknowledgements
I dedicate this book to my wife Alejandra, who not only supported me unconditionally in all of my projects, but she gave me enthusiasm and support while the project was being developed; without her, I wouldn't have finished it thanks Ale for all your support! I want to thank to all the people that have supported the project of developing this book and especially to the following people that have spent time helping me improve its quality in different ways; but particularly to my friend Argenis Gomez who provided me with the infrastructure to start this project and to whom I owe the name of this
project; to those collaborating in the project Cesar Olivar, Jorlette Martinez, Santiago Ventura, Rossana Diaz and Danny Rodrguez; to Ana Isabel Rodrguez for her revision; thanks Antonio Plutino, Phillipe Lalande Christophe Ebro and the rest of the OSS/J partners; thanks to all of those who contribute to test the concept using Free Software and Proprietary Software platforms; and thanks to all readers that during this year have been patiently waiting the publication of this book. Thank you so much to all of you!

4 Introduction
World widely speaking, all companies are facing a challenge which has been intensified in the past years regardless the area or industry; that is, the reduction of costs while improving its flexibility and speed to modernize its offer in the market. The reduction of costs has always been a classic element for the enhancement of the companies value since they are first created. However, how is it possible that the companys innovation capabilities are improved at the same time? The answer found by analysts and big consultancy agencies lays in the enhancement of processes along all the companys levels and in the use of extremely flexible and powerful, but simple, technology. Through the improvement of business key processes they have found a substantial answer as regards the improvement of their clients value. As a response to that need, Gurulab has developed a referential model that defines the New Generation Information Technology Platform (NGITP); Gurulabs goal is to create an ideal platform that provides all the necessary characteristics in order to make technology be at the service of business through its processes, and not to adapt business to the limitations of the platform. To understand how close the companies are to this ideal, the NGITP referential model comes with a mature model that describes 5 stages or levels out of which level 5 represents the ideal according to NGITP, and level 1 is the most basic level that represents the worst state a company may go through. Traditionally, company processes are programmed (or as technicians say wired) in the enterprise applications that automate their processes and that use them to operate. When several applications are used, processes synchronization occurs manually in a more basic way. This latter example is what the NGITP mature model calls level 1 (see figure 1).
1 There are companies, that in order to enhance their exit flows, have a purely economic criterion reducing costs and investment in all their units including Technology instead of having a Systemic criterion on their processes enhancement, which accompanied by a bigger investment in the technology area, would allow extremely interesting results in the global operation cost of the entire company.

In that NGITP level 1 we can see a group of "n" applications (App 1, App 2, ..., App n), which give life to "j" processes (p 1, p 2, ..., p j). Each of these interacting with their users through n man machine interfaces (GUI App 1, GUI App 2, ..., GUI App n). These interfaces are at this level through a unique access channel Web (c1).
Maturity Level
Figure 1 Level 1 of the NGITP maturity model
Generally, a dilemma arises about whether a company has to "adapt" to the processes that a new application demands, or whether it has to "modify" that application so that it implements the processes that the company is carrying out. Either of both decisions implies a great cost and a marriage with the new chosen "configuration". For example, a german enterprise application manufacturer with head office in Walldorf (Germany) provides applications whose main asset is the solid security that he provides customers with as regards the processes that his applications implement; His customers tend to "adapt" themselves rather than modify themselves But if we imagine a platform whose setting cost is almost non-existent, it would not only be a good decision to adopt the processes that the company wants (regardless of being actual or wanted, or being good or bad, or being in the box or outside of it), but to provide with a great flexibility on the modification of its processes as a response to dynamic and changing markets and scenarios. It would be enough to find an application that has this super configurable capability and we could achieve the purpose. However, we cannot ignore the fact that there is no manufacturer that could provide all the elements of platform TI together with all business requirements - not to mention technical requirements such as security, quality, prices, support, relation, etc. By just developing some of the points mentioned as regards security, the fact that a company has only one TI element supplier suggests an important risk that can be suppressed by the inclusion of several suppliers. As regards cost, the market can
undoubtedly offer more than one supplier who offers a solution with the same features which turns him into the alternative supplier with a better price, thus resulting on a better business offer. However, this implies a problem. Having applications from different manufacturers, and still assuming that all of them can be super configurable, will make the processes coexist in isolation unless they are synchronized through the integration between those applications or by "something from a higher level; an extra application that can control the processes. In the case of synchronization", without a higher element that controls the processes, applications would lose flexibility since synchronization would establish a restriction to the processes it would synchronize. Therefore, "synchronization should be managed independently; in this scenario, super-configurable applications lose their flexibility. Nowadays, most of the companies that have a mature integration practice are in this stage. This integration practice, regardless of having "super-configurable applications or not, corresponds to level 2 of the NGITP maturity model (see Figure 2).

Maturity Level
The only valid answer to our approach is the scenario in which the process is controlled by "something" of a higher level. This scenario implies that applications do not control processes but serve as tasks or functionalities to that superior entity that controls the processes. We will call it "Process Manager". We are arriving at the conclusion that is clear for many Enterprise Architects and application manufacturers throughout the world, who converge in the necessity for disconnecting process management from transaction activities that represent applications under this new approach. Walldorfs House also agrees on that and not only does he put on sale tools for process choreography, but he also generate evolution paths on his applications in order to take his processes out of their boxes towards a process choreographer. But, what is the state of our solution? So far, we have drawn a platform that consists of a heterogeneous collection of applications that present tasks or functionalities that are orchestrated by a process manager. As it can be seen, now what is superconfigurable is not a characteristic to be found in the applications, but in the architecture established between the Process Manager and the applications. To achieve that super-configurable characteristic, it is enough to provide the Process Manager with three (3) fundamental elements:

1)
A function disconnecting mechanism that the modeling processes wants to execute, out of the applications that will actually be responsible for executing.
Therefore, the business rule development based on processes is independent from the collection of applications stored at any time in the system platform. This gives back to the business the power of its processes, delegating to Technology the task of providing the elements upon which the processes coexist. This is accomplished through service exposition that provides a view of underlying application functionalities and data in a simple canonic format, ideally standard. This is what NGITP maturity model sets out as level 3 (see Figure 3). We call this services Business Service.
Maturity Level
Corporate Services
2)
A Process Manager with a powerful and simple definition interface, which is based on the choreography of exposed corporate services.
Based on corporate services, the process manager allows to model processes and to execute them throughout the technology platform, thus allowing the business to evolve rapidly according to the speed and dynamism of the environment without depending on modifications at the level of systems.

Figure 4 shows level 4 of the NGITP mature model which shows, in contrast with the previous level, that processes coexist in the Process Manager and not in the applications.
Maturity Level
Corporate Services
Please note on this figure that the graphic interface no longer corresponds to application interfaces but to processes. That is, instead of users interacting with application functionalities through interfaces, they will do so in the context of orchestrated processes by the Process Manager and through it. 3) A user interface for process execution that is automatically built starting from the definition of process.
As the final element of the mature model, as figure 5 shows, level 5 incorporates technology that adapts in an automatic way interaction interfaces man-machine to allow users interaction with the processes modeled by the Process Manager.

Maturity Level
Corporate Services
Figure 5 Level 5 of the NGITP maturity model In level 5 figure, it can be seen that there is only one interface logic that is adapted to all processes along each channel. Particularly, the first channel given as an example is the Web channel. This level provides not only the low cost advantage in the interface maintenance to support new channels, but also, at the end of the day, the possibility of changing the processes executed in the company by just changing its definition; the system will be immediately adapted to the new definition. The adaptable interface model is called SmartInterface as a concept added by NGITP.

5 What is SOAr?
SOAr is a way of integrating applications and processes based on Service Oriented Architecture (SOA), whose main objective is to isolate any platform application or business process from the rest of the architecture. SOAr achieves this by simplifying considerably any enterprise integration effort achieving: Disconnection of IT platform from business processes. Disconnection of applications from one another, hiding the existing application group complexity from any new application that may integrate. Controlling by reducing derived risks from application changes of the system platform. Taking advantage to the greatest extent existing technological tools capabilities.
To understand how SOAr works, lets imagine the example of integrating (see Figure X) the company processes (for instance, through a management platform of BPM processes) or a new application to its Information Technology platform (IT).
Processes
New application
IT Platform
Figure 6: Use case: Business process integration or new application with IT platform.
The IT platform from the case of use we are analyzing, regardless of the company it belongs to has a great amount of functionalities which, ideally, would be implemented by a concrete and arranged group of Ideal Applications which we will call Functional Components. (See figure X).

Processes
New application
IT Platform
Functional components have common names in contrast to applications that have proper names. For example, we could say that "GNU/Linux" application (proper name) is an Operation System (common name). Other examples are "Accountancy System, Human resources System, Invoicing Responsible, etc. If a company had one application for each required Functional Component, its IT Platform would look like the previous figure, which shows a simple and arranged group of applications which is integrated with processes or a new application. However, the present of the majority of the companies is that they have more than one application in the same Functional Component (see figure X) Processes New application
IT Platform
Additionally, all those applications generate a great functional redundancy that derives in great maintenance and administration complexities. Besides, the integration nature between the applications that have been traditionally used (pointto-point fundamentally) represents a more complex IT platform similar to the one shown on figure X.

Processes
New application
IT Platform
The chaos reflected by the sheet tries to show the existing chaos due to: Point-to-point integrations Full functional overlapping Partial functional overlapping Systems on substitution process
The next and last sequence sheet shows how all that chaos in the IT platform is hidden and encapsulated by a simple group of Business Services grouped by Functional Components, which are the faade that the IT platform shows to the processes and new applications that are to be integrated. Exposed Business Services simplify the exposed IT Platform since it encapsulates functional overlapping and technical complexities produced by the heterogeneous components of a system environment. In other words, instead of integrating processes and new applications to multiple applications through multiple technologies with multiple considerations as regards under which circumstances what interaction pattern is applied or what pattern is not; they are just integrated to a unique and simple functional component from a unique technology. Processes New application
Functional Components Corporate Services
IT Platform

By doing this, the integration strategy of SOAr applications provides: Simplicity, since it hides the resulting complexity of the redundancy and functional overlapping from the existing applications. For example, instead of having three billing systems, SOAr exposes only one; instead of having two accounting systems, SOAr exposes only one. Stability, since the SOAr exposed applications for every customer, such applications never change. However, internally applications do change: what SOAr does is make it transparent so that customers do not realize what really happens.
O/S Manager
Applications implementing O/S Manager functions.
For example, when installing a new CRM, SOAr exposes the Service Order Manager standard services. Behind the scenes, SOAr orchestrates and resolves the complexity of having five Service Order Managers. When another project is searching for the rationalization of Service Order Management applications, it replaces three out of the existing five by a new one. CRM does not hear of that situation thanks to SOAr. Convenience, since in the context of Gurulab NGITP referential model, SOAr represents a mechanism to achieve the establishment of an Information Technology Platform of level 3 New Generation. Efficiency, since it takes advantage to the greatest extent of the current technological platform features by clearly defining how to use each company platform component, regardless of who is the supplier of each one.

As we are going to see in the next section, SOAr represents the fourth generation of 2 EAI practice and corresponds to specific of SOA with highlighting features that shore it up as a different practice with concrete benefits.
5.1 SOAr as EAI fourth generation

Throughout history, EAI practice has advanced on its maturity going through four generations. Below, we will see each one of these generations, namely: i) ii) iii) iv) Point-to-point Broker SOA SOAr
5.1.1
First generation: Point-to-point integration
EAI Point-to-point model corresponds fundamentally to the direct connection between the applications with one another; as shown on figure 7, each application has as many connections as the rest of the existing applications.
1st Generation
Figure 7 EAI First Generation: Point-to-point The complexity model of the existing connections on this model is
EAI stands for Enterprise Application Integration.

where n is the number of applications to be interconnected. For example, for 30 applications, the combinatory result is 435 connections; for 90 applications, the result is 4005 connections. EAI point-to-point model can be considered to be the very first model that derives from the integration needs. This model has not been planned but grows without control.
5.1.2
Second generation: Broker Integration
A Broker is an element which centralizes all the information that exists between any architecture applications. It also serves as a router between messages that come from a source" application to a target application (See Figure 8).
2nd Generation
Figure 8 EAI Second Generation: Integration Hub/Broker
The Broker helps reduce communication complexity between applications. The number of connections between applications is simplified even when multiple messages pass through them. The broker interprets these messages and it works as a router sending them to the target application. The messages that each of the applications send to the broker, apart from having the information that the broker interprets to know what applications send to them, have the structure and message that the target application is expecting to receive. That is, the message sent by an application to the broker fulfills the established Agreement for the target application.

Then, all applications need to be connected to the Broker. Consequently, on this model, the number of connections is simplified to n, where n is the number of applications to interconnect.
5.1.3
Third generation: SOA
From an Enterprise Architecture perspective, SOA (Service Oriented Architecture) is an Architecture pattern that affects all the different points of view under which any topic or any IT device can be separated; from Gurulab Enterprise Architecture referential model, the pillars affected by SOA are Data, Application, Integration, Access, Infrastructure, Security and System Management.
Many application manufacturers are used to promote in their product a group of web services that display its application functionalities; they believe that they are also providing a "SOA Compatible" application.
This is not wrong though. On the ongoing market, companies have understood that by integrating their applications and by making use of these services displayed by the applications they are implementing a Service Oriented Architecture. Without issuing any value judgment, Gurulab has classified this practice as EAI third generation, better known as SOA integration; a service collection that cooperate with one another. Since the traditional architecture analysis has been based on an application collection model that completely encapsulates all of its functionalities behind its graphic interfaces, SOAs great advantage is to allow and foster the reuse of functionalities already implemented by the existing applications for these where completely exposed through services available for anyone requesting them. For n-layers architecture fans, SOA represents the functionality collection of the layer "business logic" found on any application with that model. In this context, SOA sets out that any application displays all its functionalities through services. In the third generation EAI model, the communication that exists between applications is not based on the routing of messages (as happens with the second generation broker), but on the service consumption that each application displays with its respective Agreement, in a point-to-point way.

3rd Generation
Figure 9 EAI Third Generation: SOA
Figure 9 shows how each application displays a group of Services that are available for any other application that may need them by connecting on execution time and "consuming" it. It transpires that any application can assume service supplier's or customer's role. In this EAI generation integration starts to be dynamic because connections stop being static and customized configurations and services begin to be displayed so as to be reused by any other application at the desired time. This provides a great advantage to the EAI practice since this service reuse represents less effort for a future application integration through which the same amount of service displayed will be used. Originally, this Service Oriented Architecture was implemented using CORBA technology specified and standardized by the OMG4. Although the features provided by this specification for the application integration in the enterprise environment were complete (providing security, transactionality, high availability, etc.), they were complex and expensive indeed. At the end of the 90s, keeping simplicity in mind, IBM together with Microsoft developed a service distribution specification to solve the problems that CORBA was facing. Service Web technology was born, which is leveraged by three fundamental elements: SOAP communication protocol, WSDL service Agreement specifications, and the UDDI service dynamic catalogue.
7 5 6 3
3 4
CORBA, stands for 'Common Object Request Broker Architecture'. OMG stands for 'Object Management Group. http://www.omg.org/

The market tendency is that SOA is implemented with Webservices, since SOA is architecture, it can be implemented by using any technology including Webservices: for example, CORBA, EJBs, RMI, SUN RPC, owner/Socket, Webservices (SOAP/HTTP), etc. Generally, the role of IDDI is underestimated. Although it is fundamentally a catalogue that helps any specified service customer discover the service supplier physical location to connect on execution time and consume it, it is the one that disconnects the service from its supplier. As long as customers make use of UDDI whenever it requires service consumption (and not with a physical reference done by the customer), the supplier will be disconnected allowing to change that architecture supplier by just modifying the physical register or that service in UDDI (similar to DNS operation). It is important to highlight that in SOA, customers of any service must fulfill the agreement imposed by the service supplier application because if it changes affecting the Agreement; then the customer has to be modified to fulfill the new agreement. The following question transpires: What would be the advantage of having a standard agreement specification that remains unalterable regardless of changing supplier applications?
8
5.1.4
Fourth generation: SOAr
SOAr is SOA's evolution in terms of redefining the implementation way. It fills the empty spaces that SOA leaves unsolved. These are: i) Evolution of the suppliers specification agreement without affecting customers: SOA ideal state is having an agreement standard specification with an application environment that fulfills that standard specification. By doing this, when the supplier is changed, customers will not be affected.
SOAP (Simple Object Access Protocol): standard protocol that defines the way that objects in different processes can communicate through an XML
6
WSDL data interchange (stands for Web Services Description Language): XML format used for describing Web services. UDDI (stands for Universal Description, Discovery, and Integration): it is a line Directory that is used by applications to discover dynamically other line services. DNS (stands for Domain Name System): it provides an alphanumeric labeling taxonomy that allows associating with an Internet service without the need of using the physical address.
8 7

ii)
Functional Duplicates: When service is provided by two different applications, which are differentiated by particular criteria such as customer type (a type of customer processed by A supplier and another customer type processed by B supplier), service quality, customers or equipments geographical location, etc. Cohesion: Nowadays, when company's dynamism requires a continuous change on their applications in order to evolve towards an ideal platform, any change will have its repercussions on all integrated applications.
iii)
SOAr becomes an alternative to an architecture that does not give any answers to the current enterprise situation. SOAr is an architecture where a group of intermediate suppliers are displayed. These are called Business Services. Business Services represent in the technology platform the ideal map of applications, which are simple and easy to use, hiding complexities of a redundant reality (as they are changing and dissimilar duplicities (due to the sufficient differences between the implementations of the same concepts through different systems/suppliers). SOAr adds to the architecture an additional Business Service layer that can represent Virtual Applications on the ideal company architecture. For many specialists, the services displayed by the platform correspond to compound services. However, on those approximations, compound services are set out as atomic service complements supplied by the applications. SOAr, on the contrary, uses current integration platform capacities in order to create compound services that will generate not only atomic but compound services fulfilling Business Service role. SOAr architecture main elements: 1) Applications: Group of software programs written and designed to perform specific operations that will be integration platform customers or suppliers. It is important to highlight that a same application can be customer in some cases and supplier in some others.
Such functional duplicates are not necessarily a consequence o an immature platform; business conditions can imply that those functional duplicates represent a state of the art technological solution.

2)
Business Service Interface (BSI10): It defines syntax and semantics of each of the Architecture corporate services. Ideally, they are standard. However, even when they are not, they provide the distinctive SOAr characteristic about SOA. Integration Platform: It is a platform supported by high availability, transactionality and security mechanisms. It provides powerful functionalities of a high level of connectivity, adaptation (mapping) and choreography to display defined services for Business Service Interface making up supplier applications.
3)
4th Generation
Figure 10. Forth generation of EAI: SOAr When looking at figure 10, it is possible to locate in the center corporate services displayed by the platform which are consumed by applications. In addition, applications display service suppliers that are used by the platform to display corporate services.
BSI (stands for Corporate Service Interface): It is a corporate service agreement or specification.
10

5.2
SOAr Benefits
SOAR model implementation in the corporate integration practice provides the company and especially the Technology unit with a great variety of benefits that are inherent in its architectural design and therefore are not achieved through any other way. Detailed advantages of introducing SOAr Model are listed below. However, generally speaking, everything is done dynamically by service provisions oriented to new developments that let technology organization respond to business dynamic demand. 1. It disconnects business processes of the information technology platform. Thus, both the processes and the platform evolve independently. This allows business to develop its processes more independently from IT units. In turn, IT units develop their platforms with a lower impact in business processes. It displays, in a simple way, all data and business logic found throughout all technology infrastructures. SOAr does this by displaying corporate services with the following characteristics. a. Known specifications, with no need of learning specific semantics and syntax from existing or coming soon applications. No complexity due to overlapping or functional duplicates. In other words, SOAr displays a platform where there aren't two applications doing the same task. The heterogeneous complexity typical of enterprise environments is hidden by SOAr. In other words, all data and services can be accessed through the same technology.
2.
b.
c.
3.
It substantially reduces risk costs, time and money spent on new application integration. This is done by SOArs simple display of the platform to new applications. It clears overlapping efforts to achieve the same result by having available in a simple way the existing logic and data in the technological platform. It clears application change impacts from other applications. Being the applications encapsulated, when one is changed, there is no need to alter any of the customer applications that belong to this one.
4.
5.

6.
It simplifies application migration processes by parts". Migration from the use of an old application to a new one is controlled by the platform. Consequently, gradual turn to production processes can be transparently taken to remaining platforms depending on whether they were substituted or were substituting. It provides the company with the modeled infrastructure like Level 3 of Gurulab NGITP mature model. In the context of Gurulab NGITP referential model, SOAr represents a mechanism to achieve the establishment of an Information Technology Platform of level 3 New Generation.
7.
Maturity Level
Corporate Services
Figure 11. SOAr in NGITP 8. It efficiently maximizes the technological integration platform use at a corporate level because it provides a Technological Model that clearly shows how to use each component. It controls the architecture technological evolution that is seldom found in Technology units. The integration platform can control all the turn to production processes by aligning itself with ITIL practices11.
9.
11
ITIL (stands for IT Infrastructure Library): It is an operational reference model for IT services.

5.3 SOAr and BPM

As previously explained, SOAr disconnects information technology platform business processes. This is done by displaying a group of corporate services that are available not only for modeling tools and process analysis, but for execution engine.
IT Platform .
Not only does SOAr protect application integration when one of them is changed, but it protects application change processes.
IT Platform .
Since processes consume corporate services, and these ones dont change if SOAr doesnt encapsulate applications, no application change on the IT platform will affect the process execution implemented on BPM layer.

5.4 Key Elements for a SOAr successful implementation

Taking as a premise SOAr concept to successfully implement a service oriented integration platform (EAI based upon SOA), it is necessary to bear in mind four (4) important elements: 1. 2. 3. 4. Good Business Service Interface (BSI) Flexible Platform Pragmatic Methodology of Implementation Integration Equipment
In the following chapters, we will deal in detail with each of these topics in order to provide the reader with enough criteria so he can acquire these components and ensure a successful project. The books approach to each of these elements is structural, separated from the standard, technological or suppliers approach. At www.soarframework.org you can find this document as well as texts based on experience with technologies, standards and specific suppliers. Therefore, you can have access to both criteria and references so you can make your own decisions as regards the most convenient EAI implementation based on SOA.

6 Business Services Interface (BSI)

The importance of Business Service Interface lies in the fact that the implementation has to be defined with enough quality (generality, flexibility, etc) so as to fulfill the promise that a change in the architecture application doesn't impact on any other application or on the business processes supported by SOAr. The better quality the BSI is, the lesser will be the impact on other elements and on other processes when a change of an IT platform element takes place. That is why it is important to know the features to consider when generating an interface of this kind. This chapter presents the criteria that will assure you that the BSI you are using is the best quality one and therefore be sure that your potential Integration Platform based on Service Oriented Architecture will be successful. In addition, we will present the industry standards known by Gurulab that present interfaces that can be used as BSI. If these standards are used, a good quality BSI will be created. The BSI quality is fundamental when assuring the premises you can use on the presentation of the business case that sustains your SOAr implementation process. The better quality the BSI is, the lesser will be the risk for your business share as regards economic losses; impacts will be reduced thanks to the technologic platform evolution.
6.1 BSI Quality

Before clearly defining what we mean by BSI Quality and how we get to it, it is necessary to establish the following concepts first:

Functionality Composition It is said that functionality is Compound when it can be expressed in relation to the execution of other functionalities different to the first one. Functional Derivation It is said that an F Function can be derived when a group of Fi functions are different from F, when Fi is composed by F. Atomic Functionality It is said that functionality F0 is atomic provided there are not other different n functionalities F1, F2,, Fn through which F1 can be derived. Functional Subgroup It is said that functionality F1 is a functional subgroup of functionality F2 provided F2 can be derived from a group of functionalities where F1 is among them. All functionality is a functional subgroup of itself. Orthogonal Functionalities It is said that two functionalities F1 and F2 are orthogonal provided functionality F3 doesnt exist when F3 is an F1 subgroup and F3 is an F2 subgroup. Conclusion Two functionalities are non orthogonal if one of them is a functional subgroup of the other.
BSI Quality BSI quality is directly proportional to its capacity of absorbing, without changes in its API, new non orthogonal functionalities in relation to the existing ones, or new business data characteristics.
6.1.1
Sifting Phenomenon
BSI quality is directly proportional to its absorption capacity, without making any changes to its API, new functionalities that are non-orthogonal in relation to the existing functionalities, or new features on business data. Being a fine grain specification understood as one based on atomic functionalities, and a coarse grain specification as one based on composed functionalities (not atomic), the sieving phenomenon is defined as the situation that arises when a business process or IT

platform application, with the expectation of consuming coarse grain services, is offered a set of business services in a fine grain specification. In order to understand this phenomenon, it is possible to make reference to a different metaphor than that of the business services specifications, for example, the lexicographic complexity of the English (or Spanish) and Japanese languages. To understand an idea in the English (or Spanish) language, it is necessary to use fewer lexicographic constructions (words) than with the Japanese language. This is clearly evident in the great difficulty the movie industry has to synchronize the translations of a Japanese movie into English (or Spanish). The filmmaker Sofia Coppola portrayed this situation with humor in the first scenes of the movie Lost in Translation, when the main character (played by Bill Murray) is in Japan to shoot a Whisky publicity: in the scene, the Japanese director gives the "actor" character a series of instructions during 26 seconds (clock counted) to then listen to the translator give the instructions in English for 2 seconds.
In the figure, the actor listens to the translation attentively while he looks at the director, who is waiting for the translation; after listening to the 2 second-translation, he answers Is that everything? It seemed like he said quite a bit more than that.. Between English and Japanese, there is the sieving phenomenon, where English is of coarse grain type and Japanese, of fine grain type. From this, it is easily inferred that the grain size speaks about the expressivity of its words, and in the case

of the business services specifications, the grain corresponds to the expressivity of its API12.
6.1.2
Criteria to generate a good quality BSI
Aiming to achieve a good quality business services specification, it is important that the specification architect takes into account a series of considerations, which are summarized in the following rules: 1. The BSI should be designed with an ideal reference system in mind. Said reference system may be expressed in terms of formal documents, or according to an expert's vision. The more the BSI architect represents the expert, the better the expression of said vision in the BSI will be. The business services specifications should be of fine grain, even when the processes or applications requiring to consume them, require a coarse grain specification, that is, they should be expressed according to atomic functionalities regardless of the fact that this implies a sieving phenomenon. Use of the exceptions to handle errors Based mainly on the following design patterns: Session Faade Pattern Value Object Pattern, Data Transfer Object Factory Pattern, Data Transfer Object Factory Generic Attribute Access Version Number Iterators for Bulk Transfer (Value List Handler) Templatebased Queries Generic Named Queries Bulk Operation with Best effort and Atomic Semantics MetaData Discovery
2.
3. 4.
The patterns are general references, which may be expressed in terms of specific languages like Java, or may be expressed in agnostic terms like UML. As a reference, below is a list of information sources of design patterns oriented to objects:
http://java.sun.com/developer/technicalArticles/J2EE/patterns/ http://www.research.ibm.com/designpatterns/
The development of a business services specification, including the data specification, is a large job, which should be carried out by stages in width and by iterations to cover depth (details).
12
API stands for Application Program Interface.

To the date, with my team we have had two important and convincing experiences, the first between 1997 and 1999, and the second, between 2003 and 2005; both of them taught us to create business services specifications of a very high quality. The criteria included in this section correspond to the lessons learned along the SOAr execution projects. In the next issues of this book, or in specialized workshops hosted by Gurulab, you will find details of these criteria or practical strategies regarding how to carry them out.
6.2 Functional inheritance

Due to the dynamics of the enterprising applications integration, the business services platform will be affected to comply with the permanent changes and new needs. The BSI may suffer one of these two changes: Addition of orthogonal functionalities. Addition of non-orthogonal functionalities.
It is expected that in an ideal environment the systems and processes consume business services "inherit" the new functionalities of the platform without need to be modified. This prospect is achievable through a high quality BSI in view of modifications to the platform adding new non-orthogonal functionalities. In order for the platform to add that inheritance in view of orthogonal functionalities, the BSI must be defined based on knowledge of future functional prospects, rather than of a specification practice with quality. In other words, in RUNTIME, if you add new non-orthogonal functionalities, and the BSI is of good quality, the processes and systems that consume from the BSI will inherit the new functionalities without need to change the code in the consumers. For example, in a given moment a CRM based on the fact that the Orders Management system does not allow the selection of a specific feature of the product or service to be sold, simply assumes the default feature. If the CRM is integrated to the Orders Management Business Service through a high quality BSI, when the Orders Manager provides the election functionality of the particular feature we make reference to in this example, the CRM would inherit the new functionality and instantly, without need to be modified, it begins to offer the selection option of the specific feature. Below, we will look at each of these two types:

6.2.1
Addition of orthogonal functionalities
In the scenario of addition of new orthogonal functionalities regarding the existing ones in the BSI, the processes and applications that consume from the BSI will be affected as it is required that these take advantage of them. The addition may be implemented through the introduction of new services, or even though the evolution of the existing services into new versions; although the latter case is quite unlikely in the scenario of new orthogonal functionalities, if it occurs and affects services being used, both versions may be exposed simultaneously. The publication of two versions of a same service is a practice that must be carried out carefully. Although it allows, in the circumstances mentioned in this section, to avoid the impact of the BSI evolution in the systems and processes that consume business services, it is a source of redundancy and maintenance complexity. The coexistence of several versions of a same service should be handled through the execution of an appropriate management of the services life cycle. In addition, maintenance policies for the platform should be considered in order to allow excluding old versions of services, creating technological update projects at the level of the consumers of the services to be excluded. It is important to understand that, although in view of the "technological update project mentioned in the previous paragraph there is an impact at the level of the user applications and processes of the business services, such impact does not occur due to changes in the platform, but for maintenance processes that may be implemented on a biannual basis and with no restrictions whatsoever regarding other projects.
6.2.2
Addition on non-orthogonal functionalities
When the BSI is affected by the incorporation of new non-orthogonal functionalities that did not exist in the BSI, the impact will depend on the quality of the BSI. The higher the quality of the BSI is, the fewer the changes in the consumer processes or systems, even enjoying the new functionalities introduced in the platform through the Inheritance SOAr provides them with.
6.3 Industry standard specifications

Below are presented the particular cases for which SOAr has added values. The fact that an industry is not mentioned in this chapter does not imply that it cannot use SOAr, but rather that upon the publication of this paper, Gurulab did not have information on standard devices that facilitate the implementation work.

6.3.1
Telecommunications
TeleManagement Forum (http://www.tmforum.org/) is to the IT Telecommunications industry, what the ITU is to the networks of the same industry, or the ISO to any other industry: it groups a set of standard devices and better practice that allow achieving a technological platform of new generation operations.
The fundamental approach of TMForum is the achievement of a new generation operation platform of a Telco; said approach is in the form of a specifications collection called NGOSS and the specification of standard interfaces, in the Webservices, XML and Java technologies called OSS/J. In the context of SOAr, the great value provided by these specifications is that the Business Services Specification SOAr requires is mainly the implementation of NGOSS (eTOM, SID, TAM, MTOSI, OSS/J) in the technology required by the platform (Webservices, Java, CORBA, etc.). Particularly, OSS/J provides the specifications required for Web Services, a technology widely used currently.

Figure 12. Graphic representation of TMForum NGOSS. Below is a list of the TMForum devices relevant for SOAr.
6.3.1.1
eTOM
eTOM, component of the NGOSS reference framework of TMForum, is a referential framework of processes of a telecommunications enterprise. Such framework classifies all the process with a level of detail almost equivalent to that of the specific tasks specification. It is initially useful as a standard reference at the moment of naming the processes or parts of them (sub processes). For that, it lists a number of processes classified in several dimensions, as shown in Figure 13.

Figure 13. Graphic representation of eTOM; NGOSS component of the TMForum. The eTOM model offers a complete catalog of a telco processing.
6.3.1.2
TAM
The Telecom Operations Map represents a catalog identifying and classifying the Functional Components set of a Telecommunications company. A figure appears below showing the present classification.

6.3.1.3
SID
Apart from being a NGOSS element of the TMForum, SID is a canonical model of data, agnostic of technology, represented in UML models. Figure 14 shows the SID's domains which classify all classes (object-oriented model) representing the standard product.

Figure 14. Graphic representation of SID; NGOSS element of the TMForum. The technical team responsible for this model development is constantly extending such model in order to satisfy domains where a division in the specification has opened up. If a company wishes to use this model, such company may do so by using extension guidelines to make sure that all model architectural considerations are maintained. This model is the best initial reference from which we can work to develop all data for the corporate service specification of SOAr integration architecture. Based on the experience gained as a result of the integration project in CANTV, I firmly recommend that if you are to work with this model and need its extension, you should do so by working very closely with your development team; by doing so, you make sure that the resulting product of your work is turned into the standard product and, thus, you prevent SID from developing in a different direction and leaving you with an out-of-date version.
6.3.1.4
MTOSI
As in the case of eTOM and SID, MTOSI is an agnostic specification of technology that defines interfaces between elements of a telco operating platform. Specifically, MTOSI represents the specification stating that SOAr specifically needs the technology to be used for its implementation.

Since MTOSI is a relatively new device, it does not significantly satisfy the architecture components that need to be specified.
6.3.1.5
OSS/J
Originally, a TMForum independent initiative has developed throughout time a precise implementation of SID and service interfaces (this is what MTOSI intends to achieve) for specific applications such as Trouble Ticket, Inventory, Service Order Manager, Invoicing Responsible, etc. As from July 1st, 2006, such implementation is an official chapter of the TMForum which, apart from being available at the official web site of TMForum (http://www.tmforum.org/), is available at its own URL http://www.ossj.org/.
Presently, specifications in Weservices, XML and Java of the APIs are kept and listed below: JSR #
89 90 91 130 142 144 210 251 254 263 264
OSS/J API
OSS Service Activation OSS Quality of Service OSS Trouble Ticket OSS Billing Mediation OSS Inventory OSS Common OSS Service Quality Management Pricing OSS Discovery Fault Management Order Management
Status
Maintenance Release (v1.1) Final Release (v1.0) Final Release (v1.0) Maintenance Release (v1.1) Final Release (v1.0) Maintenance Release 3 (v1.3) Early Draft Review Early Draft Review Public Draft Review Early Draft Review Public Draft Review
Spec Lead & Company

Andreas Ebbert Nokia Corporation Srinivasa Samudra la Motorola Axel Terfloth IP Value Tulika Pradhan Infozech Software Limited Pierre Gauthier MetaSolv Software Vincent Perrot Sun Microsystems Thierry Supplisson Vallent John Wilmes Ceon Corporation Andrew Paterson Nakina Systems David Raymer Motorola Andreas Ebbert Nokia Corporation
Java.net
public public public
public public public public

JSR #
285
OSS/J API
Performance Management
Status
Expert Group
Spec Lead & Company

David Raymer Motorola
Java.net
Specifications generated by OSS/J are managed through Java Community Process (http://www.jcp.org/), even when Webservices and XML specifications are incorporated. These specifications are equally published through java.net community (http://www.java.net/). In the figure below (Figure 15), a mapping appears with the OSS/J specifications with eTOM.
Figure 15. Visual map showing how OSS/J satisfies eTOM processing domains.
Figure 16 shows the OSS/J specification mapping with the SID model of NGOSS, and Figure 17 shows the dependencies between the main OSS/J entities.

Figure 16. OSS/J specifications mapping with TMForum SID.
Figure 17. Dependencies between OSS/J essential specifications.

For more information about the OSS/J development plan, you may obtain the road map documentation directly at http://www.ossj.org/downloads/docs/wp_ossj_api_roadmap.pdf Apart from including API specifications, the OSS/J specifications include a SID implementation, so the adoption of OSS/J as a business service specification involves the application of better practices for the Telecommunication industry and the use of a high quality BSI, already proved by several operators on a worldwide basis.
6.4 Other industries

On this document publication, there are no records of any frameworks or proposal for interface specification standardizing between applications for other industries, apart from those mentioned in this Section 6 Business Service Specification (BSI). However, as we have assessed the TMForum proposal for the Telecommunication industry to be applied for the Banking industry after making a few changes, we may also assess such proposal to provide solutions for other industries. We foresee that such extrapolation will work properly at least in those domains that are independent from industries such as Accountancy, Human Resources, Invoicing, CRM, etc.


7 Integration Platform Anatomy

An essential SOAr principle indicates that SOAr may be implemented on any technological platform used in a company, whether high-level tools are used as specialized products for integration based on SOA, an ordinary compiler of the language you prefer is used, or an editor of the source code is used. Irrespective of the tool used and your license outline (whether you have proprietary software, open software or free software), an anatomic description of the elements that must be found in the platform you will use for SOAr implementation appears below. It is worth mentioning that this description is open enough to describe any platform, the most important thing is being able to clearly detect which platform component corresponds to which element of this reference technological. Taking into account the technological reference model of SOAr instead of the architectural model for the platform provided by manufacturer, you will have the following benefits: Disconnecting the implementation project of the platform used. In this way, if at any time you come across a reduction in the integration platform, you will be able to easily incorporate new elements completing its reference architecture and achieving the basic objectives of the SOAr implementation described herein. Making sure an independent common language is used for a specific integration technology manufacturer. In this way, you will be able to communicate with any expert, apart from communicating with the technology supplier of your own. Providing the structure to be organized in case a decision is adopted in favor of the implementation of your project using Open Software and Free Software elements and selecting the best implementations which best satisfies the functionalities you need and you most appreciate.
A radiography of the reference architecture appears below indicating the technology to be used in two different detailed levels. The first level shows the smallest element quantity for the platform extension. The level 2 analyzes each element showing more detailed information, making the architecture more understandable from the physical point of view.
Important Explanation

It is worth mentioning that through this entire document the expression 'Adapter' has never been used as a noun (if used as a verb: Adaptation) in order to avoid confusions with the connector suppliers in the market. In general, suppliers highlight its connectors' attributes such as the ability to make Adaptations, thus calling them Adapters instead of Connectors. In this document, we call them Connectors instead of Adapters to stress that on that level NO ADAPTATION MAY OCCUR. I recommend you follow this practice and never refer to Connectors as Adapters, even when the software element is an Adapter. In other words, refer to it using its common name Connector and do not use Adapter as its own name. In this way, you make sure no one will confuse your words and will assume you wish to apply Adaptation functions to the Connector level. Some authors/suppliers put emphasis on this connector usage method, referring to such connectors as Light Connectors, which is a redundancy.
7.1 Level 1
As in the Figure 18, the architecture of the integration platform has two basic elements: i) the platform (showed in the center of the figure), and ii) the applications (satellites to platform).

Figure 18. Level 1: Architecture for the integration technology platform SOAr Applications are Software elements as we know them; however, from such elements, we highlight what we refer to as the Channel. The Channel is the collection of specific application resources that are available for achieving integration objectives. The following are examples of these resources: CICS Transactions Procedures stored in a DBMS A DBMS data schema and instance Plain file Available procedures in book shops Standard RPC Agents (SunRPC according to RFC 1057, DCOM of Microsoft, CORBA, Web Services, etc.), or owners (SAP RFC, SAP BAPIS, etc.) A platform is an agent composed of a macro level made up of three layers: connection layer, adaptation layer and core. The first layer is the Connection layer, where all necessary elements are placed in order to link the applications with the platform. It specifically includes the Connectors and the Proxy. The Connectors are responsible for solving any technologic difficulty while accessing to the application Channel. Connectors show as many Proxys as Channels you wish to integrate in the platform, with Proxys being representations of the application Channels platform.

At this point, due to Connectors, the usage of services represented in the Proxy involves using implicit services in the application channels. In the platform center, we found the Core; in such layer, Business Services are found and formed as a call sequence directed to the Proxys. Such calls put through the Adaptation layer, making all necessary changes so that the objects may be managed on the interface level of the Proxys; this is called mapping. In addition, Specific Services of Application are found in the Adaptation layer. As these are optional, they can provide the adaptation that a Customer application may request to use a Corporate Service. It is also stated that these Specific Services implement logic adaptation. The underlying application abstraction occurs in the Business Services found in the platform core. This is where logic and criteria are implemented and used to expose the services of an ideal application based on the difficult and complex underlying reality. For example, if you really have three different applications to manage Human Resources, only one (1) Human Resources Service is exposed to Business Services (as it were a single application); this is where routing criteria and logic are implemented, so that each call made to the corporate service may be converted into any necessary call for the three underlying applications. Specially, imagine that the three Human Resources applications are managing a different group of Employees, the service communicates with the appropriate application based on the application managed by the employee for whom the Human Resources services shall be rendered.
7.2 Level 2
By observing the figure for level 1 platform, the level 2 is shown in Figure 19. The basic difference between these two levels lies in the sublayers differentiation.

Figure 19. Level 2. Architecture for integration technology platform SOAr In the case of the Connection layer, the two sublayers Connection. Proxies and Connection.Connectors are shown. The Figure 19 shows a physical division that may be found between the layers; in this case, proxys are found in platform ends. Adaptation layer is divided into two sublayers: that layer where adaptations are found, and that layer where the Mapping occurs.
7.3 Ideal implementation

Ideally, a platform implementing this referential architecture would use two concepts considered key to having a more dynamic integration platform: The logic of services, whether they are at the level of adaptations or Business Services, should be a visual tool or metalanguage that brings up the notion of the data morphology. The mappings are defined between the pairs of Objects without a need to make an explicit link in the services logic. The application of the service logic mentioned, when going over the layer Adaptation.mappings, implicitly execute the above mentioned mappings

automatically, thus achieving the agreement compliance whose logic you are addressing to.

8 How is SOAr implemented?

A set of strategic tools appears below and will allow you to plan and execute a SOAr implementation project.
8.1 Enterprise Nerve System

Although you may use the approximation of SOAr to provide 4th generation integration services to concrete solutions, like the implementation of a CRM, it is preferable to look at the SOAr implementation from a corporate perspective. When implementing a corporate" integration platform based on SOAr Business Services, what is being implemented is the so-called Enterprise Nerve System; this platform provides integration services to all the integration initiatives of the company. The projects considered SOAr might have it as a goal at a corporate level, or as an integration platform for a specific business solution. In the first case, the objective at the end of the day is the implementation of the Enterprise Nerve System, which is very appropriate as an Enterprising Architecture practice. In the second case, although the objective is not to implement the Enterprise Nerve System, it may be analyzed in a way that it represents the first step in the corporate implementation plan. In order to achieve this, the consideration should refer to the inclusion of the Practice Proceed-to-Production activities for the organization operating units at the end of the SOAr implementation sub-project for a business solution. Proceed-to-Production activities should incorporate the standard considerations for the enterprise, including a capacity extension (time and resources) of the unit that has performed the first implementation. Consequently, such extension is added to the operating units for a reasonable length of time that may allow one of these two things: Entering into a contractual relationship between the integration services supplier and the operating unit, based on an integration factory. Transfer of technology, so that the operating unit adopts the practice and achieves a complete control of the SOAr enterprising integration practice.

8.2 Implementation strategy

The most appropriate way to carry out the implementation of the SOAr Enterprise Nerve System is through consecutive approximations. Each iteration is based upon the business services provision to projects of Business Solutions. In each iteration, SOAr is assimilating new applications of the technology platform, until reaching a point where all applications are integrated through SOAr. A sequence of steps appears below corresponding to an iteration that shows how an application is to be replaced and is encapsulated to be replaced afterwards using SOAr benefits.
8.2.1
Example of Iterations
Initially, the technology platform is completely integrated through a mechanism that is not SOAr. The figure shows an environment of applications integrated among each other through the first generation of the point-to-point model. Each of the four applications implements a particular Function, which is identified below each application, from Function 1 to Function 4.
Function 1.
Function 2.
Function 3.
Function 4.
Figure 20: Initial Situation

As a first step, the integration services bus is set up (ESB), and the connectors for each of the technologies for the applications related to the iteration are set up as well. Finally, applications in the ESB are connected and the proxies for each of the channels are exposed within the ESB.

Function 1.
Function 2.
Function 3.
Function 4.
Figure 21: Step 1 of the Iteration

The second step consists of exposing the Business Services (BSI) in the services platform, implementing the integration logic, encapsulating the complex reality and exposing simple business services organized by Functional Components.
Function 1.
Function 2.
Function 3.
Function 4.

Then, the third step (3) consists of performing the Encapsulation of the application(s) that are to be replaced; such Encapsulations are based on assuring that any interaction occurring with the application to be encapsulated will be performed through a business services platform and will never be performed directly. In the example, the third application will be replaced, so the other applications
interacting with this application will be modified in order to use the business services that provide the functionalities of the third application.

Function 1.
Function 2.
Function 3.
Function 4.

Note that the same figure showing the third step points out with a red arrow that the requests received by the services of the business exposing the typical function of the application three (third square found on the SOAr platform) are answered" as leveraged on the application three. In the following step (number 4), the new application, that will be the replacing application, is installed and connected to the ESB. In the example, the application number five appears. This application implements the same Function as the application it is going to replace; clearly, the new application will incorporate new functionalities or characteristics, which application three did not have.

Function 1.
Function 2.
Function 3.
Function 4.
Function 3.

In the following step (step 5), the integration platform with each requirement of the business services related to the Function to be replaced sends a copy of the request to the new application, with the aim to generate a parallel.
Function 1.
Function 2.
Function 3.
Function 4.
Function 3.

Once the stage of parallel of the new application may be considered finished, it is possible to configure the Business Service in a way that it only gives answers in connection with the results of the new application, officially entering "In Production".

Function 1.
Function 2.
Function 3.
Function 4.
Function 3.

Once the new application in production has been steady for a reasonable length of time, the application that was replaced may be excluded (see Step 7).
Function 1.
Function 2.
Function 3.
Function 4.
Function 3.
8.3 Pragmatic approach

The dynamics of the business solutions implementation projects tends to be highly pressured and the delivery times, underestimated. As a result of this situation, the technical team in charge of implementing the SOAr platform is faced with the challenge of providing the 4th generation solution in project times as close as the times it would require to implement it point by point.

Although we may think that the times to implement an integration point by point may be compared with the integration through services, in the latter case, there is a required preliminary step (which is not required for the point-to-point integration) that consists of the creation of the business services specifications (BSI), which creates an additional cost in time that may cause the following problems: 1. 2. Traditional integration experts may challenge your EAI proposal based on SOA claiming a higher cost (at least in time) for implementation. The business services implementation may be on the critical path for the business solution projects, thus you would be assuming a significant risk from the project management standpoint; and as a result, from the standpoint of the performance of an actor in your enterprising environment.
Aiming to completely avoid those circumstances, the pragmatic implementation approach is described below and will allow you to achieve the SOAr goals integrating applications in times of a point-to-point integration. As the activity that delays the integration process regarding the point-to-point reference is the BSI generation, the pragmatic approach proposes to remove such activity from the critical path, generating an integration that implements the adaptations for each consumer according to the proxies, and not to the business (core) services. The following figure shows how, from the agnostic anatomy perspective of SOAr supplier, the adaptations internally implement the integration logic directly against the proxies.

Channel
Core (Simple and Composite Corporate Services) Adaptation (Logic and Mapping)
Connection (Connectors and Proxies)
Figure 28: Pragmatic Approach of SOAr implementation. Temporary Status.

The status of the integration solution implementation showed in the previous figure is temporary; while this status begins production, it provides results to its clients. Simultaneously, the BSI is defined and the business services exposed and tested in order to modify the "adaptations" afterwards so that such adaptations may use the business services; then, the internal architecture of the ESB stays as shown in the following figure.

Channel
Core (Simple and Composite Corporate Services) Adaptation (Logic and Mapping)
Connection (Connectors and Proxies)
Figure 29: Pragmatic Approach of SOAr implementation. Final Status.
8.4 Service model

There are two ways for implementing an integration corporate service, the first through an Inflexible model and the second one using a Flexible model. Each way defines the service model that may be adopted by a corporate entity. In the first model, called Inflexible, applications should be adjusted to the canonical Agreements implemented by the Business services found in the integration platform. This implies that the developing team, in charge of introducing the changes to the applications, should modify some modules, or else create new ones, as long as there are differences between the corporate services and those provided by the application. From the integration platform technological model perspective, this inflexible model implies that the applications use the Business Services directly, without need for the platform to expose specific application services.

In the second model, called Flexible, the integration platform not only exposes the corporate services with its canonical Agreement, but also exposes a service tailored to each client application called Adaptation. Thus, the application should not be modified for using the corporate services. The decision for implementing any of the proposed models will depend mainly on the organization culture of the enterprise. An analysis of the differences between both models appears below and will allow you to decide which model is better for your reality and as a result, which model represents the best value option, and above all, the highest probability of success.
8.5 Hiring of professional services for application integration

Applications
8.6 Methodology
This section presents SOAr methodology, which represents the SOAr implementation methodology in detail, created on the basis of the experience within the replacement plan of the Invoicing Responsible, Collector and Credit Agent of CANTV. The detailed documentation of this methodology is presented as a separate publication of it, which apart from including all the requested details to train each of the actors of the plan implementation it includes all the necessary instruments to carry out quality control of each one of the different stages. Even when the experience supporting this methodology lies in Telecommunication control (CANTV Project), approaching is completely absent as far as industry is concerned so that it can be 100% useful as well as valid for other industries such as Banking, Finance Companies, Oil Industry, Manufacture, Pharmaceutical Companies, etc. Nowadays, such methodology supports its version 2, which includes the first-rush learned lessons for the creation of more than 200 business services, in the form of a methodology and instrumental upgrades. A summarized as well as a very high-level version of such methodology is presented below.
8.6.1
Premises
It is compatible with replacement plans as well as with application migration.

It consists of a process, specification devices, decision criteria, processing algorithms and QA.4 validation lists. It considers a pragmatic focus. Aligned with: SAP ASAP Business Blue Print and Gap Analysis Stages. RUP and UP TMForum Based on agreements. Four (4) phases cycle. NGOSS devices (TAM, SID, OSS/J). TMForum Prosperous Program.
8.6.2 8.6.2.1
Some definitions Interchanges vs. Services vs. Interaction
Basically, there are two communication models between applications; we gave the name of Interchanging Model to the first one and Interaction Model to the second one. In an Interchanging Model, applications communicate to each other directly, that is, it does not exist any intermediary between them, so services managed by both must have the same standard or at least they must be outlined in such a way that the application providing the service manages the requests sent by an application that must have the ability to give an answer that can be understood by the application requesting the service. For this model, communication is made up of an interchange between two applications; this communication is represented in the following figure, where A and B are applications that require communication between them.
14
Interchange
Figure 30: Interchange
Interchange: it is the interaction between two systems or the sending of information from one system to another through an intermediary being either on line or batch.
14

The architecture Client Supplier could be considered as an example of interchange communication, since it is an architecture that provides to the final user clear access to the applications, data, calculation services or any other options of the working group and/or, through the organization in numerous platforms. This architecture withstands a distributed environment in which requests of services made by intelligent working stations or clients , are the result made by other computers called servers.
16 15
In the second model called Interaction Model, communication between applications is not performed directly, that is, there is an intermediary, which is the integration platform. So if an application A wants to communicate with an application B, A must request for the service to the integration platform P, so that this platform P administers the request interacting directly with B; subsequently B broadcasts an answer which travels up to P, and this P delivers the answer to application A. The abovementioned plan is illustrated in the figure below.
Figure 31: Interaction

Therefore, you can state that applications communicate among themselves through an interaction mechanism.
14
with an integration platform by using a message delivering
This means that services handled by applications not necessarily must have the same standard, since integration platform could establish different mechanisms in order to adapt messages in such a way that could be understood by the applications which intend to communicate to each other.
15 16 17
Client (C) is a services consumer. Server (S) is a services supplier.
Interaction: It is the action executed between an application and the integration stage, which forms part of an exchange. Every exchange has at least 2 interactions.

8.6.3

Macro Process
Plan Time and resource planning Key people in many places at the same time!
0. Functional definition Processes and functions To-Be. Considered technical requests 1. Request documentation interchanges and cases of use 2. Analysis Specs based on interactions. Define interaction sequence. Define in detail every data to be interchanged as a protocol. 3. Architecture Identify the fulfillment of every interaction spec. Elimination of redundancies within the requesting group. Recycling and extension of existing services (services life cycle). 4. Design Material agreements Change in pieces of information 5. Build up and proof Changes in pieces of information Services logic Connections and adjustments TMForum NGOSS SOAr methodology may be seen as divided into pieces as far as NGOSS methodology of TeleManagement Forum is concerned.

8.6.3.1
Documentation for requesting
During requests placing sessions directed by "processes", the following activities are carried out: Functional equipment presents processes as well as functions called Goal Technical team (including integration group) makes questions and suggestions regarding processes and functions. Processes and functions are confirmed from the technical point of view. Integration team identifies interchanges and cases of use. Sessions end with a list of breaches as well as function changes.
8.6.3.2
Analysis
For every case of use identified in the above-mentioned stage, the group in charge of executing the analysis carries out the following activities:
Revision of validations performed by preliminary mechanisms, setting up the same exchange objective (generally validation rules of existing pointto-point mechanisms) Identify Business Services as well as every application role. Every application role can be identified taking into account the following consideration: In Exchanges which gain access to "Business logic". Client: Transmitter Supplier: Receiver In interchanging pieces of information/ Events Supplier: data/event owner

Validation of Integration range based on integration range criteria (detailed below) Creation of a proposal of interactions optimization opportunities. Every supplier must be on line Consumers may join together on the basis of their preferences (flat file, on line, etc.) Execution of vectorial space transformation for simplification and flexibility. For example, products catalogue. Assessment of the optimization opportunities with the project team as well as application architectures. Decision regarding the optimization opportunities. Documentation of special requests, such as coexistence, conversion, etc. Documentation of data mapping used in the "exchanges.
8.6.3.2.1
Integration Scope Criteria

Integration logic In Business Services Solution for the functional covering of Function Components In adjustments Filtration Phenomenon Validations Syntax > At connectors level Semantics > Through the identification of different components against the BSI Departments > Out of reach Sense > Out of reach Non-standardization Derivation of data from other data without using external resources. Catalogues change Correlation of crossed references between different data coming from different systems representing the same object. Piling up, in order to provide an on line service based on a batch supplier (batch).
8.6.3.3

Architecture
Identification of the execution of every interaction specs. Elimination of redundancies within request batch. Recycling and extension of existing services ( services life cycle)
8.6.3.4
Design

For each service, the following information must be specified:
Namespace and id scheme only. Synchrony: At the same time or at different times Nature: On line o in batches (Batch) API by Mechanism: WS WSDL XSD CICS Tx Commarea TX ID Flat Files XSD Example file RDBMS Connection URL Select Security login/password for validation Transaction or Compensatory Service. Return of the clearly stated status for exchanges at different times. Non-technical information: Quantity (traffic) Frequency Required answering time Protocols for individual tests
8.6.3.5
Construction and Testing
Construction and execution of proof process is specific to the platform and, as it is carried out by using a higher level tool, time will be lower as well as its integration codes test.
8.6.3.6
Proceeding to Production
Once a new service has entered into production, you have to be sure that the followup of the Service Life Cycles Administration is correct: Service Life Cycles Administration Specification Build up Publication Starting of the End of Life End of Life

8.6.4
Free Software Tools
Nowadays any ESB available in the market may be used to make an implementation of SOAr. However, it is very important that you make sure that these tools are handled in the way you have come up, particularly how this document shows you the way this must be set up. The chapter about Integration Platforms Anatomy provides specific information which will allow you to identify each of the elements of your suppliers product, so that you can make sure that the implementation be the correct one to obtain a 4th generation EAI. In order to assure the concept within a free environment, SOAr tested the concept setting up and generating an integration environment SOAr by using the ESB of Mule Free Software (http://mule.codehaus.org) Even though Gurulab.org may provide training workshops for the use of Mule, at present, it is developing ESB integration software based on expectations of the ideal platform suggested in this document. Gurulab ideal ESB project is called Maya. Its code spent many years under production, being an intermediary of text messages proceedings.


9 GNU Free Documentation License

The Free Documentation License is presented below under FSF conditions, which is published at http://www.gnu.org/copyleft/fdl.html We do not present a Spanish version since there is no official version in such language.
GNU Free Documentation License Version 1.2, November 2002 Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

SOArv1 http://www.soarframework.org/
publishedasaprintedbook.WerecommendthisLicenseprincipallyfor workswhosepurposeisinstructionorreference. 1.APPLICABILITYANDDEFINITIONS ThisLicenseappliestoanymanualorotherwork,inanymedium,that containsanoticeplacedbythecopyrightholdersayingitcanbe distributedunderthetermsofthisLicense.Suchanoticegrantsaworld wide,royaltyfreelicense,unlimitedinduration,tousethatworkunder theconditionsstatedherein.The"Document",below,referstoanysuch manualorwork.Anymemberofthepublicisalicensee,andisaddressed as"you".Youacceptthelicenseifyoucopy,modifyordistributethework inawayrequiringpermissionundercopyrightlaw. A"ModifiedVersion"oftheDocumentmeansanyworkcontainingthe Documentoraportionofit,eithercopiedverbatim,orwithmodifications and/ortranslatedintoanotherlanguage. A"SecondarySection"isanamedappendixorafrontmattersectionof theDocumentthatdealsexclusivelywiththerelationshipofthe publishersorauthorsoftheDocumenttotheDocument'soverallsubject (ortorelatedmatters)andcontainsnothingthatcouldfalldirectlywithin thatoverallsubject.(Thus,iftheDocumentisinpartatextbookof mathematics,aSecondarySectionmaynotexplainanymathematics.)The relationshipcouldbeamatterofhistoricalconnectionwiththesubjector withrelatedmatters,oroflegal,commercial,philosophical,ethicalor politicalpositionregardingthem. The"InvariantSections"arecertainSecondarySectionswhosetitlesare designated,asbeingthoseofInvariantSections,inthenoticethatsays thattheDocumentisreleasedunderthisLicense.Ifasectiondoesnotfit theabovedefinitionofSecondarythenitisnotallowedtobedesignated asInvariant.TheDocumentmaycontainzeroInvariantSections.Ifthe DocumentdoesnotidentifyanyInvariantSectionsthentherearenone. The"CoverTexts"arecertainshortpassagesoftextthatarelisted,as FrontCoverTextsorBackCoverTexts,inthenoticethatsaysthatthe
Pgina74/82
Copyright(c)2007CesarObachRenner,Gurulab.org
info@gurulab.org,http://www.gurulab.org/
DocumentisreleasedunderthisLicense.AFrontCoverTextmaybeat most5words,andaBackCoverTextmaybeatmost25words. A"Transparent"copyoftheDocumentmeansamachinereadablecopy, representedinaformatwhosespecificationisavailabletothegeneral public,thatissuitableforrevisingthedocumentstraightforwardlywith generictexteditorsor(forimagescomposedofpixels)genericpaint programsor(fordrawings)somewidelyavailabledrawingeditor,andthat issuitableforinputtotextformattersorforautomatictranslationtoa varietyofformatssuitableforinputtotextformatters.Acopymadeinan otherwiseTransparentfileformatwhosemarkup,orabsenceofmarkup, hasbeenarrangedtothwartordiscouragesubsequentmodificationby readersisnotTransparent.AnimageformatisnotTransparentifusedfor anysubstantialamountoftext.Acopythatisnot"Transparent"iscalled "Opaque". ExamplesofsuitableformatsforTransparentcopiesincludeplainASCII withoutmarkup,Texinfoinputformat,LaTeXinputformat,SGMLor XMLusingapubliclyavailableDTD,andstandardconformingsimple HTML,PostScriptorPDFdesignedforhumanmodification.Examplesof transparentimageformatsincludePNG,XCFandJPG.Opaqueformats includeproprietaryformatsthatcanbereadandeditedonlyby proprietarywordprocessors,SGMLorXMLforwhichtheDTDand/or processingtoolsarenotgenerallyavailable,andthemachinegenerated HTML,PostScriptorPDFproducedbysomewordprocessorsforoutput purposesonly. The"TitlePage"means,foraprintedbook,thetitlepageitself,plussuch followingpagesasareneededtohold,legibly,thematerialthisLicense requirestoappearinthetitlepage.Forworksinformatswhichdonot haveanytitlepageassuch,"TitlePage"meansthetextnearthemost prominentappearanceofthework'stitle,precedingthebeginningofthe bodyofthetext. Asection"EntitledXYZ"meansanamedsubunitoftheDocumentwhose titleeitherispreciselyXYZorcontainsXYZinparenthesesfollowing textthattranslatesXYZinanotherlanguage.(HereXYZstandsfora
Pgina75/82
specificsectionnamementionedbelow,suchas"Acknowledgements", "Dedications","Endorsements",or"History".)To"PreservetheTitle"of suchasectionwhenyoumodifytheDocumentmeansthatitremainsa section"EntitledXYZ"accordingtothisdefinition. TheDocumentmayincludeWarrantyDisclaimersnexttothenotice whichstatesthatthisLicenseappliestotheDocument.TheseWarranty DisclaimersareconsideredtobeincludedbyreferenceinthisLicense,but onlyasregardsdisclaimingwarranties:anyotherimplicationthatthese WarrantyDisclaimersmayhaveisvoidandhasnoeffectonthemeaning ofthisLicense. 2.VERBATIMCOPYING YoumaycopyanddistributetheDocumentinanymedium,either commerciallyornoncommercially,providedthatthisLicense,the copyrightnotices,andthelicensenoticesayingthisLicenseappliestothe Documentarereproducedinallcopies,andthatyouaddnoother conditionswhatsoevertothoseofthisLicense.Youmaynotusetechnical measurestoobstructorcontrolthereadingorfurthercopyingofthe copiesyoumakeordistribute.However,youmayacceptcompensationin exchangeforcopies.Ifyoudistributealargeenoughnumberofcopies youmustalsofollowtheconditionsinsection3. Youmayalsolendcopies,underthesameconditionsstatedabove,and youmaypubliclydisplaycopies. 3.COPYINGINQUANTITY Ifyoupublishprintedcopies(orcopiesinmediathatcommonlyhave printedcovers)oftheDocument,numberingmorethan100,andthe Document'slicensenoticerequiresCoverTexts,youmustenclosethe copiesincoversthatcarry,clearlyandlegibly,alltheseCoverTexts: FrontCoverTextsonthefrontcover,andBackCoverTextsontheback cover.Bothcoversmustalsoclearlyandlegiblyidentifyyouasthe publisherofthesecopies.Thefrontcovermustpresentthefulltitlewith allwordsofthetitleequallyprominentandvisible.Youmayaddother
Pgina76/82
materialonthecoversinaddition.Copyingwithchangeslimitedtothe covers,aslongastheypreservethetitleoftheDocumentandsatisfythese conditions,canbetreatedasverbatimcopyinginotherrespects. Iftherequiredtextsforeithercoveraretoovoluminoustofitlegibly,you shouldputthefirstoneslisted(asmanyasfitreasonably)ontheactual cover,andcontinuetherestontoadjacentpages. IfyoupublishordistributeOpaquecopiesoftheDocumentnumbering morethan100,youmusteitherincludeamachinereadableTransparent copyalongwitheachOpaquecopy,orstateinorwitheachOpaquecopy acomputernetworklocationfromwhichthegeneralnetworkusingpublic hasaccesstodownloadusingpublicstandardnetworkprotocolsa completeTransparentcopyoftheDocument,freeofaddedmaterial.If youusethelatteroption,youmusttakereasonablyprudentsteps,when youbegindistributionofOpaquecopiesinquantity,toensurethatthis Transparentcopywillremainthusaccessibleatthestatedlocationuntilat leastoneyearafterthelasttimeyoudistributeanOpaquecopy(directly orthroughyouragentsorretailers)ofthateditiontothepublic. Itisrequested,butnotrequired,thatyoucontacttheauthorsofthe Documentwellbeforeredistributinganylargenumberofcopies,togive themachancetoprovideyouwithanupdatedversionoftheDocument. 4.MODIFICATIONS YoumaycopyanddistributeaModifiedVersionoftheDocumentunder theconditionsofsections2and3above,providedthatyoureleasethe ModifiedVersionunderpreciselythisLicense,withtheModifiedVersion fillingtheroleoftheDocument,thuslicensingdistributionand modificationoftheModifiedVersiontowhoeverpossessesacopyofit. Inaddition,youmustdothesethingsintheModifiedVersion:
A.UseintheTitlePage(andonthecovers,ifany)atitledistinctfromthatofthe Document,andfromthoseofpreviousversions(whichshould,iftherewereany, belistedintheHistorysectionoftheDocument).Youmayusethesametitleas apreviousversioniftheoriginalpublisherofthatversiongivespermission.
Pgina77/82
B.ListontheTitlePage,asauthors,oneormorepersonsorentitiesresponsible forauthorshipofthemodificationsintheModifiedVersion,togetherwithatleast fiveoftheprincipalauthorsoftheDocument(allofitsprincipalauthors,ifithas fewerthanfive),unlesstheyreleaseyoufromthisrequirement. C.StateontheTitlepagethenameofthepublisheroftheModifiedVersion,as thepublisher. D.PreserveallthecopyrightnoticesoftheDocument. E.Addanappropriatecopyrightnoticeforyourmodificationsadjacenttothe othercopyrightnotices. F.Include,immediatelyafterthecopyrightnotices,alicensenoticegivingthe publicpermissiontousetheModifiedVersionunderthetermsofthisLicense,in theformshownintheAddendumbelow. G.PreserveinthatlicensenoticethefulllistsofInvariantSectionsandrequired CoverTextsgivenintheDocument'slicensenotice. H.IncludeanunalteredcopyofthisLicense. I.PreservethesectionEntitled"History",PreserveitsTitle,andaddtoitanitem statingatleastthetitle,year,newauthors,andpublisheroftheModifiedVersion asgivenontheTitlePage.IfthereisnosectionEntitled"History"inthe Document,createonestatingthetitle,year,authors,andpublisherofthe DocumentasgivenonitsTitlePage,thenaddanitemdescribingtheModified Versionasstatedintheprevioussentence. J.Preservethenetworklocation,ifany,givenintheDocumentforpublicaccess toaTransparentcopyoftheDocument,andlikewisethenetworklocationsgiven intheDocumentforpreviousversionsitwasbasedon.Thesemaybeplacedin the"History"section.Youmayomitanetworklocationforaworkthatwas publishedatleastfouryearsbeforetheDocumentitself,oriftheoriginal publisheroftheversionitreferstogivespermission. K.ForanysectionEntitled"Acknowledgements"or"Dedications",Preservethe Titleofthesection,andpreserveinthesectionallthesubstanceandtoneof eachofthecontributoracknowledgementsand/ordedicationsgiventherein. L.PreservealltheInvariantSectionsoftheDocument,unalteredintheirtext andintheirtitles.Sectionnumbersortheequivalentarenotconsideredpartof thesectiontitles. M.DeleteanysectionEntitled"Endorsements".Suchasectionmaynotbe includedintheModifiedVersion. N.DonotretitleanyexistingsectiontobeEntitled"Endorsements"ortoconflict intitlewithanyInvariantSection. O.PreserveanyWarrantyDisclaimers.
IftheModifiedVersionincludesnewfrontmattersectionsorappendices thatqualifyasSecondarySectionsandcontainnomaterialcopiedfrom theDocument,youmayatyouroptiondesignatesomeorallofthese sectionsasinvariant.Todothis,addtheirtitlestothelistofInvariant
Pgina78/82
SectionsintheModifiedVersion'slicensenotice.Thesetitlesmustbe distinctfromanyothersectiontitles. YoumayaddasectionEntitled"Endorsements",provideditcontains nothingbutendorsementsofyourModifiedVersionbyvariousparties forexample,statementsofpeerrevieworthatthetexthasbeenapproved byanorganizationastheauthoritativedefinitionofastandard. YoumayaddapassageofuptofivewordsasaFrontCoverText,anda passageofupto25wordsasaBackCoverText,totheendofthelistof CoverTextsintheModifiedVersion.OnlyonepassageofFrontCover TextandoneofBackCoverTextmaybeaddedby(orthrough arrangementsmadeby)anyoneentity.IftheDocumentalreadyincludesa covertextforthesamecover,previouslyaddedbyyouorbyarrangement madebythesameentityyouareactingonbehalfof,youmaynotadd another;butyoumayreplacetheoldone,onexplicitpermissionfromthe previouspublisherthataddedtheoldone. Theauthor(s)andpublisher(s)oftheDocumentdonotbythisLicense givepermissiontousetheirnamesforpublicityforortoassertorimply endorsementofanyModifiedVersion. 5.COMBININGDOCUMENTS YoumaycombinetheDocumentwithotherdocumentsreleasedunder thisLicense,underthetermsdefinedinsection4aboveformodified versions,providedthatyouincludeinthecombinationalloftheInvariant Sectionsofalloftheoriginaldocuments,unmodified,andlistthemallas InvariantSectionsofyourcombinedworkinitslicensenotice,andthat youpreservealltheirWarrantyDisclaimers. ThecombinedworkneedonlycontainonecopyofthisLicense,and multipleidenticalInvariantSectionsmaybereplacedwithasinglecopy. IftherearemultipleInvariantSectionswiththesamenamebutdifferent contents,makethetitleofeachsuchsectionuniquebyaddingattheend ofit,inparentheses,thenameoftheoriginalauthororpublisherofthat sectionifknown,orelseauniquenumber.Makethesameadjustmentto
Pgina79/82
thesectiontitlesinthelistofInvariantSectionsinthelicensenoticeof thecombinedwork. Inthecombination,youmustcombineanysectionsEntitled"History"in thevariousoriginaldocuments,formingonesectionEntitled"History"; likewisecombineanysectionsEntitled"Acknowledgements",andany sectionsEntitled"Dedications".YoumustdeleteallsectionsEntitled "Endorsements." 6.COLLECTIONSOFDOCUMENTS YoumaymakeacollectionconsistingoftheDocumentandother documentsreleasedunderthisLicense,andreplacetheindividualcopies ofthisLicenseinthevariousdocumentswithasinglecopythatis includedinthecollection,providedthatyoufollowtherulesofthis Licenseforverbatimcopyingofeachofthedocumentsinallother respects. Youmayextractasingledocumentfromsuchacollection,anddistribute itindividuallyunderthisLicense,providedyouinsertacopyofthis Licenseintotheextracteddocument,andfollowthisLicenseinallother respectsregardingverbatimcopyingofthatdocument. 7.AGGREGATIONWITHINDEPENDENTWORKS AcompilationoftheDocumentoritsderivativeswithotherseparateand independentdocumentsorworks,inoronavolumeofastorageor distributionmedium,iscalledan"aggregate"ifthecopyrightresulting fromthecompilationisnotusedtolimitthelegalrightsofthe compilation'susersbeyondwhattheindividualworkspermit.Whenthe Documentisincludedinanaggregate,thisLicensedoesnotapplytothe otherworksintheaggregatewhicharenotthemselvesderivativeworksof theDocument. IftheCoverTextrequirementofsection3isapplicabletothesecopiesof theDocument,theniftheDocumentislessthanonehalfoftheentire aggregate,theDocument'sCoverTextsmaybeplacedoncoversthat
Pgina80/82
brackettheDocumentwithintheaggregate,ortheelectronicequivalentof coversiftheDocumentisinelectronicform.Otherwisetheymustappear onprintedcoversthatbracketthewholeaggregate. 8.TRANSLATION Translationisconsideredakindofmodification,soyoumaydistribute translationsoftheDocumentunderthetermsofsection4.Replacing InvariantSectionswithtranslationsrequiresspecialpermissionfromtheir copyrightholders,butyoumayincludetranslationsofsomeorall InvariantSectionsinadditiontotheoriginalversionsoftheseInvariant Sections.YoumayincludeatranslationofthisLicense,andallthelicense noticesintheDocument,andanyWarrantyDisclaimers,providedthat youalsoincludetheoriginalEnglishversionofthisLicenseandthe originalversionsofthosenoticesanddisclaimers.Incaseofa disagreementbetweenthetranslationandtheoriginalversionofthis Licenseoranoticeordisclaimer,theoriginalversionwillprevail. IfasectionintheDocumentisEntitled"Acknowledgements", "Dedications",or"History",therequirement(section4)toPreserveits Title(section1)willtypicallyrequirechangingtheactualtitle. 9.TERMINATION Youmaynotcopy,modify,sublicense,ordistributetheDocumentexcept asexpresslyprovidedforunderthisLicense.Anyotherattempttocopy, modify,sublicenseordistributetheDocumentisvoid,andwill automaticallyterminateyourrightsunderthisLicense.However,parties whohavereceivedcopies,orrights,fromyouunderthisLicensewillnot havetheirlicensesterminatedsolongassuchpartiesremaininfull compliance. 10.FUTUREREVISIONSOFTHISLICENSE TheFreeSoftwareFoundationmaypublishnew,revisedversionsofthe GNUFreeDocumentationLicensefromtimetotime.Suchnewversions
Pgina81/82
willbesimilarinspirittothepresentversion,butmaydifferindetailto addressnewproblemsorconcerns.Seehttp://www.gnu.org/copyleft/. EachversionoftheLicenseisgivenadistinguishingversionnumber.If theDocumentspecifiesthataparticularnumberedversionofthisLicense "oranylaterversion"appliestoit,youhavetheoptionoffollowingthe termsandconditionseitherofthatspecifiedversionorofanylater versionthathasbeenpublished(notasadraft)bytheFreeSoftware Foundation.IftheDocumentdoesnotspecifyaversionnumberofthis License,youmaychooseanyversioneverpublished(notasadraft)bythe FreeSoftwareFoundation.
Pgina82/82

SOAr en v1.0

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SOAr en v1.0

Uploaded by

Copyright:

Available Formats

SOAr v1 http://www.soarframework.

Page 1 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Author Csar Obach-Renner March 2007

Page 2 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 3 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 7 EAI First Generation: Point-to-point................................ 22

1.2 5.3 5.4 6 6.1 6.2 6.3

Business Services Interface (BSI) ......................................................................................................... 33

Integration Platform Anatomy............................................................................................................... 49

How is SOAr implemented? ................................................................................................................. 55

Integration Scope Criteria............................................ 69

8.6.3.3 Architecture.................................................................................................... 69 8.6.3.4 Design............................................................................................................. 69

GNU Free Documentation License ....................................................................................................... 73

Page 5 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 6 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

3.1 About Gurulab

Page 7 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

3.2 Who has to read this book?

3.3 Website support and contact information

Page 8 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

3.4 About English Terms

Page 10 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 11 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 1 Level 1 of the NGITP maturity model

Page 13 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 2 Level 2 of the NGITP maturity model

Page 14 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 3 Level 3 of the NGITP maturity model

Page 15 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 4 Level 4 of the NGITP maturity model

Page 16 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 17 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 18 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 19 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Functional Components Corporate Services

Page 20 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Applications implementing O/S Manager functions.

Page 21 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

5.1 SOAr as EAI fourth generation

First generation: Point-to-point integration

EAI stands for Enterprise Application Integration.

Page 22 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Second generation: Broker Integration

Figure 8 EAI Second Generation: Integration Hub/Broker

Page 23 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Third generation: SOA

Page 24 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Figure 9 EAI Third Generation: SOA

Page 25 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Fourth generation: SOAr

Page 26 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 27 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 28 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 29 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

Page 30 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

5.3 SOAr and BPM

Page 31 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

5.4 Key Elements for a SOAr successful implementation

Page 32 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org

6 Business Services Interface (BSI)

6.1 BSI Quality

Page 33 of 82 Copyright (c) 2007 Cesar Obach-Renner, Gurulab.org