Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of

Service-Oriented Architectures Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU

outline Review of SOA The IBM Rational Software Development Platform – The IBM Rational Unified Process for SOA Software Service Engineering Developing Service Oriented Product Lines

Introduction Service-oriented architecture (SOA) is an architectural style based on common principles and patterns These include Business Process Choreography and Enterprise Service Bus (ESB) They allow engineers to effectively organize and deploy executable business processes, as looselycoupled software services. SOA is based on domains that include business process management, distributed computing, enterprise application integration, and software architecture,

What is SOA? A Technical Perspective A Service Oriented Architecture is a collection of self-contained services that can communicate with each other. Key characteristics of services: loosely coupled coarse grained typically published & available for invocation on a Service Bus Defining services at a “business level” enables rapid composition of end-to-end business processes, delivering on the promise of greater IT flexibility and agility

SOA Elements Model This diagram from „Web Services Architecture“ shows internal and external elements of the SOA architecture. Action e.g. is not an externally visible element. Note the important roles of „policy“ and „semantics“

SOA v/s Traditional Architecture Calls for a Paradigm Shift Traditional Architecture Service Oriented Architecture Functionality Driven Process Oriented Designed to last Designed for change Long development cycles Iterative development Tightly Coupled Loosely Coupled Application Specific Heterogeneous Data Oriented Business Service Oriented But must be built on standards to enhance interoperability

Service-Oriented Architecture: Key Concepts Service A unit of business functionality that can be invoked over the network Web service A service that is called in a standard way, so anyone can use it without knowing its internals “Loosely coupled” When services are self-contained, and can be easily combined and disassembled, they are called loosely coupled. Service-Oriented Architecture A standards-based platform that lets you model, develop, find, and combine services into flexible business processes Orchestration & Combining and assembling services into a coherent business process – also known as business process management Choreography

A Map of SOA Components Registry and Repository Manage and monitor Security Web Portals Human Business Process Management (BPM) Enterprise Service Bus (ESB) Data Services Process Services Business Logic Orchestration System BPM Databases Systems of Record

Service Oriented Architecture (SOA) Style: The Enterprise Service Bus ESB Functions Invocation Synchronous and asynchronous transport protocols, service mapping (locating and binding) Routing Addressability, static/deterministic routing, content-based routing, policy-based routing Mediation Adapters, protocol transformation, service mapping Messaging Message processing, message transformation and message enhancement

Business Process Management BPM is a structured approach that models an enterprise's human and machine tasks and the interactions between them as processes Evolving from document management, workflow and enterprise application integration (EAI), a BPM system can monitor and analyze tasks

jBPM vision for BPM

BPEL example: Withdrawing and depositing services of the banking system logic

Custom Service 1 4 BPEL Service 3 Transformation Services 2 Custom Services 5 Sample ESB Transform Service BPEL and SOA Orchestration Routing Service Application Server Gateway Service Routing JCA JMS MDB Servlet SSB Portlet EJB Web J2EE Application Server

outline Review of SOA The IBM Rational Software Development Platform – The IBM Rational Unified Process for SOA Software Service Engineering Developing Service Oriented Product Lines

Model-Driven IBM SOA Foundation The IBM SOA Foundation is a modular, integrated, and open set of software, best practices, and patterns that support the complete SOA lifecycle.

Business-Driven Development for SOA The IBM Rational Software Development Platform

The IBM Rational Software Development Platform

The IBM Rational Unified Process

The IBM Rational Unified Process IBM Rational Unified Process, or RUP , is a configurable software development process platform that delivers proven best practices and a configurable architecture. – – The RUP Plug-In for SOA integrates support for serviceoriented architecture and service-oriented solutions into the RUP framework with SOA-specific concepts, guidelines, activities, artifacts, and tool mentors. The RUP Plug-In for WebSphere Business Modeler updates the Business Modeling discipline in RUP to leverage WebSphere Business Integration solutions and provide a unified approach for business modeling based on the essential capabilities of the IBM Rational Software Development Platform.

Transforming BPEL to UML

The IBM Rational Unified Process Top-Down development Rational Application Developer greatly simplifies the process of creating a Web service top-down based on requirements specifications and UML models. It automatically generate WSDL files that contain an XML schema to describe Web services, as well as skeleton JavaBeans or Enterprise JavaBean (EJB) files. It also includes an XML schema definition (XSD) editor for specifying message format.

The IBM Rational Unified Process Bottom-Up Development and Maintenance When working bottom-up from an existing set of Java classes or EJBs, Rational Application Developer can also automates much of the process of turning those components into a Web service. An easy to use Wizard will generate WSDL interfaces to methods in the Java Class, a SOAP deployment descriptor, and a Web page to be used as a test client to test interactions with the Web service. It also has J2EE Connector Architecture tools that let the developer easily integrate existing Enterprise Information Systems (EIS) such as CICS or IMS into their SOA solution.

outline Review of SOA The IBM Rational Software Development Platform – The IBM Rational Unified Process for SOA Software Service Engineering Developing Service Oriented Product Lines

