Aspectos Avanzados de la Tecnología de Objetos

1. Aspectos Avanzados de laTecnología de Objetos 7. Tópicos avanzados Dr. Juan José Aranda Aboy

2. Contenidos • Concurrencia. • Patrones utilizados para resolver la Concurrencia • Distribución: CORBA y RMI. • Patrones utilizados para resolver la Distribución • Patrones utilizados para resolver la Presentación • Desarrollo bajo el modelo cliente - servidor e Internet. Dr. Juan José Aranda Aboy

3. Objetivos específicos • Conocer, describir y aplicar apropiadamente los patrones utilizados para resolver la concurrencia y la distribución. • Explicar las características de CORBA y Java RMI, comparándoles adecuadamente. • Utilizar el modelo Cliente – Servidor para construir sistemas. Dr. Juan José Aranda Aboy

4. Patrones utilizados para resolver el Modelo de Negocio y su Acceso • Un modelo del proceso de negocios (Business Process Model -BPM) es una herramienta para modelado de procesos que suministra una descripción cercana de la lógica del negocio y reglas del negocio desde el punto de vista de los asociados en dicho negocio (a business partner's point of view). • Un BPM utiliza un diagrama que muestra las interacciones entre procesos, flujos, mensajes y protocolos de colaboración desde uno o varios puntos iniciales a varios puntos finales potenciales. • Un BPM puede compararse con un mercado donde se intercambian datos ó servicios. • Usualmente es el resultado de una necesidad surgida del negocio ó de una oportunidad (arises from a compelling business need or opportunity). Dr. Juan José Aranda Aboy

5. Definición de proceso • Un proceso se define como un conjunto de tareas, actividades o acciones interrelacionadas entre sí que, a partir de una o varias entradas de información, materiales o de salidas de otros procesos, dan lugar a una o varias salidas también de materiales (productos) o información con un valor añadido. • Hay tres tipos de actividades en un proceso: • Valor agregado: Aquellas que transforman los datos e insumos para crear información y productos o servicios para el cliente. • Traspaso: Aquellas en las que se entrega de manera interdepartamental o externa la información y productos. • Control: Aquellas que permiten que las actividades de traspaso se lleven a cabo con calidad tiempo y costo establecido. Dr. Juan José Aranda Aboy

6. Proceso de negocio • es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Cada proceso de negocio tiene sus entradas, funciones y salidas. Las entradas son requisitos que deben tenerse antes de que una función pueda ser aplicada. Cuando una función es aplicada a las entradas de un método, tendremos ciertas salidas resultantes. • es una colección de actividades estructurales relacionadas que producen un valor para la organización, sus inversores o sus clientes. Es, por ejemplo, el proceso a través del que una organización realiza sus servicios a sus clientes. • puede ser parte de un proceso mayor que lo abarque o bien puede incluir otros procesos de negocio que deban ser incluidos en su función. En este contexto un proceso de negocio puede ser visto a varios niveles de granularidad. El enlace entre procesos de negocio y generación de valor lleva a algunos practicantes a ver los procesos de negocio como los flujos de trabajo que se efectúan las tareas de una organización. • es usualmente el resultado de una Reingeniería de Procesos. El modelado de procesos es usado para capturar, documentar y rediseñar procesos de negocio. Dr. Juan José Aranda Aboy

7. Los procesos de negocio pueden ser vistos como un recetario para hacer funcionar un negocio y alcanzar las metas definidas en la estrategia de negocio de la empresa. • Hay dos tipos principales de procesos de negocio: • Procesos centrales – Estos procesos dan el valor al cliente, son la parte principal del negocio. Por ejemplo, “Repartir mercancías” • Procesos de soporte – Estos procesos dan soporte a los procesos centrales. Por ejemplo, “contabilidad”, “Servicio técnico”. • Los procesos de negocio consisten en subprocesos, decisiones y actividades. • Un subproceso es parte un proceso de mayor nivel que tiene su propia meta, propietario, entradas y salidas. • Las actividades son partes de los procesos de negocio que no incluyen ninguna toma de decisión ni vale la pena descomponer (aunque ello sea posible). Por ejemplo, “Responde al teléfono”, “Haz una factura” • perspectiva en torno a los procesos que son realizados por un trabajo en equipo teniendo en cuenta al cliente el cual fija las ritmos de los resultados. • Esto facilita el acercamiento y el acuerdo con los clientes, mejora la motivación de los empleados y existe una mayor facilidad para responder a cambios en el contexto. • Para aplicar los procesos se deben tener claras las tareas, una estructura jerárquica y una tendencia a la interacción y comunicación vertical. Dr. Juan José Aranda Aboy

8. Reingeniería de Procesos • Se define como “la reconcepción fundamental y el rediseño radical de los procesos de negocios para lograr mejoras dramáticas en medidas de desempeño tales como en costos, calidad, servicio y rapidez” • se trata de una reconcepción fundamental y una visión holística de una organización. Preguntas como: ¿por qué hacemos lo que hacemos? y ¿por qué lo hacemos como lo hacemos? • es radical hasta cierto punto, ya que busca llegar a la raíz de las cosas: no se trata solamente de mejorar los procesos, sino y principalmente, busca reinventarlos. • crea cambios directos y radicales que requieren unas circunstancias en la organización para adoptarse con éxito: • Sensibilización al cambio. • Planeación estratégica. • Automatización. • Gestión de Calidad Total. • Reestructuración Organizacional. • Mejora Continua. • Valores compartidos. • Perspectiva individual. • Comportamiento en el lugar de trabajo. • Resultados finales. Dr. Juan José Aranda Aboy

9. Etapas de la reingenieria Pueden ser: • Identificación de los procesos estratégicos y operativos existentes o necesarios, y creación de un mapa (un modelo) de dichos procesos. • Jerarquización del mapa de procesos para su rediseño, y determinación de los procesos clave, aquellos que se abordarán primero o con mayor interés. • Desarrollo de la visión de los nuevos procesos mejorados. • Reingeniería (creación y rediseño) de procesos, realizada por consultores externos, especialistas internos, o una mezcla de ambos. • Preparación y prueba de los nuevos procesos (procesos pilotos) . • Procesos posteriores de mejora continua. Dr. Juan José Aranda Aboy

10. Business Process Management • Disciplina empresarial cuyo objetivo es mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio (BPR), que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua. • Como su nombre lo sugiere Business Process Management (BPM) se enfoca en la administración de los procesos del negocio. • A través del modelado de las actividades y procesos logramos un mejor entendimiento del negocio y muchas veces esto presenta la oportunidad de mejorarlos. La automatización de los procesos reduce errores, asegurando que los mismos se comporten siempre de la misma manera y dando elementos que permitan visualizar el estado de los mismos. La administración de los procesos nos permite asegurarnos de que los mismos estén ejecutándose eficientemente y obtener información que luego puede ser usada para mejorarlos. Es a través de la información que se obtiene de la ejecución diaria de los procesos que se puede identificar posibles ineficiencias en los mismos y de esta forma optimizarlos. • Para soportar esta estrategia es necesario contar con un conjunto de herramientas que den el soporte necesario para cumplir con el ciclo de vida de BPM. Este conjunto de herramientas son llamadas Business Process Management System y con ellas se construyen aplicaciones BPM. Dr. Juan José Aranda Aboy

11. Motivaciones • Existen diversos motivos que mueven la gestión de Procesos de Negocio (BPM), dichos motivos son: • Extensión del programa institucional de calidad • Cumplimiento de legislaciones • Crear nuevos y mejores procesos • Entender que se está haciendo bien o mal a través de la compresión de los procesos • Documentar procesos para outsourcing y definición de SLA (Service Level Agreement) • Automatización de procesos • Crear y mantener las cadenas de valor Dr. Juan José Aranda Aboy

12. Reglas de negocio • Reglas de negocio es la colección de políticas y restricciones de negocio de una organización. • Un ejemplo de reglas de negocio sería: • "Un cliente al que facturamos más de 10.000€ al año es un cliente de tipo A" • "A los clientes de tipo A les aplicamos un descuento del 10% en pedidos superiores a 3.000€" • Las organizaciones funcionan siguiendo múltiples reglas de negocio, explícitas o tácitas, que están embebidas en procesos, aplicaciones informáticas, documentos, etc... Pueden residir en la cabeza de algunas personas o en el código fuente de programas informáticos. • En los últimos años se viene observando una tendencia a gestionar de forma sistemática y centralizada las reglas de negocio, de forma que sea fácil y sencillo consultarlas, entenderlas, utilizarlas, cambiarlas, etc... Para ello se puede utilizar un motor de reglas de negocio. Dr. Juan José Aranda Aboy

13. Business process modeling • The term process model is used in different contexts. For example, in Business process modeling the enterprise process model is often referred to as the business process model. The goals of a process model are: • To be Descriptive • Track what actually happens during a process. • Takes the point of view of an external observer who looks at the way a process has been performed and determines the improvements that have to be made to make it perform more effectively or efficiently. • Prescriptive • Defines the desired processes and how they should/could/might be performed. • Lays down rules, guidelines, and behavior patterns which, if followed, would lead to the desired process performance. They can range from strict enforcement to flexible guidance. • Explanatory • Provides explanations about the rationale of processes. • Explore and evaluate the several possible courses of action based on rational arguments. • Establish an explicit link between processes and the requirements that the model needs to fulfill. Dr. Juan José Aranda Aboy

14. Business Process Modeling(also known as Business Process Discovery, BPD) is the activity of representing both the current ("as is") and future ("to be") processes of an enterprise, so that the current process may be analyzed and improved. BPM is typically performed by business analysts and managers who are seeking to improve process efficiency and quality. The process improvements identified by BPM may or may not require IT involvement, although that is a common driver for the need to model a business process, by creating a process master. • Change management programs are typically involved to put the improved business processes into practice. With advances in technology from large platform vendors, the vision of BPM models becoming fully executable (and capable of simulations and round-trip engineering) is coming closer to reality every day. • Business Process Modeling plays an important role in the business process management (BPM) discipline. Since both Business Process Modeling and Business Process Management share the same acronym (BPM), these activities are sometimes confused with each other. Dr. Juan José Aranda Aboy

15. Modeling language standards that are used for BPM include Business Process Modeling Notation (BPMN), Business Process Execution Language (BPEL), Unified Modeling Language (UML), and Web Services Choreography Description Language (WS-CDL).[14] Other technologies related to business process modeling include model-driven architecture and service-oriented architecture. • BPM addresses the process aspects of an Enterprise Business Architecture, leading to an all encompassing Enterprise Architecture. The relationships of a business processes in the context of the rest of the enterprise systems (e.g., data architecture, organizational structure, strategies, etc.) create greater capabilities when analyzing and planning enterprise changes. For example, during a corporate merger it is important to understand the processes of both companies in detail so that management can correctly and efficiently identify and eliminate redundancies in operations. Business Process Modeling has always been a key aspect of business process reengineering (BPR) and continuous improvement approaches, such as Six Sigma. BPM tools such as Lombardi, Holosofx, and TIBCO are used in order to represent a business process, to run a simulation of the process and for communication purposes. Dr. Juan José Aranda Aboy

16. Técnicas • There are different styles for representing processes: "scripts," "programs," and "hypertext." • Process scripts are interactively used by humans as against process programs which are enacted by a machine. They support non determinism whereas process programs can, at best, support process deviation under pre-defined constraints. • The hypertext style of process representation is a network of links between the different aspects of a process, such as product parts, decisions, arguments, issues, etc. • Scripts and programs are two styles which may be applicable to prescriptive purposes whereas hypertext is well suited to descriptive and explanatory purposes. Strict enforcement of the prescriptive purpose can clearly be represented in process programs whereas flexible guidance requires the process model to be represented in process scripts. • Descriptive and explanatory purposes require the establishment of relationships between different elements of a process trace. These relationships are well articulated as hypertext links. Dr. Juan José Aranda Aboy

17. The Business Process Model offers the following views that you design using the appropriate process language: Dr. Juan José Aranda Aboy

18. Objects in a BPM (_) • Package • Used to organize elements into groups. Not available for sub-process diagrams as you cannot create packages within sub-process diagrams • Organization unit • Element that hosts or implements processes and resources. It can be a company, a system, a service, an organization, a user or a role. It can also represent business partners for processes • Message format — Definition of data exchanged between processes • Process • Task to perform • Composite process — Complex process decomposed to be further detailed • Start • Starting point of the processes described in the process diagram • End • Termination point of the processes described in the process diagram Dr. Juan José Aranda Aboy

19. Objects in a BPM (_) • Decision • Decision to take when several flow paths are possible. Only one path will be triggered at execution time • Synchronization • Enables synchronization of flows between two or more concurrent actions or allows the design of a split • Flow • Transition between processes, starts, ends, decisions or synchronizations • Resource • Storage unit of abstract data circulating within the model, which is accessed by a process to perform actions • Resource flow • Access of a process to a resource • Data — Defines the type of information exchanged between business processes • Role association • Unidirectional relationship that designs a link between objects Dr. Juan José Aranda Aboy

20. Objects in a BPM (_) • Message part — Portion of the WSDL (Web Services Description Language) message • Top-level process — Global service that does not belong to a graph but describes its behavior in a sub-graph • Service provider — Object that gathers a set of service interfaces, for which it represents a namespace • Service interface — Object that gathers a set of operations, for which it represents a namespace • Operation — Implementation for an atomic process (activity) • Data transformation • Used to copy data from one variable to another • Variable — Data container local to a process • Correlation — Ordered list of variables • Event — Manages interruptions in the normal execution of the process Dr. Juan José Aranda Aboy

21. Business Process Modeling Notation • The Business Process Modeling Notation (BPMN) is a standardized graphical notation for drawing business processes in a workflow. BPMN was developed by Business Process Management Initiative (BPMI), and is now being maintained by the Object Management Group since the two organizations merged in 2005. • The primary goal of BPMN is to provide a standard notation that is readily understandable by all business stakeholders. These business stakeholders include the business analysts who create and refine the processes, the technical developers responsible for implementing the processes, and the business managers who monitor and manage the processes. Consequently BPMN is intended to serve as common language to bridge the communication gap that frequently occurs between business process design and implementation. • Currently, there are scores of business process modeling languages, tools and methodologies. The adoption of BPMN standard notation will help unify the expression of basic business process concepts (e.g., public and private processes, choreographies) as well as advanced modeling concepts (e.g., exception handling, transaction compensation). Dr. Juan José Aranda Aboy

22. Business Process Execution Language (BPEL) • is a business process modeling language that is executable. • The origins of BPEL can be traced to WSFL and XLANG. • It is serialized in XML and aims to enable programming in the large. • The concepts of programming in the large and programming in the small distinguish between two aspects of writing the type of long-running asynchronous processes that one typically sees in business processes. Dr. Juan José Aranda Aboy

23. BPEL4WS • The Business Process Execution Language for Web Services (BPEL4WS) provides an XML notation and semantics for specifying business process behavior based on Web Services. • A BPEL4WS process is defined in terms of its interactions with partners. A partner may provide services to the process, require services from the process, or participate in a two-way interaction with the process. Dr. Juan José Aranda Aboy

24. When to work with BPEL4WS? • You define a BPM with the BPEL4WS process language when you need to implement with the BPEL4WS standard language in order to share your business process model. Dr. Juan José Aranda Aboy

25. ¿Qué es SOA? • it is an architecture that relies on service-orientation as its fundamental design principle. Service-orientation describes an architecture that uses loosely coupledservices to support the requirements of business processes and users. • Resources on a network[1] in a SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.[2] • These concepts can be applied to business, software and other types of producer/consumer systems. Dr. Juan José Aranda Aboy

26. SOA is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). OASIS (the Organization for the Advancement of Structured Information Standards) defines SOA as the following: • A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. • There are multiple definitions of SOA, the OASIS group and the Open Group have created formal definition with depth which can be applied to both the technology and business domains. Dr. Juan José Aranda Aboy

