Computación Orientada al Servicio Conceptos, Tecnología y Diseño

Presentación del tema: "Computación Orientada al Servicio Conceptos, Tecnología y Diseño"— Transcripción de la presentación:

1 Computación Orientada al Servicio Conceptos, Tecnología y Diseño
Carlos Humberto Barrera Arquitecto de IT General Business IBM de Colombia

2 Entornos de negocio complejos impulsan el cambio en TI
Business Challenges Business Requirements Mejorar la Innovación y crecimiento Mejorar la Flexibilidad y Agilidad Tomar mejores decisiones… rápido Mejorar la Colaboración y el empoderamiento Implementar y optimizar procesos de negocio end-to-end Reducir costo y complejidad Globalización Presiones por competencia Fidelidad de cliente erosionada Complejidad en la cadena de suministro Leyes, regulaciones y Compliance Transformaciones de Industria Adquisiciones&Fusiones IT Infrastructure Must Businesses are facing a lot of market pressures and competitive dynamics. They have a set of requirements that will help them address these challenges. In order to support the requirements they need a IT infrastructure which is able to adapt and be responsive to the changing businesses needs, and can be deployed in projects which can be built upon as value is realized. They need to manage complexity to prevent it from inhibiting innovation within their own businesses. Permitir Flexibilidad Entregar Calidad de Servicio(QoS) Ser segura Ser confiable y escalable Be Easy to Enhance, Reconfigure and Maintain Aprovechar sobre la base de información confiable Integrar sistemas legados e islas de información Implementar en pasos incrementales Complexity Inhibits Business Innovation

3 Barreras que impiden flexibilidad en el negocio
Arquitectura empresarial limitada Carencia de estándares Compra de aplicaciones puntuales para atender necesidades individuales de Líneas de negocio **Main point: Business flexibility requires IT flexibility. IT flexibility is very difficult and expensive with today’s systems that look like the diagram. So now that we’ve talked about the need for flexibility and reuse, let’s look at some of the barriers that sometimes prevent companies from getting to where they want to be. Again, let’s emphasize that the business can only be as flexible as the IT systems that support it. On the right, you’ll see an actual application architecture for a consumer electronics company. Current approaches to IT architecture do not support these drivers The text on the left all has to do with IT infrastructure that has grown bit by bit, over the years to handle focused issues with no recognizable roadmap. Linkages between pieces of this infrastructure tend to be inflexible and very difficult, expensive, and time-consuming to change.

4 Evolución del mercado esta siendo delineado por tendencias emergentes
Nuevas capacidades para modelos de consumo estan ganando aceptación La naturaleza de la aplicación esta cambiando La adopción de SOA empuja el apetito for Servicios de Negocio y su disponibilidad . Aproximaciones que facilitan su simple consumo estan ganando aceptación: Protocolos Web 2.0 Software como un Servicio (SaaS) En respuesta a la necesidad de flexibilidad, las aplicaciones estan evolucionando de construcciones monoliticas a compuestas, basadas en servicios de negocios expuestas. Esto es cambiando la dinamica de como las aplicaciones de negocio: Serán creadas y y originadas Y de quienes serán capaces de crearlas Incrementando foco en especialización de industria El Negocio y TI estan convergiendo The nature of the application is changing In response to the need for flexibility, the application is evolving from clearly delineated monolithic blocks of code to composites based on exposed business services, this impacts how applications will be created and sourced application creation is expanding to address adhoc processes, and situational circumstances, changing the dynamics of what is a business application and who creates it New capability consumption models are gaining root As SOA adoption fuels the appetite for and availability of business services, Web 2.0 technologies, and Software as a Service delivery models are gaining traction, providing simpler ways to facilitate consumption and leverage of capabilities in business applications Increasing focus on Industry Specialization As SOA drives alignment between IT resources and the business processes they serve, there is a growing need to deliver capability in the context of the industry vertical/domain in which the business function operates Convergence of Business and IT With the passing of the era of technology for technology sake, renewed focus on the business value that IT brings is changing the skill set required to be effective in this new environment. Both in terms of effectively leveraging technology to innovate the business as well as delivering capabilities that are meaningful to the business SOA esta alineando los recursos de IT y los procesos de negocio a los cuales sirve. Como resultado… Existe una creciente necesidad en desarrollar capacidades en el contexto de industria en el cual el negocio opera. Con el paso de la era de la tecnología para el bien de la tecnología y centrarse nuevamente en el valor de negocio que aporta TI… Cambiando un conjunto de skills son requeridos para efectivamente Aprovechar tecnología para innovar el negocio Desarrollar capacidades que hacen sentido al negocio 4

5 SOA: El habilitador crítico para la Innovación
Innovation That Matters * “La solución basada en SOA nos ha permitido transformar nuestros productos logrando así ser mas innovadores, expandir nuestro mercado y ser mas competitivos. Esto nos permitirá crecer nuestro negocio de manera significativa en los años venideros." IBM recently conducted a survey (in conjunction with The Economist magazine and Nikkei Research) to find out what was on the minds of CEOs. The survey revealed that CEOs have three mind-set changes: Growth is back on their agenda…at the top…with cost containment having moved to a distant 2nd. CEO’S think they are going to grow by introducing new products, by providing product differentiation, and by leveraging customer information to better service customers (a definite change from last year). The second major change is that CEOs are no longer simply looking for efficient organizations, but building organizations that are agile; organizations that not only respond to market changes, but can even cause those changes to happen. They want responsiveness to be a competitive advantage rather than a defense mechanism. Third, CEOs are looking at how to make their people more effective – to enable people with tools, information, and skills to work across the organization (beyond silo barriers). We also have survey data from CIOs that reveal that their priorities are aligned to those to of the CEO: First, they say they need to align IT and business goals (so IT can contribute to business growth) Second, IT must build responsiveness into the business. Businesses can’t be responsive without proper IT capabilities. Third, IT must enable people to be successful in their projects. Answering these challenges is what on demand business is all about. Notes: Survey is conducted annually by our BCS group to understand what the top-down needs of the market are.. The rest of the presentation will tie back to these recurring themes (CEO needs). “SOA es el corazón de la próxima ola de innovación. Los lideres que lo ejecuten de la manera correcta, tendrán la capacidad de cambio y adaptación rápida” “SOA es critico para … ejecutar la visión on-demand y en preparación … para los cambios incrementales en el tiempo. Las compañías … tomaran mejores decisiones.”

