A BIAN Building Block Service Repository and Registry

Transcription

1 Banking Industry Architecture Network A BIAN Building Block Repository and Registry Author: BIAN Working Group Repository Version: 1.0 Last Change: July 1, 2009

2 Organization Authors Role Name Company Bruno Bonati Claus Hagen Oliver Kling Pieter Steyn BIAN Credit Suisse BIAN Standard Bank Version History: Version Date of Change Author /07/2009 BIAN Page 2 of 18

3 Copyright Copyright 2009 by BIAN Association. All rights reserved. THIS DOCUMENT IS PROVIDED "AS IS," AND THE ASSOCIATION AND ITS MEMBERS, MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON- INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THIS DOCUMENT ARE SUITABLE FOR ANY PURPOSE; OR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. NEITHER THE ASSOCIATION NOR ITS MEMBERS WILL BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION OF THIS DOCUMENT UNLESS SUCH DAMAGES ARE CAUSED BY WILFUL MISCONDUCT OR GROSS NEGLIGENCE. THE FOREGOING DISCLAIMER AND LIMITATION ON LIABILITY DO NOT APPLY TO, INVALIDATE, OR LIMIT REPRESENTATIONS AND WARRANTIES MADE BY THE MEMBERS TO THE ASSOCIATION AND OTHER MEMBERS IN CERTAIN WRITTEN POLICIES OF THE ASSOCIATION. Typographical Conventions The type styles shown below are used in this document to distinguish programming statements from ordinary English. However, these conventions are not used in tables o section headings where no distinction is necessary. Lucida Sans bold - OMG Interface Definition Language (OMG IDL) and syntax elements. Courier bold - Programming language elements. Lucida Sans - Exceptions Terms that appear in italics are defined in the glossary. Italic text also represents the name of a document, specification, or other publication.

4 Table of Contents 1 Introduction Purpose of this Document Approach of the Definition Team Background and Origination of Terms Registry Repository Relationship between Environment Goals of a Repository Scope of this Document Overview of a Repository Repository infrastructure & Architecture Infrastructure The architecture of the Repository Storage and display of services The conceptual view of the repository Consumer portal Contract Management / SLA Repository process Access control and security Quality control Organization Availability Roles Versioning Monitoring Reporting Case studies Large European Bank Large European Bank Software Provider Questionnaire on Building Block Repository Page 4 of 18

5 1 Introduction 1.1 Purpose of this Document SOA is a topic of interest for many areas in the organization, affecting their processes, roles and responsibilities and amongst others the technical infrastructure to run a Bank. Heavily discussed, promoted and obviously of great importance is the Enterprise s Bus (ESB). The ESB is, however, not the only infrastructure element needed, and this document is dedicated to another key infrastructure building block: the. Over time, companies that adopt SOA steadily increase the number of available services. In the beginning, managing these services is not too difficult and it can be done manually. Eventually, when a whole range of services exist, manual tracking mechanisms such as databases, address books or spreadsheets can no longer fulfill the requirement to function as the hub between the service provider and the service consumer. The Repository provides the ability to register, discover and govern services. Experience shows that the features and functionality required in real life banking IT scenarios cannot be fulfilled by products available in the market currently. Furthermore the terms Repository and Registry are used in a broad context and for a large range of products, lacking a precise definition and a common understanding which makes comparison of available product offerings difficult. As a is essential for SOA, this document is intended to provide insight into the topic from multiple perspectives. 1.2 Approach of the Definition Team This document is based on the experience of members in BIAN with having service repositories in place. It is a very practical view on the topic and in some ways also contrary to what the literature and vendor brochures describe. This report is not, however, an attempt to be a definitive and complete specification of this topic. In all of the conceptual documents and in the literature there is a clear distinction between a Repository and a Registry. It is important to note that the industry lacks a clear definition of which functions and elements belong to either of them, and therefore we are describing a set of possible features and attributes of a repository and/or registry. One of our objectives is to achieve a more common understanding of this topic by defining the terms and descriptions of the overall set of functionality. Currently only a few banks and IT experts have experience with a Repository in a large scale environment. SOA in banking is still a new discipline and some banks running a SOA successfully still do not have a sophisticated Repository. The approach we took for our analysis was to capture information through a questionnaire distributed to experienced architects. The questionnaire is attached to this report as an appendix and the findings of the interviews are the basis of the structure of this paper. 1.3 Background and Origination of Terms Registry The term registry has its origin in the localization and the description of web services. A registry could be a governance infrastructure component for finding and using services based on different sorts of metainformation. This meta-information covers different aspects of the provided services: - semantic of a service - qualitative properties like o availability Page 5 of 18

