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

2. 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

3. 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

4. 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?

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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, …
다양한 바인딩 (프로토콜지원)

14. 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등

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

16. Address, Binding, Contract

17. Creating Endpoints

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

19. Understanding the Managed Services Engine
The Managed Services Engine Architecture

20. 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.

21. 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

22. 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

23. References
Aaron Skonnard, “SOA Simplified: Service Virtualization With The Managed Services Engine”, May, 2009