Download Connected Systems Architectural Guidance

Connected Applications
Today
Case Studies I
Lawrence Wilkes
Deutsche Bank
Deutsche Bank Global financial services group provide
services in 70 countries
Business Challenge
Components calculate option pricing for equity derivatives
Distribute components to local operations in a way that could be
easily adopted for each market in which the set of calculators was
being used
Their derivatives calculators provide option prices as a
web service hosted on Unix
Using custom controls and Visual Studio .NET, a drag
and drop toolkit was provided to its developers around
the world
.NET Framework provided:
Seamless interoperability with Unix hosted services
Encapsulation through componentisation
development time reduced by 50%
Global Pricing Calculation
Architecture
Name
Ticker
CCY
Exch
.NET
.aspx
.cs
Client SDK using
Custom controls
Web Service
F(x)
Unix hosted equity
option calculator
L’Oréal
Before .NET
No separation of
elements in the page
Logic and page
design mixed together
High costs of
maintenance and
change
http://www.lancome.fr
L’Oréal Architecture
Web Service
XML
Service
Facade
asmx
L’ Oréal Web Services
 Product Description
 Search
 Images
 Request Further Info
BizTalk Server
Queue
Validate
Transform
HTML
ASP
.asp
.NET
SQL 2000
L’Oréal Summary
BizTalk Server and SQL 2000 used to implement XML
product Catalogue
ASP .NET separates user interface from XML data –
using server controls
Web Services integrate with retailers and suppliers
BizTalk for XML transformation and integration
"We expect .NET to deliver a 20 to 30 percent reduction
in the total cost of ownership for our hundreds of Internet
properties. In addition to lower development and
deployment costs, our new solution will reduce ongoing
administrative costs by making life much easier for our
webmasters and marketing people.“
Jérôme Peyrelevade Head Technology Officer L'Oréal
Internet and e-Business Group Architecture
Accor Services
3500 hotels in 88 countries, 46% market share, offering
budget to luxury accommodations including travel
agencies, restaurants, and casinos
Accor swapped development from Java/WebLogic when
Microsoft Consulting Services demonstrated the .NET
development environment
The task:
Replace back-office systems with common library of
business objects
Streamline e-procurement for the chain of restaurants
and hotels
Manage sales and marketing campaigns for increased
sales and incentives for sales staff
Accor .NET Architecture
Web Service
Service
Facade
asmx
C#
Supplier
XML
HTML
E-procurement
Sales Campaigns
App
Centre
BizTalk
ASP
.NET
Windows 2000
Business
objects
SQL 2000
BTI UK Hotel Broker
Corporate
Travel Rules
Maps
Weather
Driving
Instructions
XML
• Hotel Broker
• Flight Broker
• Car Broker
Web Service
BTI Hotel
Broker
XML
Web Service
Hotels
Car Hire
HTML
Corporate
Users
.NET
Windows
Server 2003
SQL 2000
GALILEO Web Services
 Reservation Builder
 Trip Planner
 Flight Information
 Itinerary
 Travel Codes Translator