6 o statements about performance o etc. - implementations of services The amount of information provided by a registry should be sufficient and necessary for all service requestors to discover the required services and establish a binding to the most appropriate implementation. A further definition for the term registry, publicly available is: A Basic function for finding, publishing, subscribing and managing service assets Repository Repositories emerged from the application development environment. They are used to manage all kinds of information and artifacts related to the services. The content of these repositories can be subdivided into three domains (other partitions are possible): - contract management and Governance - Development (design time and build-time) - management (run-time). Another publicly available definition is: A Repository offers functions to enable a SOA lifecycle; functions include metadata management, service governance and the ability to store services assets physically. Repositories today mainly are focused on design [and build] time services Relationship between The close relationships between these two components require a careful synchronization and interlinking of their content. We need to assess whether the distinction between a repository and a registry has to be made in the implementation. There are different models describing the relationship between Repository and Registry. One very important aspect is the actual content, and another is the set of features around managing a Repository. One of the success factors for implementing a Repository is how it is integrated with the systems that connect to the repository, and this warrants further consideration. From our analysis we observed two different views in terms of the relationship between the Repository and Registry: 1) Banks and Providers with a very pragmatic approach and extensive experience in SOA observe a clear trend in the market that the differentiation between disappears more and more in best practice. The leading tools combine the basic functions of a Registry with the broad range of capabilities of a Repository. 2) The separation is considered rather driven by history: Most of the providers come from the registry part where UDDI was there in place for quite a long time as a standard. These providers develop their solutions more towards original repository functions. We therefore use the term Repository reflecting the combination of registry and repository in the next chapters. The following figure provides an overview of the topic. Page 6 of 18

7 Governance Infrastructure Components Contract Management Repository Development Repository Management Repository Provider user Dependencies Roadmap Configuration Deployment Contract SLA Models Testcases Code Documents Capacity Management Mediation (Routing) Monitoring Reporting Registry Policies Qualitative Attributes Provider Interface Binding Figure 1 Perspective on Repositories and Registries Environment Some banks and providers emphasize the context in which a Repository should be embedded. They see the content of a Repository even wider. Possible candidates who are highly connected to the Repository are: - the developer platform for services which should be technology independent but has to consider the different types of services - a data modeling tool Furthermore it is important to connect the Repository to other repositories and systems: - registry of applications - detailed description of business functions and processes - Source code repositories Goals of a Repository The Repository stores service definitions, describes the features of the services and provides the artifacts (e.g. Level Agreements), concepts (e.g. Business Object Model) and methods (e.g. Versioning) around services. The main purpose of the repository is to provide component owners with a mechanism to manage the services delivered by their components, so that: the developers can generate and publish service interfaces consumers can use powerful search functions to find the right services in a central catalogue the service landscape can be structured 1.4 Scope of this Document BIAN focuses mainly on IT or application service definitions. We therefore restrict the scope of this document to the Repository containing IT s. It is interesting that the interviewees did not mention one example where Business s or Business Processes are part of their Repository except SAP managing integrations scenarios and processes in the Repository. Page 7 of 18

8 A repository focused on business or even B2B s faces completely different challenges, which are not addressed in this paper. There are many articles and papers that emphasize the necessity that a Repository should not only focus on IT services, and a lot of strategic questions mentioned in the literature should be supported by an integrated Repository: - What is the impact of strategic changes in business to IT? - What parts of IT are affected by Business process outsourcing? - Where is there a need for action on the IT side when implementing new products? It seems too early to define a clear scope for this topic that covers the business side completely. The scope of this paper is therefore focused on a Repository with the majority of services being developed in-house, where a Repository is embedded in an ecosystem of other connected. These include a UML tool for managing the application architecture, BPM design tools like ARIS managing business processes, or an architecture management tool (inventory, status, interfaces, and connections of applications into a project). Page 8 of 18