Software Service Engineering Software service engineering entails the science and application of concepts, models, methods, and tools to – – – – define, design, develop/source, integrate, test, deploy, provision, operate, and evolve business-aligned and SOA-enabled software systems in a disciplined and routinely manner. Dagstuhl Seminar Proceedings 09021 Software Service Engineering http://drops.dagstuhl.de/opus/volltexte/2009/2041

Software Service Engineering In 2009, a seminar was organized around the following themes: 1. What are the novelties in Software Service Engineering (SSE)? 2. Top-down SSE starting from business architecture and mapping to Information Technology (IT) architecture. 3. Bottom-up SSE service composition and service enablement of existing (legacy) applications. 4. Recurring design issues in meet-in-the-middle service realization and patterns for them.

Software Service Engineering What is new in Software Service Engineering (SSE)? The current models, techniques, and concepts of SSE fall short in designing service-based systems that operate in open, dynamic, and uncontrolled environments. SSE involves combining various programming models and development paradigms, including event-driven and asynchronous programming, declarative programming, process modeling, and protocol design.

Software Service Engineering Top-down SSE starting from business architecture and mapping to Information Technology (IT) architecture Currently, many uncorrelated approaches and tools are available for developing SOAs on the one hand and for facilitating business (process) modeling on the other hand. It remains a challenge, however, how these methods and supporting toolsets can be seamlessly integrated to formulate a holistic approach in which software services can be identified, specified, realized, tested, deployed, managed, and evolved in a consistent and standardized fashion.

Software Service Engineering Bottom-up SSE service composition and service enablement of existing (legacy) applications Technology is moving towards ubiquitous Internet of services which combines software services with mobile devices, sensor networks, and social networks. This leads towards the concept of services everywhere fuelled by various very heterogeneous building blocks. There is a growing need for integrated approaches that cater for redeployment of legacy resources as services on clouds.

Software Service Engineering Architectural decision models and tools for meet-in-the-middle service realization Investigate how service design knowledge can be made reusable and how to identify, make, and enforce architectural decisions during SOA design. Architectural decision models complement pattern languages with domain-specific guidance and technology and asset-level refinements.

Software Service Engineering The observations conclusions were distilled into a set of defining SSE tenets, which fall in three complementary dimensions: architectural (platform), process, and engineering

Software Service Engineering The architectural (platform) tenets were compiled as follows: Service is the key design and runtime concept; a service is described by its contract. The services described in a contract are provided by endpoints (providers) and invoked by service requesters. Composition of services is facilitated by the service contract. Services communicate via document exchange using messaging technology. The service communication leverages protocols, which may support request coordination and support for conversations. Service virtualization supports location transparency.

Software Service Engineering From a process perspective, they identified the following process tenets: – Scoping (application boundaries)/context. Services should be designed in such a way that they routinely support business processes. This implies a scoping of processes so that their supporting software services are logically cohesive and loosely coupled, minimizing message, protocol, and context dependencies. Lifecycle, ownership, and versioning. The objective of SOA is to manage the lifecycle of a service starting from business goals over service definition, through deployment, execution, measurement, analysis, change, and redeployment.

Software Service Engineering process tenets (cont.): – Lifecycle, ownership, and versioning (cont.) Specifically, during their life services are subject to two broad classes of changes: low-impact changes versus intrusive changes. Intrusive changes include operational behavior changes and policy-induced changes, Low-impact changes demand a comprehensive service versioning strategy that may cater for forward and backward compatibility. A key issue regarding version management entails ownership of service data, logic, and transactions, especially in the context of processes that cross organizational boundaries.

Software Service Engineering process tenets (cont.): – – Reuse and variability. To cater for reuse in various process contexts, services should be designed as differentiated services that allow for multiple levels of service, depending on service request(er). Functional variability may also be built in by parameterization, delegation, or specialization/generalization. Governance and roles. Successful implementation and management of service-enabled processes is directly dependent on a strict service governance framework that clearly defines chains of responsibility, measurements to gauge efficacy, and controls to check on compliance.

Software Service Engineering Engineering tenets were established as follows: Technical federation 2. Dynamism 3. Organizational federation. 4. Boundaries. 5. Heterogeneity 6. Business-IT alignment. 7. Holistic approach. We will discuss the first 4 tenets 1.

Software Service Engineering Engineering tenets were established as follows: 1. Technical federation. SSE has to cater for service-enabled software applications that are highly distributed in nature with many asynchronous interactions between services. SSE has to deal with services that may be deployed on various runtime platforms, including mobile devices, computing clouds, and legacy systems, and have been developed in various programming paradigms – including, but not limited to, OOAD and CBD.

Software Service Engineering Engineering tenets (cont.) 2. Dynamism. A key tenet of SSE, dynamism regarding both the services that are aggregated into dynamic service compositions via late binding – possibly into agile service networks dynamism regarding the highly volatile context in which they operate. Firstly, dynamism implies that SSE methods, techniques, and tools have to deal with emergent properties and behavior of complex service networks, which may in fact be comprised of thousands of independent – yet cooperating – services.