BTI Benefits
Call centre productivity increased by up to 40 per
cent
Agents concentrate on complex requests
Supported infrastructure and lower cost of
ownership
Integration with other systems via Web services
New automated services to customers
Building Connected Apps on
the Microsoft Platform
Nigel Watling
[email protected]
Microsoft EMEA
Components, Services, Systems
Do Bar
Do Foo
Do Baz
Service Oriented Architecture
Key Points
SOA is an architectural approach to creating
systems built from autonomous services
i.e. it is a mindset NOT a technology
It can be implemented using any technology
A major leap forward in philosophy and
approach to designing and building
distributed, connected systems
Leverages what we already know
Evolves and consolidates all we’ve learned to
date about designing & building distributed
systems
Service-Orientation Tenets
Philosophy of services
Tenet \Ten"et\, n.
Any opinion, principle, dogma, belief, or doctrine,
which a person holds or maintains as true.
Source: Webster's Revised Unabridged Dictionary, © 1996, 1998
Services have explicit boundaries
Across boundaries we must have FORMAL interaction
Services are autonomous
Message based interaction with no implicit dependencies
Services share contract and schema
Require a formal, shared language for schema and contract
Service compatibility is determined based on policy
Require a formal, shared language and namespace for policy
Why is SO important?
Provides us with an opportunity to rethink
how we design and architect tomorrow’s
systems
With Web services it enables a level of
interoperability never before achievable
Makes explicit some of the core
assumptions that compromise today’s
systems
Particularly around boundaries and locality …
Practicalities
Boundaries
A SOA boundary is
explicit
autonomous,
based on schema and contract for structure,
and on policy for semantics
Influenced by platform, deployment and trust
Objects are appropriate within boundaries
Services are appropriate across and within
boundaries
A SOA environment extends only as far as where
we agree the boundary is
How far do you want your boundary to extend?
Web Services
Standards-based Messaging
Web Services form a global infrastructure for
message passing
Interoperability through open standards
Core set of standards has been built
Industry is driving development of additional standards
to complete the architecture
Can be used with any architecture (not just SOA)
e.g. RPC between components!
On any hardware, any platform, any
programming language
Broad interoperability requires web services
What is a practical, broadly
interoperable SOA?
An applied approach to creating systems built
from interoperable autonomous Web services
Web services
Communicate via SOAP message exchanges
Are built to last
Have a critical need for availability and stability
Systems
Are a set of Web services cooperating in a given task
Are built to change
Adapt to new services after deployment
SOA Implementation
Systems and Services
A system built using SOA principles which
wants broad usage will:
Build on the WS- protocols
And use SOAP messages between services
Internally a service can utilize whichever
technologies and techniques are the most
appropriate
E.g. mainframe
Choose your boundaries carefully
Microsoft Technologies
What to use, where and when!
There are many Microsoft technology
choices for building SOA systems
Which should you use, where and when?
ASMX
ASP.NET Web Services
ASMX is Microsoft’s recommended method
for developing Web Services today
ASMX gives great support for formal
contract and schema expression (WSDL)
ASMX doesn’t natively support the WS-*
protocol family
ASMX can be combined with WSE to get
WS-* support
WSE
Web Services Enhancements
Getting started today? Use the evolving
advanced feature set provided by WSE
Early implementations of WS-* specifications
WSE tracks the evolution of emerging WS-*
protocols
WSE builds on current Microsoft messaging
technologies
WSE can be used with ASMX for Web Services over
HTTP
WSE can be used standalone for Web Services over
TCP/IP
WSE’s supportability is 2+1 (standard+extended)
.NET Remoting
.Net Remoting is an easy-to-use object remoting technology
.NET Only
.NET Common Type System (NOT XML Schema)
Proprietary messages
Third party bridging products
No built-in security until .NET Framework 2.0
Can leverage IIS for transport-level security
Or roll-your-own custom channel
It requires tightly coupled implementation between
participants, and is therefore particularly unsuited to SOA
boundary implementation
It is a reasonable technology to use for cross app-domain
communication within the service boundary
DON’T USE XPROCESS/XMACHINE
Use ASMX or Enterprise Services
.NET Remoting and Web Services
Working Side by Side
Web Service
Remoting
Client
Client
RemotingWeb Service
Interface Interface
Service
Implementation
Don Box on .NET Remoting…
From his blog on 26/4/04
The Good
The transparent proxy (TP) /stack builder sink (SBS) infrastructure
Allows you to construct an object reference for ANY CLR interface.
Allows the CLR to marshal object references across AppDomains inside a process
The technology is alive and well and a crucial part of the CLR. Indigo M5 uses this!
The Bad
The support for WSDL under the TP/SBS infrastructure is an architectural dead end
The Ugly
.NET Remoting assumes shared classes and shared assemblies between the two
endpoints. Indigo exists to break this dependency. This is a profound architectural
change.
Custom transport channels are based on bytes. Indigo has a SOAP/Infoset-based
architecture that is more general and will have a longer life span
There are no plans to support the binary/TCP transport channel. It is one-off and
proprietary.
The TP/SBS infrastructure allows class-based remoting using MarshalByRefObject.
Indigo does not require MBRO.
Conclusion
The real asset of .NET Remoting is the TP/SBS infrastructure. If you find yourself
wanting to use it, do so with a clear conscience.
If you're crossing host boundaries, ASMX is probably a better choice, both
architecturally as well as in terms of tracking where the platform is headed in the next
2-10 years.
Enterprise Services
ES offers rich enterprise system features
Performance
Security
ACID transactions
Object Pooling
Just-in-time activation
Declarative transactions
Role-based security
And more…
ES is the programming model that will most
resemble the Indigo programming model
ES uses DCOM as its communication protocol
DCOM is not suitable for spanning trust boundaries
It is tightly coupled enough (because you have
proxies/stubs) that you should avoid using it cross
machine
COM+ relies on closely coupled participant systems,
and is unsuitable for expression of service boundaries.
It is fine for use within a service boundary
.NET Enterprise Services
Working Together
Remoting
Client
Web Service
Client
Remoting
Interface
Web Service
Interface
Service Implementation
ACID Transaction
MSMQ
System.Messaging
MSMQ is Microsoft’s Message Queuing
technology
Performant, reliable, durable messaging
Rich administrative support
Proven model
No language for schema, contract, policy
These are intuited, not interpreted
Great to use within a service boundary
System.Messaging is the .NET wrapper
SOA and MSFT Messaging Stacks
ASMX and/or WSE for the boundaries
ASMX, WSE, .NET Remoting, Enterprise
Services, MSMQ inside the boundaries
ASMX+/|WSE
Other Microsoft Web Services
Solutions
ATL Server and Managed C++ – ISAPI
extensions
SOAP Toolkit – deprecated by .NET
No longer retires July 1, 2004
Standard support April 05, Extended April 07
SQL Server 2005
TDS only prior to SQL Server 2005
Now uses SOAP and HTTP via http.sys to go
through firewalls
#1 Recommendation
Use ASMX + WSE to create Web services
Complementary Technologies
Technology Map
CLR
Remoting
Web Services
SOAP
Clients
CLR
Application
CRM
ASMX
BizTalk
Enterprise
Services
ERP
Connectors…
BizTalk Server 2004
Overview
Services must be agile
Business Process Management
Enterprise Application Integration
Trading Partner Interaction
BizTalk Server incorporates SOA paradigm
Components are exposed and self-describing
Robust support for long-running, asynchronous
transactions
Solutions are extensible and reusable
Processes can be monitored in real time
Can reconfigure any process activity without disrupting
the process
BizTalk Server 2004
Faster development and deployment of
business integration applications
Microsoft Office access
Vertical Market accelerators
Enterprise class scalability
Easy integration with Web services
Extensive standards support
BizTalk Server 2004
Process Service Features
Process Orchestration
Rapidly develop integration services
Transport abstraction
Human Workflow Services
Expose end user touchpoints
Scalable long-running transactions
Business Activity Monitoring
BizTalk Server 2004
Orchestration
BizTalk Server 2004
Infrastructure Service Features
Security
Encryption
Authorization
Single sign-on
Reliable messaging
Auto retry
Secondary transports
Auditing
Message tracking
Application data tracking
BizTalk Server 2004
Working Together
Client
Application
IIS
BizTalk Server
Web
Service
BAS
Web
Service
SharePoint Portal Server &
SharePoint Services
Web-based Team and enterprise
collaboration
Audience targeting and personalization
Combine team portals into enterprise portals
SharePoint Services built on .NET framework
Integrated with BizTalk Server
Sites created in ASP.NET
Web service and XML integration
Host Integration Server 2004
Technologies to Integrate IBM Hosts with
New Solutions Developed using Microsoft
Windows
Lower Costs to Deploy Web and SOA Solutions
Reduce Time to Market for Enterprise Devs
Simplify and Secure Network Infrastructure
Approaches and Methods of Integration
Network and Security
Data Access and Messaging
Application to Application
The Role of Objects
Object Orientation
Interaction Richness
Complete fidelity with local
contract
Customers have 20+ years of experience
and have built intuition here
Boundaries are harder to isolate
Requires careful opting out
Share types, not schemas
Tightly Coupled
Typically require deployment of both
client and server in sync
Assume cheap, transparent
communication
object identity and lifetime
maintained by infrastructure
Platform-based compatibility
Assertions built into platform
Service Orientation
Reduced Assumptions
Reduce assumptions between
services
Builds on ideas from component software,
distributed objects, and MOM
Boundaries are explicit
Opt in model
Share schemas, not types
Autonomous
Security and failure isolation are a
must
Variable cost, explicit communication
Independent deployment of client /
Service
Policy-based compatibility
Assertions use stable global names
Today’s Prescriptive Guidance
Summary
Build services using ASMX
Enhance your ASMX service with WSE if you need the
WSE feature set and can accept the support policy
Use object technology in a service’s
implementation
Use Enterprise Services if:
You need ES rich feature set
You are communicating between components on the local
machine and have performance issues with ASMX or WSE
Use .NET Remoting if:
You need to integrate with an existing proprietary protocol
You are communicating in-process, cross app domain
Use System.Messaging if you need the reliable
messaging and queuing features in MSMQ
Developer Enablement
Visual Studio .NET
2003
Foundation for XML
WS programming
model
Key supported
standards
Attribute based
development
Schema driven XML
serialization
WS-I Basic profile
compliant*
Web Services
Enhancements (WSE) 1.0
Foundation for advanced Web
service support
Improved extensibility
WS-Security
Guidance
Authorization and Profile Application
Block
Building Interoperable Web Services:
WS-I Basic Profile 1.0
Web Service Façade for Legacy
Applications
Infrastructure And Business Process
Windows Server
2003
Metadata
AD & ADAM
Security
Authorization
Manager
Registry & Discovery
Enterprise UDDI
Queuing
MSMQ
Hosting
IIS 6.0 & Enterprise
Services
Management
WMI
BizTalk Server 2004
Connectivity (EAI/B2B)
350+ Adapters
Native Web service
support
Business Process
Orchestration
Business Rule Engine
Business Activity
Monitoring
Human Workflow Services
Partner Management
Guidance
Information & Application
Architecture for the
Service-Oriented
Enterprise
Application
Interoperability: Microsoft
.NET and J2EE
Security
Single Sign-On
Management
SQL Server 2000
Web Services
Support
Smart Client And Reach
Office System 2003
XML meta and
persistence format
InfoPath for schema,
template driven forms
Native Web service
consumer
Visual Studio .NET
integration
Guidance
Smart Client Offline
Application Block
Asynchronous
Invocation Application
Block
Service Aggregation
Application Block
Sharepoint Portal
Server for Office
Windows Sharepoint
Services
.NET Compact
Framework
PocketPC and
SmartPhone
© 2004 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.