27. Why SOA? • The main drivers for SOA adoption are that it links computational resources and promotes their reuse. • Enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditions[5] . • This style of architecture promotes reuse at the macro(service) level rather than micro(objects) level. It can also simplify interconnection to - and usage of - existing IT (legacy) assets. • In some respects, SOA can be considered an architectural evolution rather than a revolution and captures many of the best practices of previous software architectures. • In communications systems, for example, there has been little development of solutions that use truly static bindings to talk to other equipment in the network. • By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces. • SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services Dr. Juan José Aranda Aboy

28. SOA guiding principles • Reuse, granularity, modularity, composability, componentization, and interoperability • Compliance to standards (both common and industry-specific) • Services identification and categorization, provisioning and delivery, and monitoring and tracking Dr. Juan José Aranda Aboy

29. The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design: • Service Encapsulation • Service Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other • Service contract - Services adhere to a communications agreement, as defined collectively by one or more service description documents • Service abstraction - Beyond what is described in the service contract, services hide logic from the outside world • Service reusability - Logic is divided into services with the intention of promoting reuse • Service composability - Collections of services can be coordinated and assembled to form composite services • Service autonomy – Services have control over the logic they encapsulate • Service optimization – All else equal, high-quality services are generally considered preferable to low-quality ones • Service discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms Dr. Juan José Aranda Aboy

