Christian Weyer thinktecture

Introduction & Motivation for ISB Extending a simple WCF service Identity, Authentication, Authorization Application Scenarios Messaging Options Summary 2

Service Delivery SaaS Service Composition SOA Service Experience Web 2.0 Service … … Services Software +

Software+Services seems to me like „SOA done the right way“, frankly Increasing need to build and enable composite applications in a service-oriented manner Some solutions look for easy connectivity Provide value add with advanced messaging options Strong focus on identity, authentication and authorization required 4

5 BondPrice Enterprise X

6 BondPriceTrade Enterprise X

7 BondPriceTrade Enterprise X

8 XML Enterprise Service Bus Enterprise X BondPriceTrade

9 Enterprise X BONDPRICETRADE XML Microsoft “Biztalk Services”

10 Application 1Application 2 XML Microsoft “Biztalk Services” Bank A

11 Application 1Application 2 XML Microsoft “Biztalk Services” Market Data Publish Subscribe XML

Bank A 12 Application 1Application 2 XML Microsoft “Biztalk Services” Market Data Publish Subscribe XML Subscribe Publish

Syndication Peer-To-Peer Callbacks, Notifications Multicasting, Pub/Sub Remote Control Prototyping, Testing 13 C I A Confidentiality, Integrity, Authenticity

Codename „Biztalk Services“ is the current incarnation of the ISB Provides several services in the cloud, currently Identity Management, STS Connectivity, Relaying Workflow (just not yet) Enter the ISB at Developers (and architects) can grab an SDK WCF-based, leveraging standards Custom bindings and behaviors 14

Service Client Relayed Connection ConnectOpen Authenticate Identity Service Connectivity Service Trust “Biztalk Services” 15 Direct Connection (optional) 5 6

ITokenProvider tokenProvider = new CardSpaceTokenProvider(); ServiceEndpoint ehep = echoHost.AddServiceEndpoint( typeof(IEcho), new RelayBinding( RelayConnectionMode.RelayedDuplex), "sb://connect.biztalk.net/ services/thinktecture/Echo"); ehep.Behaviors.Add(tokenProvider); ITokenProvider tokenProvider = new CardSpaceTokenProvider(); ServiceEndpoint ehep = echoHost.AddServiceEndpoint( typeof(IEcho), new RelayBinding( RelayConnectionMode.RelayedDuplex), "sb://connect.biztalk.net/ services/thinktecture/Echo"); ehep.Behaviors.Add(tokenProvider);

<endpoint address="sb://connect.biztalk.net/ services/thinktecture/Echo" contract="IEcho" binding="relayBinding" bindingConfiguration="myRelay" /> … <binding name="myRelay" connectionMode="RelayedDuplex" /> <endpoint address="sb://connect.biztalk.net/ services/thinktecture/Echo" contract="IEcho" binding="relayBinding" bindingConfiguration="myRelay" /> … <binding name="myRelay" connectionMode="RelayedDuplex" />

Frankly, in some big shops the relay binding is to date a reason to get fired There is a reason for the DMZ You expose your very own machine to the outside Customers need to be aware of this different security risk model Integrate risk model into analysis phase IMO, we will need guidance and tools to properly set up and configure networks for working with the relay Maybe also leverage different technologies, like Teredo or UPnP 18

Authentication through username/password or information card „Biztalk Services“ implements a Secure Token Service (STS) based on WS-Trust specification Feel the future of AD Authorization based on powerful & flexible claims-based model Configure through web frontend Configure through API in SDK 19

20 Identity Relay Service Client GetToken() Connect Relay cert registered w/STS Open

Problem Consumers want to be notified of new data No polling, but rather proactive push messaging desired NATs and firewalls in the way (by design ) Solution Expose duplex contract through relay binding Service can publish new data through the ISB‘s address ISB securely dispatches messages appropriately to the callback endpoints 21

Problem Multiple (n) receivers want to receive messages Sender(s) does not want to send n messages and maintain list of receivers NATs and firewalls in the way (by design) Solution Let the ISB do the maintenance of receivers Sender send one message to the ISB – the ISB send n messages to n receivers 22

Biztalk Services (Cloud) Biztalk Services (Cloud) … … … Send: sb://.../traffic Listen: sb://.../traffic Listen: sb://.../traffic 23

Problem We have m publishers and n subscribers Need for infrastructure to handle these message exchanges Similar to pure multicasting scenario NATs and firewalls in the way (by design) Solution m publishers send to multicast address at ISB n subscribers listen to mulitcast address at ISB ISB does the hard work of correlation and dispatching 24

„Biztalk Services“ is an incubation project There will be a V1 of the ISB… Of course, there are still missing parts today, e.g.: Store and forward Broader platforms support Really federated identity I am sure we will see improved feature support in upcoming releases Keep track and watch 25

Leveraging the cloud for composite applications can be a winner Powerful messaging options Enabling otherwise-hard-to-realize scenarios Internet Service Bus can handle connectivity, authentication, authorization, messaging and other connected systems aspects Think about security risk model „Biztalk Services“ incubation project shows the path to a real ISB – with a real name 26

Christian Weyer Weblog Christian Weyer thinktecture 27

© 2007 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.