SOA Simplified Service Virtualization With the Managed Services Engine 임형준 (hyungjun25@cnu.ac.kr) 충남대학교 컴퓨터공학과 데이터베이스시스템연구실 2018년 11월 7일 수요일

Table of Contents Background SOA challenges Service virtualization basics Microsoft Services SOA Infrastructure Windows Communication Foundation Getting started with the Managed Services Engine Importing and configuring service resources References

Background As businesses begin to adopt service-oriented architectures (SOA), they initially focus on service-enabling core business functions and processes Loose-coupling, reuse, and the overall alignment of software assets with how the business actually works While SOA can definitely provide benefits to the business, there's a common misperception that SOA makes things easier This is simply not true Building distributed systems is inherently complex Architectural principles that can help you manage some of that complexity

SOA Challenges Can you trust your services to support mission-critical business processes? Can you make changes to existing services without wondering what might break? Do you have design-time and runtime visibility across all your systems and services? Can business, operational, and policy changes be made without requiring developer involvement?

Service Virtualization Providing a common infrastructure for building and managing a complex service ecosystem while addressing the challenges of SOA initiatives A technical solution referred to as the Microsoft Managed Services Engine (MSE) A common architecture and a centralized runtime that provides the service plumbing required by all services and their consumers throughout the entire heterogeneous service ecosystem The runtime provides the core capabilities all services need such as versioning, protocol-mapping, monitoring, routing, and run-time policy enforcement

New services are Added to the Runtime Services are added to the runtime by simply importing the service metadata WSDL definitions WS-MetadataExchange endpoints Custom importers for legacy line-of-business apps that describes the service Once the metadata is imported Administrators can manage the physical service resources by defining models for different types of virtual services that the runtime can automatically host and expose to the various service consumers The idea is consumers will interact only with the virtual services

Service Virtualization Runtime Translates these models into service behaviors that provide the aforementioned capabilities without requiring any changes to the deployed and running service code Easily configure virtual service endpoints to accommodate different types of consumers, to version operations, and to modify service policies as business requirements The service model becomes the communication rendezvous point Architects, developers, IT professionals, and the business owners All of whom can interact with the models through role-specific views in the management tool From a consumer perspective A virtual service looks just like any other service it might consume Consumers cannot tell the difference between a virtual service and the real service sitting behind the scenes

A Service Virtualization Implementation Pattern A service intermediary is necessary to decouple the client from the service implementation Service Intermediary Client Implementation Catalog Design Tools A Common Pattern for Service Virtualization

Service Intermediary In this type of architecture, clients never interact with service implementations directly Always communicate through the service intermediary Where the virtual services are hosted and exposed It can be located with the client, with the implementation, or somewhere in between to provide topology flexibility How to host the virtual services by reading the service models from the service catalog Expose multiple virtual services for a single service implementation so you can easily accommodate different customer scenarios

A Role of Service Intermediary All communication travels through the service intermediary central node to intercept each service invocation and introduce additional service behaviors without having any impact on the client or service code for example, operation versioning, protocol mapping, monitoring, routing, run-time policy enforcement, and custom behaviors

Microsoft Services SOA Infrastructure An implementation of the service virtualization pattern through a solution called the Managed Services Engine The MSE is built on the Microsoft server platform Microsoft Windows Server 2003, Microsoft Windows Server 2008 Microsoft SQL Server 2005, SQL Server 2008 Microsoft .NET Framework 3.5 A heavy focus on Windows Communication Foundation (WCF) for the underlying communication and the implementation of the service interception pattern described earlier

Windows Communication Foundation .NET Framework 3.0의 기능 Service Oriented Architecture 기반 Web Service (XML + SOAP) 기반 다양한 Communication 프로토콜 지원 HTTP, TCP, Named Pipe, MSMQ, P2P 다양한 웹 서비스 표준 지원 SOAP 1.2, WS-Addressing WSDL, WS-Policy WS-Security, WS-Trust, WS-SecureConversation WS-ReliableMessaging WS-AtomicTransaction, WS-Coordinate

Why WCF? Future Communication Infra Common Programming Model 웹서비스 기반 (XML + HTTP) 서비스 지향 아키텍처 (SOA) Interoperability 표준 WS-* 스펙 구현 Common Programming Model Web Service, .NET Remoting, LRPC, MSMQ 프로토콜에 관계없이 하나의 프로그래밍 모델 사용 가능 단일 코드 베이스 사용 가능 New feature 트랜잭션, 신뢰할 수 있는 메시징, P2P, … 다양한 바인딩 (프로토콜지원)