30. Service-oriented design and development • The modelling and design methodology for SOA applications has become known by the terms service-oriented analysis and design and SOAD. • SOAD is a design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer. Dr. Juan José Aranda Aboy

31. SOA is a logical executable process language that allows you to orchestrate your processes without being linked to any platform or language. It belongs to the Service Orchestration family. • The SOA process language is very close to BPEL4WS, except that: • · It has no generation and reverse functions • · Any type of operation can be attached to a process (BPEL4WS only supports One-Way and Request-Response operations on processes) • · No correlation can be defined for sent messages • An SOA BPM is a model that allows you to assemble software components that are designed by a WSDL. Therefore, you can import WSDL files in an SOA BPM. Dr. Juan José Aranda Aboy

32. Conceptual model of a SOA architectural style Dr. Juan José Aranda Aboy

33. The architectural style and principles • The architecture style defining a SOA describes a set of patterns and guidelines for creating loosely coupled, business-aligned services that, because of the separation of concerns between description, implementation, and binding, provide unprecedented flexibility in responsiveness to new business threats and opportunities. • A SOA is an enterprise-scale IT architecture for linking resources on demand. In a SOA, resources are made available to participants in a value net, enterprise, line of business (typically spanning multiple applications within an enterprise or across multiple enterprises). It consists of a set of business-aligned IT services that collectively fulfill an organization’s business processes and goals. You can choreograph these services into composite applications and invoke them through standard protocols, as shown in Figure 2 below. • A service is a software resource (discoverable) with an externalized service description. This service description is available for searching, binding, and invocation by a service consumer. The service provider realizes the service description implementation and also delivers the quality of service requirements to the service consumer. Services should ideally be governed by declarative policies and thus support a dynamically re-configurable architectural style. Dr. Juan José Aranda Aboy