9 2 Overview of a Repository 2.1 Repository infrastructure & Architecture Infrastructure When selecting the infrastructure for the service repository one has to consider the technology platform of the actual services that will be delivered. Information about the technology a service is built on is very important in a Repository. The main criterion to choose the appropriate technology for a Repository is the technical environment and platform preference of the bank. The bank must be able to operate the repository with its existing staff and skills. It does not make sense, for example, to have a Repository based on Java if Java is not used in the bank. On the other hand if the bank uses mainly mainframe technology it makes sense to have the repository also in this technology The architecture of the Repository There are basically two approaches to structuring the architecture of a Repository: Single Repository or Federated repositories. A single Repository works in smaller and less complex environments, with only a few systems in place around the service repositories. In larger banks, however, ecosystem architecture or a federated approach is required because the Repository has to be embedded in the system landscape and must be connected to many tools. 2.2 Storage and display of services The Repository should enable the storage, discovery, and display of services. It will consist of conceptual and logical views. The logical view could be modeled using a Unified Modeling Language (UML) model (represented by a set of related UML diagrams) that defines the full detail of the service s behavioral and information models. The model will include complete definitions of each class, interface, operation, attribute, and association. The Repository should contain images of each diagram in the model (or links to images in an appropriate model repository) and a textual list of the classes, interfaces, operations, attributes, and associations (and their definitions). The repository stores service interfaces (which represent the physical view of the service s behavior and data exchange models). The definition of a service interface will be specific to the service interaction profile that governs interaction with that service interface. The content of a Repository is not limited to services. A full solutions portfolio gives an overview of all services and a catalogue of applications. Large banks do not typically put all of the different levels of solutions into one tool. The solution details could be registration information, ownership information, pricing information, and Sub-solutions Categorization. Design-time services are typically kept in one place; runtime information would be very valuable but that has to be developed. Key Finding: Most of the banks and providers that already have a repository in place are considering it as a solution portfolio and not just a Repository, even though one could put only services in there. Page 9 of 18

10 2.3 The conceptual view of the repository The conceptual view of the Repository consists of a single document or page for each service. description metadata contains properties like: - name - version information - description - contact information for various purposes (business contact, developer contact, etc.) - One large provider may support various services in the repository. s can have unlimited fields and definitions and they support unlimited service types. They can be created as a separate entity. When a solution is added to the registry a service type will be selected. This service types then display the fields for entry based for example on the XML Binding. Defining and maintaining relationships is important. In the life cycle management of services it is necessary to manage relationships between different versions. These relationships enable transparency in terms of which services are derived from, or replaced by others. Properties include: - user-defined states like created, approved, published, used, and operated - a complete description of the real-world environment of invoking the service - a list of the main actions that a consumer can perform on the service - a list of the main Business objects involved in interaction with the service All the important meta models (compare BIAN Metamodel) should be published in the Repository: - The Landscape View based on the Landscape Model Language - the Business Process View based on the Business Process Model Language - the Software Component View based on the Software Component Model Language - the Business Object and Message Model View based on a Business Object Model Language - the Business Data Exchange Model Language - the Use Case View - in conjunction with relevant market standards. Besides these models, the repository should also contain real Business Architecture Content as the Landscape, the Business Object Model of the Bank, a Data Exchange Model and Functional Landscape could be connected to the individual services. Methodology and guidelines to define services and sub-domains can also be found in the Repository. 2.4 Consumer portal There are different kinds of users of the Repository: - Provider: the developer of a service - Consumer: the prospective consumer of services - Architects and CIO s: to monitor and manage The goal is to develop the access to the Repository from a consumer perspective via a GUI tool through which services and solutions can be made available and procured. The consumer will be able to view service catalogues and can have access to view the information of the whole repository and all the details of a service. Page 10 of 18

11 There are a variety of ways to facilitate finding services: - full text search capability for all service artifacts and metadata - predefined queries can (stored as template) - The repository should notify repository users via appropriate means (e.g. ) when artifacts are added to, removed from, or changed within the repository. Users should be able to register (and de-register) interest in particular artifacts or types of artifacts; this should be accomplished via a self-service capability, rather than requiring intervention from the repository administrator. 2.5 Contract Management / SLA The service contract defines the service level that consumers can expect from services in terms of performance, availability, pre- and post-conditions. They also define the financial parameters if the services support a billing model. Page 11 of 18