WCF Features Web Service Based Security Transaction Reliability XML, HTTP, SOAP, WSDL 등 웹서비스 스펙 준수 Security WS-Security, WS-Trust 등 메시지 기반 보안 제공 HTTPS, 인증기반의TCP/IP 등 트랜스포트 수준의 보안 제공 Transaction 분산 트랜잭션 지원 TCP 바인딩 사용시 OLE Transaction 직접 사용 Reliability 신뢰도 높은 메시징을 위해 WS-RM 프로토콜 구현 세션 기능 제공 (ASP.NET의 세션과는 다른 개념) P2P Networking Rich Built-in Bindings BasicHttp, WSHttp, WSDualHttp, NetTcp, NetMsmq, NetNamedPipe등

Basic Concept WCF Endpoint (ABC of WCF Programming) Address Binding 서비스를 액세스하기 위한 주소 Transport에 따라 달라짐 http://......, net.tcp://......, net.pipe://......, net.msmq://....., net.p2p://...... Binding 서비스 호출에 사용되는 Transport 프로토콜, 인증, 암호화, 메시지 인코딩, 세션 여부 등 Binding에 의해 Address 형식이 결정되곤 함 Custom Binding 제공도 가능 Contract 서비스에 대한 인터페이스 서비스의 메쏘드(Operation Contract) 관련 데이터 타입들(Data Contract) 하나의 WCF 서비스는 다수의 Endpoint를 가질 수 있음

Address, Binding, Contract

Creating Endpoints

Channel WCF 프로그램 간의 메시지 통로 클라이언트가 서비스로 처음 메시지를 전송하는 순간에 채널 확립 채널 타입(단순 입력, 단순 출력, 입-출력, 요청-응답 메시지 패턴으로 구현) 클라이언트 채널은 서비스 endpoint 제작 클라이언트가 서비스로 처음 메시지를 전송하는 순간에 채널 확립 최초 클라이언트 서비스 메시지 전송이 두 번째 메시지 전송 보다 더 시간이 소요될 수 있음

Understanding the Managed Services Engine The Managed Services Engine Architecture

MSE Components Service Runtime Engine The messenger is primarily responsible for message normalization The broker receives the normalized message and is primarily responsible for operation rationalization (choosing a specific version of a specific operation) The dispatcher is primarily responsible for invoking the target implementation Service catalog (Metadata repository) Contains the models that drive your virtual services hosted by the MSE runtime You import services (as well as other artifacts) into the repository using a management tool Once you've imported the service metadata, you can begin defining what your virtual services will look like to the rest of the world Messenger The first layer of this architecture is the messenger. This layer is responsible for hosting endpoints, receiving service requests, executing all message-level tasks, and supporting message-level policy. The messenger has no awareness of specific services as its task is to simply validate that a message is acceptable and could be making a valid service request. For example, if an endpoint in the DMZ requires an X-509 certificate, the messenger will verify that, but will not verify that it is invoking a valid service. Broker The next layer of the Managed Services architecture is the broker, which is responsible for the service control functions, including operation rationalization, request validation, service context, and operation policy enforcement. The broker is not concerned with any message level policies, but rather focuses on whether the message is valid for a specific operation listed in the service catalog. This includes the ability to determine the appropriate version, either implicitly or explicitly. Once the broker is done processing, the message is processed as a valid service request. Dispatcher The final layer of this architecture is the dispatcher, which is responsible for the execution of the service logic. This architecture allows an operation to have multiple implementations and each could have its own dispatcher implementation. The dispatcher is based on a factory model, where each type of communication pattern could have its own implementation. The execution specifics are again defined by metadata in the Service Catalog which the broker provides to the appropriate host. This is where execution details, such as timeouts, re-tries, and asynchronous routines, would be handled.

Importing Service Resources from WSDL What type of service metadata you'd like to extract from the WSDL definition to import into the repository Choose to import only the schema definitions, and they will be imported as schemas and data entities in the MSE repository Also choose to import all of the service resources found in the WSDL definition including the schemas, operations, bindings, and endpoints, and they will be imported into the MSE repository as data entities, resources, bindings, and instances, respectively

Importing a RESTful Service Resource Since RESTful services don't typically come with a WSDL definition Use a different wizard for defining and importing metadata that describes the RESTful service in terms of operations

References Aaron Skonnard, “SOA Simplified: Service Virtualization With The Managed Services Engine”, http://msdn.microsoft.com/en-us/magazine/dd727511.aspx, May, 2009