34. In order to migrate to a SOA, you need some additional elements that go beyond service modeling. These include: • Adoption and maturity models. Where is your enterprise at in the relative scale of maturity in the adoption of SOA and Web Services? Every different level of adoption has its own unique needs. • Assessments. Do you have some pilots? Have you dabbled into Web services? How good is your resulting architecture? Should you keep going in the same direction? Will this scale to an enterprise SOA? Have you considered everything you need to consider? • Strategy and planning activities. How do you plan to migrate to a SOA? What are the steps, tools, methods, technologies, standards, and training you need to take into account? What is your roadmap and vision, and how do you get there? What’s the plan? • Governance. Should existing API or capability become a service? If not, which ones are eligible? Every service should be created with the intent to bring value to the business in some way. How do you manage this process without getting in the way? • Implementation of best-practices. What are some tried and tested ways of implementing security, ensuring performance, compliance with standards for interoperability, designing for change? • In addition to identification, specification, and realization described in this article, the service-oriented modeling approach includes the techniques required for deployment, monitoring, management, and governance required to support the full SOA life cycle. The above discussions on migration to SOA and the additional activities after realization deserve an article of their own, which I will get to in a subsequent column in this series. For now, let’s assume that you scoped the project and decided where to focus on: a focal point for transformation of existing systems or services to a new set of systems and services has been defined. You can now start service-oriented modeling to build your service-oriented architecture. Dr. Juan José Aranda Aboy