12 3 Repository process Access control and security The Repository should control and restrict access to modify, add, or delete information about services in the repository. The view of services should not be restricted because it is important that developers can see the available services in order to encourage reuse. The access to the Repository has to be defined and managed properly. The access control system for the providers and consumers is the same, because providers and consumers of services are the IT developers and/or architects. In large banks where the majority of services are designed by the application development units it is common practice to use the existing application access control system Quality control It is important that the quality of services is controlled through a separate process outside the Repository. Links between the Repository and the processes are needed. SAP tries to keep part of the quality functions in the Repository. It is a trend that large banks and providers define the Repository as the centre and owner to manage the service quality process Organization The organization of the Repository typically follows the organization of the IT department. The owner of the Repository as an IT tool is the Development support unit in the bank. This unit is typically also responsible for the third-line support of systems. The Repository is treated as just another application, and supported as follows: - First-level support is the call centre or help desk - Second-level support is the responsibility of IT production - Third-level support is provided by IT development - Fourth-level support is provided by the software vendor Availability As soon as the Repository is in production, contingency and backup systems become an important issue Roles In a SOA you require new roles that are unfamiliar in a non-soa environment, e.g. a Designer is a new role that has the authorization to register services Versioning The versioning of services is a very important Repository function. There are different approaches to versioning. At one bank we observed that they have three versions in production at the same time Monitoring It is important to have system management tools for the repository which enable proper monitoring of the system and the services Reporting Different users of the services repository have a different requirement for reports. These include application developers, business people, IT Managers and Architects. Page 12 of 18

13 4 Case studies 4.1 Large European Bank 1 The bank has many years experience in SOA in Banking. About five years ago the bank developed a Repository of their own, as there was no solution available on the market that met their requirements. This solution has many disadvantages which are typical of a system that grew over a number of years and had to adapt to the progress in terms of SOA and the new concepts. The main gap of the old solution was: - designed too much from a developer perspective - high technical complexity - manual interfaces - redundancies and - many media breaks It also became clear to the bank that they required a solution that also has a strong interlink to an application environment supporting the developers to define and implement services. The bank looked for a standard software product. It is typical about the maturity of SOA in Banking that the best solution they found only covered about 40% of the requirements. This means that the tool had to be developed in a joint venture. Interestingly the bank had to give up this approach because it was not possible to customize the standard tool in a way that it was able to cover the missing functionality. The bank has now chosen again an in house development approach. The main purpose of this new repository is: - that the component owner can manage the services of their components, - that the developers can produce source code with the platform for services, and - that the consumer has a catalogue with powerful search functions so they can find the right service. There is however no strong focus on SLA s. The bank has three types of services in the Repository: - asynchronous - synchronous and - file transfer. 4.2 Large European Bank 2 This bank structures the IT functions into mainly three domains: - Sales - Operations - Analytics (controlling). SOA is only addressed and realized in the Sales area. The Bank implemented a middleware based on a JAVA Web Application Server with a process layer. s are implemented in this middleware by using encapsulating functionality of the back-end systems via adapters. Page 13 of 18

14 At the moment the bank is in the phase of identifying useful and reusable functions, for this purpose they developed an own database where the following information related to s is stored: - technology of the function - parameter structure - used business objects - providing application or system - communication (synchronous, asynchronous, mass data interface) - technical and business description - contact person - dependencies from other functions - pre- and post conditions - availability of the function. With this starting point they want to identify services beyond the sales area. As soon these services are implemented they will be stored in the database as well. The main purpose of this tool or registry today is the support of architects. There are only a few reporting tools mostly based on SQL statements. An analyzing tool for architectural evaluation has been implemented recently. Nearly all information stored in the database is entered manually. Requests from software developers with regards to availability of services have to be addressed to the architect. There are no user interfaces implemented. The reason for this setup is to limit the tool to architectural decisions and to build up a SOA infrastructure. It is a first step into the SOA world. The experience obtained will be used for the next steps. The registry is still on the planning horizon. 4.3 Software Provider The company started with a lot of products which in a way were comparable to silo solutions in a bank. There a different data structures behind the solution, and techniques and architecture were different. The company will increase the value for the customer if they were to provide these solutions in an overall context without functional overlaps and with reduced technical and functional complexity. The way to do that is to decompose the monolithic products into small components and services that can be orchestrated into new small products or composed services. It is obvious that the company needs a registry and repository to manage these components. The system has been built over the last 6 years. The repository is based on a modified WIKI, and therefore there are no restrictions on the content that can be added. Furthermore there is a direct link to the registry from where the services and small products (composed services) can be accessed. Both the registry and the repository are open for the integration of third party products and other services. The interaction with other products is also possible. The only precondition is to use common standards like Web s (WSDL, XML). It is notable that this company successfully manages the separation between registry and repository, as opposed to the trend of the market to integrate these functions into one system and approach. It is evident that the registry and repository of this software company does not cover runtime aspects of services. Page 14 of 18