Software Service Engineering Engineering tenets (cont.) – Dynamism. A key tenet of SSE, This signifies that software applications that have been designed in accordance with SSE typically exhibit unpredictable, non-linear and non-deterministic behavior. Dynamism puts requirements on virtually all layers of the typical SOA stack Late binding and loose coupling constitute two key principles for increasing the adaptability of service applications and for accommodating dynamic (re-)composition as well as (re-)configuration of services in a network.

Software Service Engineering Engineering tenets (cont.) – Dynamism. A key tenet of SSE SSE has to accommodate various styles of composition, fostering user-friendly enterprise service mash-ups as well as heavy-weight compositions of industry strength enterprise applications by service development professionals.

Software Service Engineering Engineering tenets (cont.) – 3. Organizational federation. Development and maintenance (operations) must be typically achieved in highly distributed organizational environments, involving multiple departments, units, enterprises, and governmental organizations. Development and maintenance of applications will be a collaborative effort, implying that in fact design, coding, deployment etc. will occur in networks of collaborative service clients and providers.

Software Service Engineering 4. Boundaries: Services developed with SSE methods or tools have to be endowed with clear and explicit boundaries. Services developed with SSE methods or tools have to be endowed with clear and explicit boundaries. In particular, SSE has to respect service contracts that capture goals and constraints (pre- and post-conditions and invariants), An intrinsic part of the service contract entails the service interface that clearly specifies the messages a service understands and the service endpoints that are available. Enriching the service interfaces with additional semantic information such as scenarios or behaviors allows a more robust and stable service composition

Software Service Engineering What is the most important challenge of SSE? 32 participants submitted an answer, the top scored answers are as follows: 1. Address the ‘open-world’ assumption: unforeseen clients, execution context, usage (16 points) 2. Bridging a modeling chasm: design/develop and delivery/execution (15) 3. ‘Open world assumption’: uncertainty (15) 4. IT-business alignment, adaptability (15) 5. Alignment of technical and business engineering for services (14) 6. New models and abstractions to represent and handle SOA dynamics (14) 7. To develop software without knowing in which context it is used (14)

outline Review of SOA The IBM Rational Software Development Platform – The IBM Rational Unified Process for SOA Software Service Engineering Developing Service Oriented Product Lines – Heterogeneous Style based Architecture Model (HEART)

Developing Service Oriented Product Lines

Developing Service Oriented Product Lines The levels of Services – – – Molecular services: The mass of low level services ( atomic services) are grouped into richer services as required by the product family are called ‘molecular’ services. Orchestrating services: High level services, that are specified first as workflows and their constituting tasks. The system integration and deployment activity form a product and the orchestrating services provide services to users by integrating and parameterizing the molecular services at runtime.

Developing Service Oriented Product Lines Example: The virtual office of the future (VOF)

Developing Service Oriented Product Lines Example: The virtual office of the future (VOF)

Developing Service Oriented Product Lines Example: The virtual office of the future (VOF) Molecular Service Specification 1: molecular service FOLLOW ME (user User) 2: invariants user.employeeStatus true 3: precondition user.authentification logged in 4: postcondition none; 5: option Environment Visualization 6: binding time runtime 7: precondition user.device desktop notebook 8: postcondition none; 9: option Automatic Log-on 10: binding time runtime 11: precondition user.rank director manager and 12: RFID bases user location method available 13: postcondition user.access granted rejected;

Heterogeneous Style based Architecture Model (HEART) Design Goals 1. Support for late binding of networked resources to their consumers: 2. Support for mobile products 3. Support for four main functionalities of a resource consumer: a resource consumer should be able to maintain connectivity to the system domain, recognize current context, interact with a user, and manage multiple active services at a certain moment. 4. Support for service level classification 5. Support for dynamic reconfiguration

Heterogeneous Style based Architecture Model (HEART) The HEART model consists of three decomposition levels to address design goals

Heterogeneous Style based Architecture Model (HEART) The next decomposition level supports the third design goal by adapting the communicating process style.

Heterogeneous Style based Architecture Model (HEART) The next decomposition level supports the fourth and fifth design goals by adapting C2 style, which provides flexibility through its layered structure and modular components (called "bricks.“), a brick can send/receive messages to/from other bricks through its top and bottom ports, and bus-style connectors connecting ports.

References SOA Development Using the IBM Rational Software Development Platform: A Practical Guide Dagstuhl Seminar 09021: Software Service Engineering, An Executive Summary, Willem-Jan van den Heuvel1, Olaf Zimmermann2, Frank Leymann3, Tony Shan, 2009 An Approach for Developing Service Oriented Product Lines, Jaejoon Lee, Dirk Muthig and Matthias Naab, 12th International Software Product Line Conference, 2008 IEEE

Conclusions This lectures reviewed the concepts of SOA We discussed the IBM Platform for SOA application development We also discussed concepts of Software Service Engineering Presented briefly an approach for SSE development using product-line architecture concepts