35. Layers of SOA Dr. Juan José Aranda Aboy

36. Service-oriented modeling and architecture (SOMA) • IBM’s 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. • SOMA identifies services, component boundaries, flows, compositions, and information through complementary techniques which include domain decomposition, goal-service modeling and existing asset analysis. Dr. Juan José Aranda Aboy

37. Activities of service-oriented modeling Dr. Juan José Aranda Aboy

38. shows the activities that are typically conducted by each of the roles of provider and consumer. Note that the provider’s activities are a superset of the consumer’s activities (for example, the provider would also be concerned with service identification, categorization, and so forth). In many cases, the differentiation of the roles comes from the fact that the consumers specify the services they want, often search for it, and once they are convinced of the match between the specification of the service they are looking for, and that provided by a service provider, they bind and invoke the service as needed. The provider, in turn, needs to publish the services they are willing to support; both in terms of functionality and most importantly in terms of the QoS that consumers will require. This implicit contract between consumer and provider might mature into an explicit contract in terms of SLAs; negotiated either electronically or through business and legal venues. Dr. Juan José Aranda Aboy

39. The service-oriented modeling and architecture method • The process of service-oriented modeling and architecture consists of three general steps: identification, specification and realization of services, components and flows (typically, choreography of services). Dr. Juan José Aranda Aboy