15 In the Registry they have a database of solution details as registration information, ownership information pricing and SLA. The content of the repository on the other hand is a rich text description with the following artifacts attached: - XML Schema - WSDL - Documents (PDF, Word Documents) - Data Models, - Class Definitions, - SQL Scripts - SDK s - Specifications - etc. Page 15 of 18

16 5 Questionnaire on Building Block Repository 1. Definition: What is your understanding / Definition of Repository or Registry? One possible Definition: The governance of an IT environment obeying the characteristics of a service-oriented architecture imposes new demands for all involved stakeholders. Registries and repositories are two central components of a governance infrastructure supporting all governance activities. A registry is a governance infrastructure component for finding and using services based on different sorts of meta-information. This meta-information covers different aspects of the provided services: - Semantic of a service - Qualitative properties (availability, statements about performance, etc.) - Implementations of a service The amount of information provided by a registry should be sufficient and necessary for all service requestors to discover appropriated services and establishing a binding to the best fitting implementation. Repositories are used to manage all other kinds of information and artifacts related to the services offered by repositories. The close relationships between these two components require a careful synchronization and interlinking of their contents. As a consequence some vendors offer products which integrate the functionalities of registries and repositories. The content of these repositories can be subdivided into three domains (other partitions are possible): - contract management - Development (build-time) - management (run-time) The following diagram illustrates the different components and shows some portion of their contents. Governance Infrastructure Components Contract Management Repository Development Repository Management Repository Provider user Dependencies Roadmap Configuration Deployment Contract SLA Models Testcases Code Documents Capacity Management Mediation (Routing) Monitoring Reporting Registry Policies Qualitative Attributes Provider Interface Binding Page 16 of 18

17 2. Detailed view Describe how you define the content with regards to the following topics based on your experience. Contract Management a. SLA b. Responsible Person, Provider c. -Access (Security-Aspects) d. User of (Applications, Departments) Development e. Naming convention f. -Types g. -Documentation h. -Design-Time-Models / interface patterns i. Business Information j. Relations to other services / Does the SR provide information about interoperability of services? About semantic relations (business object, service landscape allocation)? (Dependencies) k. Code l. Test cases m. Are only implemented services inside or also information about planned services? (Roadmap) Management n. Which Tools are used? o. Physical location, Capacity management, Routing p. synchronous/asynchronous access q. Facilities to find services r. Monitoring, reporting Registry s. Business process models t. Are there composite services inside (out of other services)? u. Policies v. Interface Other important content 3. Which IT-Middleware can be used for publishing services? a. Web services b. Enterprise JavaBeans c..net d. UDDI e. IDL Specification f. Own standards 4. Security a. Are there any access-control mechanism? b. If, yes. Do they depend on the application which uses the or a User-access-list? c. If, yes. Are there different levels of access to use the? d. What happens when a is not available? e. What happens when the Repository is not available? f. Is the Repository only internal (Intranet) or external (internet) accessible? g. Who can register a service? h. Are only public services inside or also private services? Page 17 of 18

18 5. Versioning a. Is there only the latest version accessible? Or is it possible to use different versions of one service in parallel? b. How about the history of published s? c. How call the users attention of new (or new versions) s? 6. Access a. How are s provided to users of services? b. Is the -Repository requested on runtime or only design time? c. Which Protocols are used? d. Are s offered centrally? If not, how? 7. Process / Organisation a. How is the quality controlling of services organized? b. How does the process of service registration work? c. Who is responsible for which tasks? How is the access to the SR organized? d. Is there today public SR available? Do you use them? If not why not. If yes what kind of services? e. Are Business processes modeled and included in the Repository? 8. Interoperability a. Is it possible to connect the registry with other repositories? b. What kinds of repositories can be integrated? c. What technology is used for integration (e.g. XML)? Page 18 of 18