6 Porque SOA ? “Organizations are not simply focused on adopting SOA; they want to solve business needs, and that should be their primary focus.” IDC, May 2007 Primary Drivers of Service Oriented Architecture Adoption “While most vendors promote generic SOA benefits like business agility, customers are investing based on meeting the more specific requirements endemic to their industry.” AMR Research, February 2007 AMR survey conducted with 1,077 respondents IDC methodology: IDC’s Software Developer Network Survey ( is an ongoing market research initiative that conducts one survey each calendar quarter in collaboration with over a dozen large IT vendors. Each participating vendor recruits respondents to IDC’s Web-based, opt-in survey from its respective developer network. The result is a very large sample of professional software developers worldwide from user enterprises and IT suppliers such as ISVs and system integrators. There are no restrictions on the size of the respondent’s organization, and the broadest possible scope has been assumed for what roles the respondent could play in the overall software development life cycle, including software developers, architects, engineers, quality assurance testers, and management. Source: Deepening Tracks on the SOA Journey”, IDC, May 2007

7 La Primera Vez…

8 Lo que se propuso…

9 Pero qué es …..? … orientación de servicios ? … un servicio?
Una tarea repetible del “negocio” - e.g., verificar el crédito del cliente; abrir una nueva cuenta Una manera de integrar su negocio como servicios “conectados” y los resultados que proveen Main Point: Services are repeatable business tasks. Business processes are a series of services snapped together like building blocks. SOA is an architectural style that makes this possible Servicios … Expone una interfase bien definida. Oculta los detalles de la implementación. Es invocable mediante mecanismos basado en estándares abiertos. Puede ser granular, complejo o algo intermedio. Un servicio complejo, es aquel que expone una función de alto nivel de negocio, el a su vez invoca a otros servicios internos. Un servicio granular es aquel que implementa una y solo una función muy especifica. Puede tener ambiente de “request/response” o “fire and forget”. Let’s start by looking at some base-line definitions so we’re all talking about in the same terms. First of all, what is a service? <read definition> It’s important to stress that we’re talking about a part of a business process here. Don’t think about software or IT. Think about what your company does on a day to day basis and break those business processes up into repeatable business tasks or components. If you look at the graphic in the middle, this is the analogy of building blocks <do NOT use the word “Legos”> snapping together to build a structure. Services are the building blocks and they are snapped together into a business process. Second, what is Service Orientation? Building on our definition of a service, Service Orientation is a way of integrating your business as linked services and, more importantly, the outcomes that they bring. We’re still not talking about technology; we’re talking about a thought process and a business philosophy. What is SOA? It is quite simply the IT architectural style that supports the Service Orientation thought process makes it a reality. And finally, what is a Composite Application? <read definition> So composite applications are the actual running services that have been assembled and strung together to support the what your business does. SOA helps make building and adjusting composite applications fast and easy. **Main point** SOA makes it easy to snap together services into a business process just like snapping together building blocks into a structure. … arquitectura orientada a servicios (SOA)? Un estilo de arquitectura TI que soporta la integración de su Negocio como servicios vinculados entre si

10 What is … “Service Oriented Architecture” - is a framework for integrating business processes and supporting IT infrastructure as secure, standardized components—services— that can be reused and combined to address changing business priorities. SOA framework helps an enterprise wide IT architecture to promotes loose coupling, reuse, and interoperability between systems.

11 Global Business Services
Why do enterprise need Service Oriented Architecture Framework ? In today's enterprise world, it is very difficult to survive without leveraging diverse technologies into both their day-to-day operations and their long-term strategy. An organization must be more dynamic to address frequent market changes, reducing operating cost and higher customer requirement. So, we believe SOA is the way that companies can develop IT infrastructures capable of supporting dynamic enterprises. Implementing business process driven IT with SOA promises to simplify and accelerate business transactions. Therefore, the agility and flexibility options of an SOA allow organizations to better handle business situations like the following: Department, intracompany, or intercompany mergers Acquisition Divestiture Product or service rollouts Business partner, customer, or supplier changes Geographical expansion Competitive gains in market share @ Copyright IBM Corporation 2007

12 Global Business Services
When Not to Implement an SOA Framework…. When enterprise have a homogeneous IT Environment When real-time performance is not critical When Flexibility is not needed When tight coupling is needed When Organization isn’t ready for it. @ Copyright IBM Corporation 2007

13 SOA “Mitologia” SOA no es una Revolución
SOA no es solamente un producto de software No existe tal cosa como ‘SOA Compliance’ SOA no es acerca de acoplar servicios a una aplicación o plataforma específica SOA ≠“RIP & Replace” de aplicaciones existentes SOA ≠ EAI SOA ≠ Web Services SOA ≠ ESB SOA ≠ BPEL

14 Common misconceptions about what SOA Framework Is
Service Oriented Architecture is a great product developed by various lead software vendors. Service Oriented Architecture will resolve most of our enterprise integration problem in less time. Service Oriented Architecture can be easily implemented by developing web service. Then What is SOA…… SOA is design pattern that helps us to build better solutions by using services. SOA project should follow middle-out approach and snowball approach while designing SOA project. SOA is an approach to design service based systems. Web Service is an implementations methodology that uses specific standards and language protocols to execute an SOA Solution.

15 IT’s architectural evolution: making IT more responsive
Pre 1950’s To 1960’s 1970’s to mid 1980’s 1980’s to Mid 1990’s Mid 1990’s to Early 2000’s Late 1990’s Today Monolithic Architectures Sub-routines / Remote Procedure Calls Remote Object Invocation Message Processing EAI Services (SOA) The desire to make IT more flexible is not new. Indeed, it is as old as the IT industry itself. Early initiatives involved making monolithic architectures more flexible by breaking them into callable subroutines and procedure calls. The idea was then built upon by the concept of business objects – discrete pieces of code which included data and its behavior which could change depending on context. Object technologies were mostly tightly coupled and so messaging technologies were developed to loosely couple applications from one another. Various EAI techniques were then developed to make applications even more modular. Today, we are at a culmination of all of these architectures with the notion of Service Oriented Architectures. SOA blends the best of all these concepts into one new architecture that promises to make the notion of applications even more flexible. Increasing Modularity to Achieve Flexibility

16 Create a Service from the various components
DFK Data Warehouse General Ledger AP Sales Corrections PO Receiving Return to Vendor Warehouse Management Credit App Employee Change Notice OTHER APPS - PC ACCTS REC APPS - PC INVENTORY CONTROL APPS - PC Journal Entry Tool Kit Scorecard Resource Scheduling P09 - P17 Cyb. Millennium Millennuim 3.0 Banks - ACH and Pos to Pay Cobra Stock Status Polling On-line New Hire Entry CTS Plan Administrators (401K, PCS, Life) D01 Post Load Billing Home Deliveries - Transfers Planning Purchase Order Solution Software Inventory Info Interface Sales Posting Price Management System Cycle Physical Inventory SKU Information Customer Repair Tracking I35 Early Warning Merchandise Analysis I13- Auto Replenishment CTO Intercept Counts Tex A ACH Stock Options Customer Perceived In-Stock Tx SS Capital Projects Fixed Assets Recon File Repair EDI Coordinator Mesa Data NEW Soundscan Resumix Op. Store Budget Reporting Tally Sheet Cash Receipts/Credit House Charges Ad Expense -Promo Price Marketing Support BMP - Bus performance Mngt Store Testing Media Bonus/HR Hand Scan Apps Shows POS Tax A04 - Cust Refund Chks Equifax Credit Cellular Rollover Satellite Scanning VAN SKU Rep Host to AS400 Communication Layaways Bus Systems V04-Sign Count Corrections N. P01- Masterfile Customer ABC Co Universal Account Reconcilliation Depository Banks Cell Phones - ISP AAS Cash Over/ Short Coop SKU Selection Tool Performance Supplier Compliance 1 DRK ABBX Misc Accounting/Finance Apps - PC/NT AIMS Mngr Approval Batch Forcasting Ad Measurement Ad Launcher Mkt Reactions Spec Source website Rebate Transfer Sign Writer Workspace PowerSuite Monitor Calendar Stores & Mrkts Due Dates Smart Plus Insertions Orders Budget Analysis Tool Print Costing Invoice App Reports Broadcast Filter Maintenance Printer PO Printer Vendor Setup Connect 3 PDF Transfe Spec Source SKU Tracking S20-Sales Prodigy PSP In-Home Warranty Process Servers (Imaging) Locate the service components Step 2 Step 1 Identify the Business Service – the basic SOA building block Repeat Step 4 Step 3 Construct the interface So how do you connect to services using SOA? Step 1: First you have to identify the kind of business service to which you want to connect. Step 2: That service may already exist somewhere within your organization, so you have to locate that service. That can be very tough, if all you have is point to point connections linking everything. Step 3: Next you have to construct the interface that connects the services. These may be quite complex and have a lot of transformation logic within them. Step 4: Finally, if you have to connect to many services, you will have to repeat the process over and over again.

17 Now that we have rendered the applications as services…
Determine Customer Eligibility Retrieve Credit Report Request additional info Etc…. Generate decline Once you have rendered the applications as service you can construct a business process that co-ordinates activity between them. Etc…. Business Process is implemented by integrating services

18 SOA Life Cycle SOA design principles
The guidelines in this section are concerned with the overall SOA system, representing decision points for establishing your system. What prescriptions and guidelines will you give the service designers and implementers? What capabilities will your SOA infrastructure offer? We give a number of suggested design principles, but each represents an engineering trade-off. Your enterprise may have specific requirements that lead you to make different choices from our general recommendations. Our intention in setting out our design principles is to identify the decision points; the responsibility for those decisions lies with the architects. We do not claim that our set of design principles is exhaustive; it is very likely that as you implement an SOA in your enterprise you will adopt additional principles, and we would be very interested to hear about them. SOA requires consistency There are many candidate technologies for creating, publishing, discovering, and invoking services. An SOA should provide a reference architecture specifying particular mechanisms that service providers and consumers will use; we should aim for consistency across all participants in the SOA. Such consistency should reduce development, integration, and maintenance effort. If there are needs for exceptions to the reference architecture, we prefer a complementary approach. For example, suppose that UDDI were the chosen mechanism for service publication and discovery, but a particular development team had a well-established development process based on some other repository technology? We would choose to invest effort in publishing that team's services to both repositories. Hence existing consumers of the service could use their familiar -- if nonstandard -- repository. Consumers operating in the common SOA infrastructure would be able to use the standard --perhaps UDDI -- repository for all services. SOA simplifies development We would expect any enterprise-scale SOA infrastructure to be both scalable and resilient; it should also include industrial-strength Enterprise Service Bus (ESB) and security technologies. Or, to put that another way, developers of services and processes targeted at the SOA infrastructure exploit sophisticated middleware, relying on the SOA infrastructure to provide solutions to problems such as authentication, message transformation, and reliable message delivery. One important principle should underlie the provision of these middleware capabilities: service and process developers should be insulated from the complexities of the middleware implementation. Our idealized goal is that developers working in our SOA environment should need only business domain knowledge and basic programming language skills. We can work towards this goal in a number of ways, as follows: Declarative techniques: The J2EE programming model is an example of using declarative techniques to provide separation of concerns between the application logic and the configuration of middleware. For example, an application assembler applies security authorization of roles for EJB methods by adding entries in deployment descriptors rather than in code; then a deployer will map the roles to users and groups. Note that the developer need write no authorization code. Abstractions: In some cases the SOA infrastructure may offer APIs for particular purposes. For example, the SOA infrastructure may have error reporting or auditing facilities. We should take considerable care in designing these APIs, paying attention to ease of use. We should favor declarative techniques over programmatic configuration of these facilities. Also, where standard APIs are available, for example the Java logging APIs, we should expose the SOA infrastructure capabilities via those standard APIs rather than devise our own. Code generation: Where some complexity of code is unavoidable it may be possible to use code generation techniques. As an example, consider Web Services Definition Language (WSDL), which can be used to hide complexities of SOAP, HTTP and JMS from the developer. This is accomplished through the combination of machine-readable interface definitions expressed in WSDL and tooling that can generate language-specific implementations of the relevant invocation code from the WSDL. Tooling: In cases where details of the SOA infrastructure unavoidably intrude into the developer's code, we can reduce complexity for the developer by extending the development environment with suitable tooling. An Eclipse-based environment offered by the IBM Rational® Software Development Platform products is readily extensible with custom plug-ins, code snippets, and user guides. Model-driven development: Model-driven development techniques can be seen as a particularly sophisticated combination of the previous two approaches, exploiting both tooling and code generation capabilities to simplify the development experience. The developer produces Unified Modeling Language (UML) models that can be transformed to code that includes the code necessary to exploit the SOA infrastructure. In summary, in defining a Service-Oriented Architecture and its infrastructure, we must pay careful attention to the needs of developers. Where we offer developers guidelines for how they should develop or use services we should seek mechanisms to encourage adherence to those guidelines. A general principle should be "Doing the easy thing is doing the right thing." In other words, adherence to the guidelines should be perceived as taking the line of least resistance. Governance within the SOA becomes a crucial element to its success. From the developer's perspective there is a responsibility to understand the SOA infrastructure and guidelines and to work with the guidelines rather than seek to avoid them. Services have standard, formally defined, machine-readable interfaces Having established that tooling and code generation can play a significant role in SOA implementation, we can now emphasize the importance of using machine-readable interfaces. When we describe interfaces using a well defined machine-readable language, we enable a broad range of tooling capabilities. Remembering that we wish to promote decoupling, we strongly favor the use of formally-defined open standard languages such as WSDL over a proprietary format. The concept of a machine readable approach should be expanded from the description of service interface, such as WSDL, to all other forms of declarative information or meta-data. This twin emphasis on declarative techniques and machine-readable metadata is what pushes the complexity away from the business application developer into the standards-based middleware. Technologies such as the emerging WS-Policy are an important enabler of this approach. Services are designed for reuse Service designers should keep in mind that any service they product can potentially become a reusable asset. The designers should not exclusively focus on requirements of the initial consumers of a service, but rather should undertake more extensive business analysis in order to determine more complete requirements. We recommend that designers consider the potential evolution of a service: The design must accommodate increasing throughput; if a service is successful then the number of consuming services may well increase and hence usage may well increase by orders of magnitude. If the number of consuming services increases then both data volumes and concurrent data access patterns may be significantly different from the initial situation. We must anticipate that there will be requests for extensions to the service; new consumers may well need additional functionality and modifications to existing functionality Many of the design principles we discuss in the remainder of this article are particularly relevant to ensuring the scalability and maintainability of services. We offer one word of caution: it is possible to spend undue effort in designing services for potential reuse and hence to "over-engineer" implementations. We would encourage an initial focus on the design of the service interface, ensuring that it enables scalability; our design principles should help with that. Then produce a tactical implementation of that interface sufficient to meet current, known requirements. Provided that the interface is well-designed it should be possible to substitute a more scalable implementation when the need arises.

19 Capas de Arquitectura Capa Procesos de Negocio Capa de Servicios
Estado Cuenta Empleado Tramite Ciudadano Finanzas Lotus Notes Capa Aplicaciones ERP CRM Directorio Recursos Humanos Capa Tecnología J2EE Linux IBM CICS Microsoft .NET CBDI Forum

20 High-level SOA Framework Architecture
Front End Application Business Processes Business Services Implementation Service Adaptors Business Application Service Portal Order Management ATP Pricing Order Processing Customer Quote to Cash Siebel SAP ERP Custom App COBOL Mainframe Orchestration SOA Enterprise Layers Definitions Front end application GUI or Front end application interface employed by business users. Business Processes Business processes that coordinate the activities of the organization. Business Services Services that model and define individual activities in a reusable and technology-neutral manner using web services. Components Components and objects that are used to implement and execute the service Business Application Business application data stored in systems-of-records, operational data stores, ERP, data warehouses and reporting system

21 Example Platinum Customer Consumers Channels Sales application
Central office Business Process Open Account Check Credit Process Order Account Activation Business Service atomic and composite Account Activation Verify Customer Address Verify Customer Credit Create Account IT Service Layer EJB SCA Message Flow Operational Systems Legacy Cobol SAP GL 3rd party System Address Verification Customer DB Alternative 3rd pty

22 La Arquitectura de Referencia SOA
Arquitectura de Datos y Business Intelligence Monitoreo e infraestructura QoS, Seguridad, Gestión, y Integración (Patrón Enterprise Service Bus) Consumidor Procesos de Negocio Coreografía de Procesos Servicios Atomicos y Compuestos Componentes de Servicios Sistemas Operacionales Cliente de Servicios Proveedor de Servicios JService Portlet WSRP B2B Otros Aplicación OO Aplicaciones In House Paquete Gobernabilidad Modelamiento de Servicios So, slide 25 shows what we’re calling the SOA solution stack, also the SOA reference architecture. But basically, how this is used in Strategy and Planning is we can actually lay out on each tier what the world would look like if in fact we applied Strategy and Planning. Servicio Compuesto Servicio Atómico Registro

23 SOA: ¿Pero que es un Servicio?
Los servicios son funciones que cuando son invocadas ejecutan una tarea específica. Por ejemplo: La función de sistema operativo, lógica definida de cliente, empaquetó el módulo de uso, el etc Servicios … Expone una interfase bien definida. Oculta los detalles de la implementación. Es invocable mediante mecanismos basado en estándares abiertos. Puede ser granular, complejo o algo intermedio. Un servicio complejo, es aquel que expone una función de alto nivel de negocio, el a su vez invoca a otros servicios internos. Un servicio granular es aquel que implementa una y solo una función muy especifica. Puede tener ambiente de “request/response” o “fire and forget”. Request-response, also known as request-reply, is a message exchange pattern in which a requestor sends a request message to a replier system which receives and processes the request, ultimately returning a message in response. This is a simple, but powerful messaging pattern which allows two applications to have a two-way conversation with one another over a channel. This pattern is especially common in client-server architectures.[1] For simplicity's sake, this pattern is typically implemented in a purely synchronous fashion, as in web service calls over HTTP, which holds a connection open and waits until the response is delivered or the timeout period expires. However, request-response may also be implemented asynchronously, with a response being returned at some unknown later time. This is often referred to as "sync over async", or "sync/async", and is common in EAI implemetations where slow aggregations, time-intensive functions, or human workflow must be performed before a response can be constructed and delivered.

24 Concepto Básico de Servicio
Consumidor Servicio 2. Descubrimiento 3. Unión Mensaje (SOAP) Directorio Servicio (UDDI) 4. Comunicación El Concepto Básico del Servicio: El proveedor del servicio publica su servicio en el Directorio de servicios como puede ser un UDDI, mediante un contrato WSDL el cual define la descripción de la interfase EL Consumidor del servicio opcionalmente puede descubrir el servicio consultando el directorio de servicios El consumidor del servicio usa el contrato para crear el protocolo de enlace al proveedor del servicio – requerimientoi tecnico para comunicarse con el servicio Para usar un servicio, los mensajes son intercambiados entre el consumidor y el proveedor empelando la dirección publicada por el servicio Dirección EndPoint Contrato (WSDL) Proveedor Servicio 1. Publicación

25 La implementación de SOA ofrece una flexibilidad IT necesaria para responder a los retos e iniciativas de negocio Flexibilidad del Negocio Rentabilidad, Procesos de negocio, Tercerización, Regulaciones, Procesos de Negocio BPM Requiere SOMA IT Flexible Ambiente operacional On Demand Service-oriented modeling and architecture (SOMA) SOMA refers to the more general domain of service modeling necessary to design and create SOA. SOMA covers a broader scope and implements service-oriented analysis and design (SOAD) through the identification, specification and realization of services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services. SOMA includes an analysis and design method that extends traditional object-oriented and component-based analysis and design methods to include concerns relevant to and supporting SOA. It consists of three major phases of identification, specific and realization of the three main elements of SOA, namely, services, components that realize those services (aka service components) and flows that can be used to compose services. SOMA is an end-to-end SOA Method for the identification, specification, realization and implementation of services (including information services), components, flows (processes/composition). SOMA builds on current techniques in areas such as domain analysis, functional areas grouping, variability-oriented analysis (VOA) process modeling, component-based development, object-oriented analysis and design and use case modeling. SOMA introduces new techniques such as goal-service modeling, service model creation and a service litmus test to help determine the granularity of a service. Servicios SOA Arquitectura orientada a servicio (SOA) Desarrollo Infraestructura Gestión Desarrollo de software Gestión de la infraestructura Integración Fuente: IBM Business Value Institute 2005

26 Distinct Value … Regardless of Where You Choose to Engage
Value to Business Greater agility in specific, departmental business areas Optimization and innovation across end-to-end business processes Business model innovation to support the Globally Integrated Enterprise Predictive business automatically responding to market forces Coordination across lines of business Enterprise-wide organizational cooperation Enact significant shifts without direct IT involvement Scope Collaboration within a line of business Foundational Extend End-to-End Transform Adapt Dynamically Value to IT Main Point: Go into greater detail about what each path of Smart SOA is all about This continuum is not a maturity model. It's not something that has a starting point and a destination. There is distinct value at every path regardless of where you choose to engage. On the basic side, Foundational SOA can deliver value through focused, proven, high ROI project. Usually narrowly defined projects for very specific needs. Scope is usually around a single application or within a single business unit. At this point, organizations will typically have completed less than five SOA projects and express less than ten percent of their functions as services. Typically less than five percent of these services are reused. Moving over to Extending End-to-End, organizations are typically more focused on applying the principles of SOA to the end-to-end businesses we discussed earlier that span a wide variety of applications, lines of business and even span borders and organizations. These are typically more central and higher-profile processes and users benefit from the broader ROI of innovating and optimizing these processes Scope is usually around a single process and can span one or more business units. At this point, organizations will typically have completed less than ten SOA projects and express less than 40 percent of their functions as services. Typically less than 20 percent of these services are reused. Moving over to Transform, organizations are typically looking to use SOA to help innovate their business models using IT for strategic advantage across their enter enterprise rather than an individual business process. They are looking at multiple processes that span multiple business units. At this point, organizations will typically have completed less than twenty SOA projects and express less than 80 percent of their functions as services. Typically less than 50 percent of these services are reused. At the far right at the Adapt Dynamically approach, we're looking at really a somewhat aspirational state. At this point, we can look forward to technology becoming invisible and business leaders being able to enact major shifts without direct IT involvement. While we've seen some organizations achieving bits and pieces of this, it's really something to strive for in general. This would encompass the extended enterprise, involve more than 20 completed SOA projects, express over eighty pecent of functions as services and reuse more than half of the services. End-to-end business process management to innovate and optimize IT for strategic advantage and business model innovation Technology becomes invisible Focused, proven, high-ROI projects % functions expressed as services <10% <40% <80% >80% % of services reused <5% <20% <50% >50% Based on 5700 customers using our SOA offerings

27 Global Business Services
Benefits of Service Oriented Architecture Reduce development time and cost - SOA services are easily reused and can be rapidly assembled into new, composite applications. Lower maintenance costs - Reusable services reduce the number and internal complexity of IT services. Higher quality services - Increased service reuse creates higher-quality services through multiple testing cycles from different service consumers. Lower integration costs - Standardized services know how to work together, enabling disparate applications to quickly and easily connect. Reduce risk - Fewer, reusable services provide greater control over corporate and IT governance policies and reduce the overall compliance risk. Loose coupling technology – The ability to model service independently of their execution environment and create messages that can be sent to any service. Division of responsibility – The ability to more easily allow business people to concentrate on business issues, technical people to concentrate on technology issues, and for both group to collaborate using the service contract. @ Copyright IBM Corporation 2007

28 Ejemplo: Influence of SOA in Siebel Application

29 Service Oriented Architecture & Siebel
Component Description Smart Client A set of front end client application. Business Process Each process is declaratively defined as an orchestration of services. The location of services is transparent to the applications, and the processes may cross applications. Various sections of a process may be implemented in different applications, each executed under the control of its own process controller, whether BPEL-compatible or custom. Application Service All application functions are modeled using service technology. All services—whether data services, business services, or integration services—follow the service paradigm. Data/Source Service At the logic level, all applications are peers as providers and consumers of services and data.

30 Overview of SOA Influence in Siebel Application
Service-oriented architecture (SOA) is the environment that supports the building of applications using service technology. Siebel order management is a composite application built following the discipline of SOA. SOA allows for sharing of business logic across multiple access channels, using data and application features wherever they reside. An SOA application must include the following: Component Smart Client Business Process Application Service Data/Source Service

31 Siebel – Order Management
Siebel Order Management is build upon Service Oriented Architecture principles, C/ OM business functions are encapsulated in well-defined services. Data is transfer between services as hierarchical documents ( Process Property). Siebel workflow process is used to invoke series of internal business services in order to implement business processes. Siebel C/OM Signals mechanism provides the service invocation framework. The C/OM Variable Maps mechanism defines, constructs, and persists the data passed to and from the services. Siebel C/OM business processes and business function can be exposed as stateless services to external application using Siebel ASI framework. Siebel already started focusing on SOA framework right from Siebel 7.5. They introduce Siebel web service functionality in this release with minimum capability. We can expose Siebel WF or Business Service as web service.

32 Siebel – the principles of SOA
We can create Siebel specific business processes and business functions by following the basic principles of SOA. Services should be independent. Services should only interact with other services. Services should be loosely coupled. Services should be accessible through standardized technologies (SOAP,XML,WSDL,HTTP and JMS etc., ) Service should provide reuse business functionality. Services are named to maximize consumability Services have well-chosen granularity Services are cohesive and complete

33 Siebel OOB Web services for Customer Order Management
Namespace Web Service ABOWebService AssetWebService CalculatePriceWS CatalogWebService ContactWebService ContextServiceWrapperService EligibilityCompatibility OrderWebService ProductConfigurator ProductRecommendation PromotionWebService QuoteAddItemsWS QuoteWebService These are the few OOB Web Service which can be exposed to external world for use. Siebel also provides a way to modify the OOB Web Service to fit the customer needs. While do this exercise we need to make sure all requirements of existing business processes in not neglected. Note : In order to use above OOB web services, you need to activate list of workflow processes. (Refer Siebel bookshelf)

34 El Reto: Lograr que las Personas, Procesos e Información trabajen juntos, con sinergia y alineados a los objetivos de negocios

35 SOA: Puntos de entrada Centrada en el negocio y enfocada en IT
1 2 3 5 4

36 Foco en el Negocio Puede empezar con el problema más critico y quedara habilitado para crecer con flexibilidad Facilita la interacción de individuos y procesos con niveles consistentes de servicio Entrega información confiable para llegar a conocer bien el negocio y posibilitar la innovación Obtener mayor eficiencia y efectividad por medio de la Innovación en el modelo de negocios Main Point: SOA is best considered in terms of a lifecycle. Think of this lifecycle comprehensively and approach it tactically focusing on the sections that provide the most value for you. Our customers have told us that they take a lifecycle approach to SOA. They start in what we are calling the Model phase by gathering business requirements, designing, simulating, and optimizing their desired business processes. That way, they can make sure they are setting the right steps in motion before further action is taken. Once they have optimized the business processes, they implement it by combining newly created and re-used existing services to form composite applications. The assets are then deployed into a secure and integrated environment taking advantage of specialized services that provide support for integrating people, processes and information. This level of integration helps ensure that all the key elements of your company are connected and working together. Once deployed, customers manage and monitor the composite applications and underlying resources from both an IT and a business perspective. Information gathered during the Manage phase is used to gain real-time insight into business processes enabling better business decisions and feeding information back into the lifecycle for continuous process improvement. Underpinning all of these lifecycle stages is governance which provide guidance and oversight for the SOA project. “Escoger procesos de negocios que el negocio reconozca de manera clara como claves — procesos para los cuales el negocio necesita contar con una visión clara, control, agudeza y flexibilidad end-to end”

37 SOA Begins By Working Within Your Existing Environment Business Centric and IT Focused Entry Points to SOA 5 4

38 Arquitectura de referencia SOA
Innovación de Negocios & Servicios de optimización Servicios de Procesos Servicios de Asociados Servicios de Aplicaciones del Negocio Servicios de Acceso Monitorea, administra y asegura los servicios, aplicaciones y recursos Facilita la toma de Decisiones mediante la información del negocio en tiempo real Coordina y automatiza los procesos de Negocios Conectarse con Asociados de Negocios Construir un ambiente de servicios robusto, escalable y seguro Facilitar la interacción entre la Información existente y las aplicaciones existentes Servicios de Administración TI El verdadero control sobre su negocio BPM Manages diverse data and content in a unified manner Innovación de Negocios & Servicios de optimización Servicios de Desarrollo Servicios de Interacción Servicios de Procesos Servicios de Información Servicios de Asociados Servicios de Aplicaciones del Negocio Servicios de Acceso Un ambiente integrado, para el diseño y construcción de las soluciones Monitorea, administra y asegura los servicios, aplicaciones y recursos Facilita la toma de Decisiones mediante la información del negocio en tiempo real Habilita la colaboración entre personas, procesos & Información Coordina y automatiza los procesos de Negocios Conectarse con Asociados de Negocios Construir un ambiente de servicios robusto, escalable y seguro Facilitar la interacción entre la Información existente y las aplicaciones existentes ESB Facilita la comunicación Entre los servicios Servicios de Administración TI Servicios de Infraestructura Optimizarlo por medio de la Disponibilidad y Rendimiento Administrar diversas fuentes de Datos y Contenidos de manera unificada Servicios de Interacción Habilita la colaboración entre personas, procesos & Información Colaboración La Cara visible de SOA Como manejar el ciclo completo de desarrollo SOA Servicios de Desarrollo Un ambiente integrado, para el diseño y construcción de las soluciones Servicios de Información Innovación de Negocios & Servicios de optimización Facilita la toma de Decisiones mediante la información del negocio en tiempo real Administrar diversas fuentes de Datos y Contenidos de manera unificada Servicios de Acceso Facilitar la interacción entre la Información existente y las aplicaciones existentes La información como Servicio Servicios de Información Monitorea, administra y asegura los servicios, aplicaciones y recursos Servicios de Administración TI Servicios de Infraestructura Optimizarlo por medio de la Disponibilidad y Rendimiento Administrar diversas fuentes de Datos y Contenidos de manera unificada IT Service Management: Administrando una infraestructura orientada al Servicio SOA nos proporciona una visión Tecnológica centrada en Necesidades de Negocios

39 Arquitectura de Referencia (Funcional)
Business Dashboard Info Assets Apps & Innovación de Negocios & Optimización de Servicios Servicios de Desarrollo Servicios de Interacción Servicios de Procesos Servicios de Información Servicios de Asociados Servicios de App de Negocios Servicios de Acceso Integrated environment for design and creation of solution assets Manage and secure services, applications & resources Facilitar la toma de decisiones con información de negocios a tiempo real. Enables collaboration between people, processes & information Orchestrate and automate business processes Manages diverse data in a unified manner Connect with trading partners Build on a robust, scaleable, and secure services environment Facilitates interactions with existing information and application assets ESB Facilitates communication between services Administración de Servicios IT Servicios de Infrastructura Optimizes throughput, availability and performance Portal Correo Colaboración Gestión Documental (ECM) Servicios datos - MDM DB Access Empleados Socios de negocios Clientes Otras Community Manager New Apps EJBs Siebel Adapter CICS Access Consola de Adminis de IT

40

41 An example to illustrate SOA Framework in Siebel application
Global Business Services An example to illustrate SOA Framework in Siebel application @ Copyright IBM Corporation 2007

42 Global Business Services
Example - Case Study Business context The Business Problems being solved Need to increase revenue by improving order processing time In order to attract and retain customer base, must continuously refine and enhance its services, while keeping prices low. Increase the speed and agility in delivering new business services Streamline processes to reduce operating costs. Enable easy and flexible integration with Legacy Order management System from multiple delivery channels Isolate External Systems from changes and evolution of Legacy Order Management System Enable Flexibility Pricing to quickly respond to changing market conditions Key Objective: To build a flexible infrastructure & application solution that serves as an enabler for subsequent business-driven projects. @ Copyright IBM Corporation 2007

43 Example – Functional Scenario
Global Business Services Example – Functional Scenario In a typical order management business scenario, an order is entered into the CRM system and fulfillment occurs through the back-office ERP. In this example, we are using Siebel as the front-office application to manage marketing, sales, and service operations and Oracle E-Business suite for ERP (order management, inventory, and financials). The business process considered here is the Quote-to-Order process. One part of this business process—quote and order entry—is executed in the CRM system, while order fulfillment is performed in the ERP system. To optimize internal operations, the entire cross-application Quote-to-Order business process needs to be automated. @ Copyright IBM Corporation 2007

44 Process Scenario - Example
Global Business Services Process Scenario - Example Sales Orders Creation in Siebel. A sales order in Siebel can be created either by converting a quote into a sales order or directly through the Order Capture Screen. After creating order in Siebel , the system will automatically change the status to ‘In Progress’. This Sales Order Process will invoke and submit the order information to the Integration Process. This in turn will invoke Business process thru Siebel Workflow process. ( Oracle BPEL Process Manager, IBM BPEL4WS etc..) Siebel Workflow process converts the messages data into the format required by Oracle ERP Order Management module. The sales order creation takes place in the Oracle ERP application, and the order acknowledgment is send to Seibel. ATP Check in Oracle ERP During the order creation process the salesperson may wish to check the availability of the material to promise the delivery date. Siebel CRM will make a synchronous call to ERP application to get the on-hand available quantity using the Item/Product Availability inquiry component. Siebel Workflow Process will transmit this ATP Check request to Oracle ERP. Oracle ERP will check the available quantity for the specific item from the inventory. It will send back the relevant availability details to Siebel Workflow Process. Siebel Workflow Process will invoke update process in Siebel CRM. Based on this operation, the customer will be promised the actual delivery date. Order status updates from Oracle ERP to Siebel CRM After propagating the sales order to ERP application, the order is booked in ERP, the acknowledgment is sent to Siebel where the order status will be changed to “Booked". Oracle ERP will publish the changes to the order status from time to time. This status from ERP is mapped to equivalent status in CRM. @ Copyright IBM Corporation 2007

45 Order Management Service Diagram
Global Business Services Order Management Service Diagram Source: SOA for dummies @ Copyright IBM Corporation 2007

46 Global Business Services
Example – How to develop and implement this example in Siebel application. We are going to discuss about all web service that can be reused or created in Siebel application to support our example scenario. Create / reuse a workflow process to query and fetch order data information from Siebel application. Convert above workflow process as Order Query web into Siebel outbound web service. Expose Siebel Order Query web service. Consume ERP Order creation web service. Consume ATP web service from external system. ( Synch Call ) Consume pricing web Service from external system. ( Synch Call ) Consume customer validation web service from external system into Siebel Application. ( Synch call) Create and Expose Product validation web service. Consume Shipping web service from external system. Note : Above external web service can be import into Siebel application. These web services can be chained as business processes by using Siebel workflow process or we can also use BPM application to consume all web service and then we can create business processes by using BPEL. ( Business Processes Execution Language ) @ Copyright IBM Corporation 2007

47 SOA to align business and information technology
Global Business Services SOA to align business and information technology Enterprise Goal Need to increase revenue by improving order processing time Business Process Layer (BPM) Order Creation Services Order Service Customer Service Reporting Service Inventory Service Pricing Service Application Layer Siebel Oracle SAP Custom SAS Technology Layer Windows Unix CICS OS/390 Java/J2EE MQ RDBMS @ Copyright IBM Corporation 2007

48 Reusable Services Logistics Team Call Center Agent Sales Agent
Global Business Services Reusable Services Sales Agent Logistics Team Call Center Agent Customer Point of Sales Product Configuration Inventory Check ATP Tax Calculation Pricing Pricing Pricing Service ATP Service Tax Calculation Service Applications Services Applications Externalizing common functions as “services” allows for code re-use, thereby saving on development investment and maintenance expenses. ü Infrastructure However, this creates an important dependency; if the ‘service’ is not working, the applications cannot function X This forces us to re-examine what we call “applications” and what we call “infrastructure”! Oracle ERP SAP External @ Copyright IBM Corporation 2007

49 Business processes flow for order
Global Business Services Business processes flow for order Begin Input Order ATP Ack Order Ship Delivery Send Invoice End Validate Supplier Confirm Order Cancel Note: Above business processes can be designed and executed in Siebel workflow process or BPM application. (BPEL ) @ Copyright IBM Corporation 2007

50 SOA Messaging Architecture
Global Business Services SOA Messaging Architecture All definitions, descriptions, and messages are based on XML Service Broker Connects to Searches UDDI Registry Requests Register Order Processing Adapter Order Creation Adapter Message SOAP Reads and Uses Web Service Description Provides Provides Provides Pricing Adapter Customer Validation Adapter Inventory Checking Adapter Shipping Delivery Adapter Product Adapter @ Copyright IBM Corporation 2007

51 Business Partner Invoking backend service
Global Business Services Business Partner Invoking backend service Convert Input XML into Target XML Monitor Service Process & Log input information Route output information to target specific location XML Input Gateway Transform Monitor Route @ Copyright IBM Corporation 2007

52 ESB Scenarios DMZ DMZ Trusted Untrusted Global Business Services
Pricing Product ERP Order System DMZ Trusted Untrusted XML/MQ Inventory SOAP/HTTP Customer Validation XI50 XI50 Business Partner Shipping Advantages: Speed Simplicity Complex fault recovery Complex service interactions w/ recovery Process Server / WESB Adapter Service Registry & Repository Siebel IBM Tivoli Monitoring Server @ Copyright IBM Corporation 2007

53 Global Business Services
Future Focus …. SOA Governance. SOA Security. Exceptional Handling. SOX Issue. DataPower. XLST. @ Copyright IBM Corporation 2007

54 Global Business Services
Conclusion The software architecture defines which software components to use and how those components interact with each other. Sounds pretty simple when we put it that way, but we’re not going to hide the ugly truth from you: Creating a service oriented architecture takes thought, patience, planning, and time. We call it a journey, and depending on the size and scope of an organization, it may be a journey of years or even a decade. But you can start seeing returns on your SOA investment very quickly, without having to rewrite all your software. Siebel Application helps us to quickly expose an existing or custom web services to enterprise world. Siebel application provides powerful tools and methods to develop SOA based solution to support an enterprise to create more flexible solutions based on market needs. @ Copyright IBM Corporation 2007