40. Business-driven development • Business-driven development is a methodology for developing IT solutions that directly satisfy business requirements. This is achieved by adopting a model-driven approach that starts with the business strategy, requirements and goals and then transforms them into an IT solution. The transformation is typically achieved by applying model transformations. Due to the alignment of the business layer and the IT layer, it is possible to propagate changes of the business (semi-)automatically to the IT systems. This leads to increased flexibility and shorter turnaround times when changing the business and adapting the IT systems. BDD shares these objectives with SOA and SOAD, which makes it one of the candidate methodologies for SOA design. SOMA and BDD can be used in combination. Dr. Juan José Aranda Aboy

41. When to work with Service Oriented Architecture? • When you decide to use the Service Oriented Architecture process language, you generally do not know yet which platform you are going to use to execute your processes. • However, SOA allows you to design the Web services orchestration by providing access to service providers, service interfaces and operations. Dr. Juan José Aranda Aboy

42. What is a Web service? • A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described, and discovered by XML artifacts, and supports direct interactions with other software applications using XML-based messages via Internet-based protocols. • Web services are software components that are developed using specific technologies from three primary technology categories: • An XML-based description format (for example, WSDL) • An application messaging protocol (for example, SOAP) • A collection or transport protocol (for example, HTTP) • In each of these categories, there are proprietary (vendor- or platform-specific) technologies as well as open (vendor- or platform-independent) technologies available. • Service-oriented applications include applications that MAY make use of Web service technologies such as SOAP but MAY NOT include a WSDL or other XML-based description. Such applications are considered Web-service-like but are not technically Web services. Dr. Juan José Aranda Aboy

43. Service-oriented application protocols Dr. Juan José Aranda Aboy

44. Enterprise Web services are Web services that do provide a WSDL description but MAY make use of proprietary application messaging or transport protocols. An example of such a service would be one that sends SOAP messages over IBM MQSeries using JMS. • Internet Web services are enterprise Web services that MUST only use open application messaging or transport protocols. An example of such a service would be one that sends OTA XML messages over HTTP. • XML Web services represent the very small subset of Internet Web services that MUST use the W3C's adopted XML-based messaging protocol over a narrow range of transport protocols. Specifically, XML Web services will only send SOAP messages, and only send them over HTTP, SMTP, or raw TCP/IP connections. Dr. Juan José Aranda Aboy

45. Domain of Web service protocols Dr. Juan José Aranda Aboy

46. Web services help to reduce complexity by encapsulating business processes into reusable components. • Web services help to improve interoperability by acting as a wrapper around legacy or platform-specific applications. • Web services can be composed together to perform higher-level business functions. • Web services help to hide back-end implementation details through the use of standardized or well-known interface definitions. • Web services enable just-in-time integration by promoting loose coupling and late binding. • Web services are platform and implementation neutral, thus promoting true interoperability. • Web services leverage existing established Internet standards. Dr. Juan José Aranda Aboy

47. Web Service Choreography • is a specification by the W3C defining a XML-based business process modeling language that describes collaboration protocols of cooperating Web Service participants, in which services act as peers, and interactions may be long-lived and stateful. • The underlying intuition behind the notion of choreography can be summarised as follows. “Dancers dance following a global scenario without a single point of control" • Web Service Choreography leverages the power of Web services to allow entities to create business processes that mirror today's dynamic and ever-changing business needs. Organisations can expose their application software and resources as Web services so that others can dynamically find and use them in their business processes. Creating a business process requires not only a clear definition of collaboration patterns of all its components but also a way of depicting standard B2B interactions. WS-Choreography addresses the vision of true Web service coordination and collaboration by: • Providing practical models for dynamic, reusable and scalable process compositions and choreography • Addressing technical completeness/correctness/executability issues • Enabling more dynamic, semi-automated composed processes • Enabling the incorporation of semantics Dr. Juan José Aranda Aboy

48. Orchestration • describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services. • It is often discussed as having an inherent intelligence (trait) or even implicitly autonomic control, but those are largely aspirations or analogies rather than technical descriptions. In reality, orchestration is largely the effect of automation or systems deploying elements of control theory. • This usage of orchestration is often discussed in the context of virtualization, provisioning, and dynamic datacenter topics. It is often used as a buzzword. • A somewhat different usage relates to the process of coordinating an exchange of information through web service interactions. (See also service-oriented architecture). Dr. Juan José Aranda Aboy

49. Ejemplos de orquestación • Oracle BPEL Process Manager provides a framework for easily designing, deploying, monitoring, and administering processes based on BPEL standards. BPEL Process Manager is the service orchestration solution on Oracle's SOA Suite. • Intervoice Media Exchange contains an orchestration engine that has been designed to initiate and manage media interactions. It is the industry's first commercially available product that has implemented State Chart eXtensible Markup Language (SCXML) as the framework for building complex multi-modal interactions. • TIBCO BusinessWorks is a very functional orchestration, integration and transformation tool that supports BPEL, Web Services, common integration activities and visual modeling of orchestration processes. • Microsoft BizTalk Server contains an orchestration engine often used for business process management (BPM), allowing developers to quickly orchestrate complex business processes involving multiple disparate systems. • NetBeans Enterprise Pack is an open-source SOA tool that contains BPEL visual designer and runtime that allow to easily orchestrate Web Services in a BPEL process, execute, test and debug the designed processes Dr. Juan José Aranda Aboy

50. SOA and web service protocols • SOA may be built on Web services standards (e.g., using SOAP) that have gained broad industry acceptance. These standards (also referred to as web service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, implement SOA using any service-based technology, such as Jini. • Service-oriented architecture is often defined as services exposed using the Web Services Protocol Stack[citation needed] . The base level of web services standards relevant to SOA includes the following: • XML - a markup language for describing data in message payloads in a document format • HTTP (or HTTPS) - request/response protocol between clients and servers used to transfer or convey information • SOAP - a protocol for exchanging XML-based messages over a computer network, normally using HTTP • XACML - a markup language for expressing access control rules and policies. • Web Services Description Language (WSDL) - XML-based service description that describes the public interface, protocol bindings and message formats required to interact with a web service • Universal Description, Discovery, and Integration (UDDI) - An XML-based registry to publish service descriptions (WSDL) and allow their discovery • Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba, Jini and REST. Dr. Juan José Aranda Aboy