Transcript Slide 1

Using Web Services to
Build Mission Critical Integration Solutions
2
Agenda
Eric Newcomer
CTO, IONA Technologies
–
–
–
–
Introduction
Requirements for mission critical application integration
Web services standards update
Gap analysis
Peter Cousins
Technical Director, IONA Technologies
– Introduction to Artix
– Building secure, reliable, transactional, multi-transport Web services
– Use cases
3
IONA Drives Down the Cost
and Complexity of Enterprise IT
The
IONA
Benefit
Customers include world’s largest firms

80% of Global Telecom

70% of Financial Services in Global 100

Blue Chip Partners
System
Cost
and
Complexity
System Life
Our vision extends beyond integration



Worldwide presence

Global HQ in Dublin, Ireland

US HQ in Massachusetts
We improve our customers’ return on current assets
While driving an architecture for future change
Making their infrastructure technology and
vendor independent
4
About Myself …

CTO of IONA since May 2002 - responsible for Web services strategy

25 years experience in the computer industry, including more than 15 years
at Digital Equipment Corporation/Compaq Computer

Author of Understanding Web Services
and co-author of Principles of Transaction
Processing

Co-author and editor of the Structured
Transaction Definition Language specification published by X/Open

Original member of the XML Protocols Working Group at W3C and current
editor of Web Services Architecture Specification

Co-Author of the Web Services Composite Application Framework (WSCAF) submitted to OASIS
5
Web Services Offer Great Promise
 Web services are highly suited
to integration




Technology-agnostic interfaces and
protocols for interoperability
Easy to learn and use
Backed by a broadly accepted set of industry
standards (SOAP, WSDL, UDDI)
Support integration both inside and
outside the organization
 Still, Web services are
relatively immature



Standards haven't caught up to the
requirements of users
Security, reliability and availability are still only
partially addressed
Promise of multi-protocol mappings unfulfilled
“To succeed where others
failed, enterprises will
need more-flexible
architectures to deal with
rapid economic, market
and technological
changes. Web services
will play a key role in this
transformation”
How Web Services Will Change
Enterprise Architectures
July 24 2002
6
The “Web Services Gap”
Mission-Critical
Integration Requirements
 Heterogeneous
applications and
middleware platforms
 Enterprise Features:
 Scalability
 Reliability
 Performance
 Desire for Flexibility:
 Architecture
 Tools
Web Services are still a
relatively immature technology
 The standards
haven't caught up
to the needs of the
user
 Concerns for
security, reliability
and availability are
only partially
addressed through
standards
 A great deal of
standards activity is
ongoing and
leaderless
7
The “Web Services Gap”
Mission-Critical
Integration Requirements
Web Services are still a
relatively immature technology
 The standards
 Heterogeneous
applications and
middleware platforms
 Enterprise Features:
 Scalability
 Reliability
 Performance
 Desire for Flexibility:
 Architecture
 Tools
WHAT IS NEEDED ?
Reliable, secure,
transactional, stateful,
multi-transport
Web Services
Ideal for
mission-critical
application integration
haven't caught up
to the needs of the
user
 Concerns for
security, reliability
and availability are
only partially
addressed through
standards
 A great deal of
standards activity is
in balance and
leaderless
8
Standards “Alphabet Soup”
Others ??
Too many to list all
Management
Web Services
Distributed Management (WSDM)
Orchestration
BPEL4WS
Transactions
Security
Reliable Messaging
WS-CAF, WS-T & WS-C

Lots of activity
 Not enough progress
–
–
–
–
Competing standards
Vendor agendas
Competing bodies
Slow pace
XML Encryption, XKMS,
XRML, WS-Security, SAML
WS-Reliability,
WS-ReliableMessaging
Competing Standards Bodies
Service Contract
WSDL
Look-Up & Discovery
UDDI
Message Payload
SOAP
9
What IONA is Doing About It
Extending our enterprise heritage to Web services
 Standards based integration
 Extending standards for mission-critical integration
 Security, Transactions, Reliability
On October 20th, IONA introduced Artix
 The software industry’s first-ever Web services platform built for
mission critical application integration
 Helps customers use Web services the way they really want to
How to Build Reliable, Secure,
Enterprise Web Services Now
11
Topics to be Covered
 Multi-transport Web services
 Reliable Web services
– Load balancing
– Failover
– Stateful
 Secure Web services
– Wire-level
– Authentication
 Transactional Web services
WSDL: The Enterprise Service Contract
13
WSDL could have been called…
ESDL - Enterprise Service Definition Language
WSDL is the logical choice
as the service definition language
–
XML Schema provides the type system
–
Logical Contract is all applications
need to care about
–
Physical Contract is extensible to
support any middleware binding
ESDL
PortType
Operation
Logical
Contract
Part
Logical contract
–
Defines public interface
–
Independent of transports,
data formats, and programming languages
Physical contract
–
Defines binding to transport and wire-level data format
–
Multiple physical contracts can be defined for each
logical contract
Message
XML Data Type
Binding
Physical
Contract
Port
Service
14
Why WSDL?
WSDL is Open and Extensible


Extensibility allows non-SOAP bindings
Extensibility allows service policies to be defined in contracts too
SOAP bindings

RPC or Document, encoded or literal over HTTP
Non-SOAP bindings


Enterprise connectivity: MQ, Tuxedo, Tibco, CORBA, IIOP, HTTP/S
Enterprise messaging: XML, Fixed Format, FML (Tuxedo), TibRvMsg, G2++
Service Policies

Routing, Failover, Security, Transactions, etc.
Industry Support
–
–
–
–
Strong Developer Interest
Strong multi-vendor support
Thriving ISV tool market
Thriving open source community
15
Creating Your WSDL (or rather ESDL)
Development Cycle
+
Client
Proxy
Code
OR
Server
Stub
Code
Service
Designer
Security –
wire level and / or authentication
Routing –
Add decision logic to the Web service
Tibco
TibRV
Msg. Def.
CORBA
IDL
Tuxedo
TibRV
Msg. Def.
HOST
COBOL
CopyBooks
MQ
Message
Definition
Transports Bindings –
SOAP over HTTP, IIOP, MQ, etc..
Transactions –
work with MTS, OTS, MQ, Tuxedo
transactions
Reliability –
Failover, scalability, state management
Code
Generation
Tools
wsdl2cpp
wsdl2corba
wsdl2java
16
Code Generation
•
Client
Proxy
Code
Tools for generating C++,
CORBA and Java Web
service proxies and stubs
–
OR
Quickly build new client
and server Web
service applications
Server
Stubs
Code
Code Generation Tools
wsdl2cpp
 Generates C++ proxies and stubs from WSDL contract
–
Generated code hides
transport details
–
Classes/APIs for
manipulating SOAP
messages
•
These server applications
can be invoked by any
Web services consumer
•
Related spec: OMG
WSDL - C++ Mappings
wsdl2corba
 Generates CORBA proxies and stubs from WSDL
contract
wsdl2java
 Generates Java proxies and stubs from WSDL contract
Multi-Transport Web Services
18
Multi-Transport Web Services
Development
Middleware transports are specified in Design Studio
–
One or more transport bindings
•
–
One or more ports for each transport binding
•
•
–
HTTP/S, MQ, IIOP, Tuxedo, Tibco
Binding information defined in the physical contract
•
WSDL
e.g. HTTP ports are URLs and IP addresses
e.g. MQ ports are queue names
Bindings are defined as WSDL extensors
PortType
Operation
Logical
Contract
Part
XML Data Type
Run-Time handles:
–
–
–
Synch/Asynch bridging
Payload mapping
Protocol bridging
Binding
Physical
Contract
Bindings only involve the physical contract
–
–
Message
They can be added and removed without affecting application code
Allows you to modify transport level configuration data at any time
Port
Service
19
Multi-Transport Web Services
Run-Time View
Web Service
Requestors
Web Service
Providers
SOAP
HTTP/S
HTTP/S
SOAP
Web
Service
Run-Time Services
.NET
TUXEDO
TUXEDO
Payload
Mapping
Java
Service
Routing
FML
Java
Service
Registry
TIBCO
TIBCO
TIBRV
MQ
MQ
MQSeries
Protocol
Bridging
Security
Synch/Asynch
Bridging
MQSeries
MQ
C++
C++
IIOP
Transport
Plug-Ins
Authorization
Authentication
Transaction
Management
Discovery and
Load
Balancing
IIOP
Transport
Plug-Ins
IIOP
CORBA
20
WSDL Extensors
XML Schema declarations uniquely identify extensor schemas
<?xml version="1.0" encoding=“UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:mq="http://schemas.iona.com/transports/mq"
xmlns:fixed="http://schemas.iona.com/bindings/fixed"
xmlns:tns="http://soapinterop.org/"
xmlns:xsd1="http://soapinterop.org/xsd"
targetNamespace="http://soapinterop.org/"
>
21
WSDL is a standard
WSDL Extensors
XML document
XML Schema declarations uniquely identify extensor schemas
<?xml version="1.0" encoding=“UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
These standard
namespaces are
xmlns:mq="http://schemas.iona.com/transports/mq"
what make it WSDL
xmlns:fixed="http://schemas.iona.com/bindings/fixed"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://soapinterop.org/"
xmlns:xsd1="http://soapinterop.org/xsd"
targetNamespace="http://soapinterop.org/"
>
User defined
namespaces help
manage complexity
22
WSDL Extensors
XML Schema declarations uniquely identify extensor schemas
<?xml version="1.0" encoding=“UTF-8"?>
<definitions
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:mq="http://schemas.iona.com/transports/mq"
xmlns:fixed="http://schemas.iona.com/bindings/fixed"
xmlns:tns="http://soapinterop.org/"
xmlns:xsd1="http://soapinterop.org/xsd"
targetNamespace="http://soapinterop.org/"
>
23
WSDL Extensors
SOAP namespaces
XML Schema declarations uniquely identify extensor
schemas to
are referenced
use SOAP-based
<?xml version="1.0" encoding=“UTF-8"?>
<definitions
Web services
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:mq="http://schemas.iona.com/transports/mq"
xmlns:fixed="http://schemas.iona.com/bindings/fixed"
xmlns:tns="http://soapinterop.org/"
xmlns:xsd1="http://soapinterop.org/xsd"
targetNamespace="http://soapinterop.org/"
>
Other namespaces can
define alternate behavior,
such as other transports
and bindings
24
WSDL Extensors
WSDL Bindings define how messages are encoded on the wire
<binding name="SearchBinding" type="tns:CustomerService">
<soap:binding style="rpc“/>
<operation name="NameSearch">
<soap:operation soapAction="http://soapinterop.org/" style="rpc"/>
<input>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</input>
<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</output>
</operation>
</binding>
25
WSDL Extensors
Bindings define how messages are encoded on the wire
<binding name="SearchBinding" type="tns:CustomerService">
<soap:binding style="rpc“/>
<operation name="NameSearch">
<soap:operation soapAction="http://soapinterop.org/" style="rpc"/>
<input>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</input>
<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</output>
</operation>
</binding>
26
WSDL Extensors
SOAP binding extensors
allow specifying rules that
Bindings define how messages are encoded
wire binding,
governon
thetheentire
such as rpc or document
<binding name="SearchBinding" type="tns:CustomerService">
<soap:binding style="rpc“/>
style
<operation name="NameSearch">
<soap:operation soapAction="http://soapinterop.org/" style="rpc"/>
<input>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</input>
<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="http://soapinterop.org/"/>
</output>
</operation>
Operation extensors
allow specifying
per-operation rules,
</binding>
such
as soapAction,
or overriding style
Body extensors
allow specifying
per-message rules,
such as literal or
encoded use
27
WSDL Extensors
WSDL Ports define where and how messages are sent
<service name="SearchService">
<port name="SearchPort" binding="tns:SearchBinding">
<soap:address location=“http://my.host.com:9001/Search"/>
</port>
</service>
port extensors allow
specifying transport
address information, as
well as protocol
information (e.g., http)
28
What about Existing MQ Bindings?
• Not many existing MQ Services use SOAP, or even XML
• Critical services not changing overnight
• Existing Application protocol must be followed
Example Request
01 CUSTOMER-SEARCH.
05 FIRST_NAME PIC X(25).
05 LAST_NAME
PIC X(25).
05 ZIP-CODE
PIC X(5).
Example MQ Configuration
QMgr cssys1
QName request_q
ReplyQ reply_q
The messages should be non-persistent
reply msg correlid will have request msg id
Example Reply
01 CUSTOMER-SEARCH-RESULTS.
05 STATUS.
10 RESULT-CODE PIC 9(5).
10 MESSAGE
PIC X(25).
05 RESULT-COUNT
PIC 9(2).
05 CUSTOMER-RECORDS OCCURS 25 TIMES
10 FIRST-NAME PIC X(25).
10 LAST-NAME
PIC X(25).
10 MIDDLE-INITIAL
PIC X.
10 ADDRESS
15 STREET-ADDRESS
PIC X(50).
15 CITY
PIC X(25).
15 STATE
PIC XX.
15 ZIP-CODE
PIC X(5).
10 HOME-TELEPHONE PIC X(10).
10 ACCOUNT-TYPE
PIC X.
88 PLATINUM VALUE 'P'.
88 GOLD VALUE 'G'.
88 STANDARD VALUE 'S'.
29
Fixed Format Binding
<binding name="SearchFixedBinding" type="tns:CustomerService">
<fixed:binding/>
<operation name="NameSearch">
<fixed:operation discriminator="discriminator"/>
<input>
<fixed:body>
<fixed:field name="discriminator"
fixedValue="01"
bindingOnly="true"/>
<fixed:field name="FirstName" size="25"/>
<fixed:field name="LastName" size="25"/>
</fixed:body>
</input>
<output>
<fixed:body>
<fixed:sequence name="return">
<fixed:sequence name="item" occurs="100">
<fixed:field name="FirstName" size="25"/>
<fixed:field name="LastName" size="25"/>
<fixed:field name="Street" size="25"/>
<fixed:field name="City" size="25"/>
<fixed:field name="State" size="25"/>
<fixed:field name="ZIP" size="25"/>
</fixed:sequence>
</fixed:sequence>
</fixed:body>
</output>
</operation>
</binding>
Fixed binding extensors
allow specifying rules that
govern the entire binding,
such character set
Fixed Format Binding
<binding name="SearchFixedBinding" type="tns:CustomerService">
<fixed:binding/>
<operation name="NameSearch">
<fixed:operation discriminator="discriminator"/>
<input>
<fixed:body>
<fixed:field name="discriminator"
fixedValue="01"
bindingOnly="true"/>
<fixed:field name="FirstName" size="25"/>
<fixed:field name="LastName" size="25"/>
</fixed:body>
</input>
<output>
<fixed:body>
<fixed:sequence name="return">
<fixed:sequence name="item" occurs="100">
<fixed:field name="FirstName" size="25"/>
<fixed:field name="LastName" size="25"/>
<fixed:field name="Street" size="25"/>
<fixed:field name="City" size="25"/>
<fixed:field name="State" size="25"/>
<fixed:field name="ZIP" size="25"/>
</fixed:sequence>
</fixed:sequence>
</fixed:body>
</output>
</operation>
</binding>
Fixed operation extensors
optionally allow specifying
a discriminator so that the
message type can be
determined
Fixed body extensors
define how each field is
written to the buffer to
comply with the existing
application protocol
30
31
MQ Port Extensor
MQ ports are indicated by the mq port extensor,
and often use fixed bindings, but any Artix binding
can be used, including SOAP
<service name="SearchService">
<port name="SearchPort" binding="tns:SearchFixedBinding">
<mq:client QueueManager="MY_DEF_QM"
QueueName="MY_FIRST_Q"
AccessMode="send"
ReplyQueueManager="MY_DEF_QM"
ReplyQueueName="REPLY_Q"
CorrelationStyle="messageId copy“
/>
</port>
</service>
Message correlation for
request/reply operations
are handled using simple
declarations on the port
mq ports addressing
information is richer to
reflect the richness of the
underlying middleware
(this is a simple example)
Building Reliable Web Services
33
Locator – WSDL-based Naming Service
 Dynamic, high performance service registration
 Automatic service lookup adapts to:
 Machine failures
 New service instances
 Site/server reconfiguration
 Services automatically registered with
the Locator upon start-up
 Multiple instances of the same service can be
registered to support load balancing and failover
 Related specification: WS-Addressing
34
Reliable Web Services
Fault Tolerant, Load Balanced Server Pools
.NET, Web services
application or IIS/JSP
Technical Need:
– Fault-tolerant, reliable Web
service providers
(2) Lookup
Locator
Support in Artix:
(3) Invoke
– Locator Service
• Service Discovery
• Multiple Servers – Same
Service
• Load balancing, fault
tolerance
(1) Publish
Artix Enabled
Server Pool
35
Reliable Web Services
Session Management
.NET, Web services
application or IIS/JSP
Technical Need:
– Stateful client / server interaction
– Context management
(2) Lookup
Locator
– Related specification: WS-CAF
(3) Invoke
Support in Artix:
– Locator Service
• Service Discovery
Session
management
interceptor
plug-ins
(1) Publish
• Session manager plug-in provides
session context across calls and
instance policies
Artix Enabled
Server
36
Reliable Web Services
Scalable Infrastructure
.NET, Web services
application or IIS/JSP
Technical Need:
– Scale to support 1000’s
of clients
(2) Lookup
Locators
– Configure servers
independently
(3) Invoke
Support in Artix:
– Locator Service can be
distributed and federated
• Request not found local
– fetch upstream,
cache locally
• Support for fan up and
fan down configuration
(1) Publish
Locator can be
federated like
‘DNS’ servers
Artix Enabled
Server
37
Reliable Web Services
System Recovery
.NET, Web services
application or IIS/JSP
Technical Need:
(2) Lookup
– Require 24 x 7 operations
– Locator Host fails or the Locator
service is killed - system must
recover without restarting the
servers
Locator
(3) Invoke
Support in Artix:
– Locator can recreate the
pre failure state from the
running endpoints
– Running servers will not
need to be restarted
(1) Publish
On restart of
Locator, state
rediscovery can be
enabled, which
recreates active
state
Artix Enabled
Server
38
.NET or Axis Client Services
.NET, Web services
application or IIS/JSP
Technical Need:
– Need session management,
failover and reliability with
.NET or AXIS Web services
(2) Lookup
Locator
(3) Invoke
Support in Artix:
– Locator Service
• Artix .NET plug-in and AXIS
plug-in for managing the
lookup & forward interaction
(1) Publish
Artix Enabled
Server
Secure Web Services
40
Secure Web Services
Wire Level Security
.NET, Web services
application or IIS/JSP
Technical Need:
– HTTP wire level security
Support in Artix:
(2) Lookup
Locator
– Support for wire level encryption
(SSL, HTTPS)
– Also, support for wire level
security of other middleware
transports (CORBA, Tuxedo,
Tibco, MQ)
(3) Invoke
(1) Publish
Artix Enabled
Server
41
Secure Web Services
Authentication
.NET, Web services
application or IIS/JSP
Technical Need:
– Access control and
authentication to secured
services
(2) Lookup
Locator
(3) Invoke
Support in Artix:
– IONA Security Framework (ISF)
is used for integration with
standard access control
systems (Netegrity, LDAP)
(1) Publish
– No code changes to
the application
– Related Spec: WS-Security
Artix Enabled
Secure Server
Netigrity
or
LDAP
Artix security plug-in
IONA Security
Framework
Transactional Web Services
43
Transactional Web Services
Maintaining Data Consistency
.NET, Web services
application or IIS/JSP
Problem
– But what about middleware that does not
support transactions like Web services
– Related specifications:
WS-CAF, WS-T, WS-C
Invoke
Solution
– Artix Encompass can act as the
transaction coordinator
•
Any XA-Compliant resource can be
managed and listed in the transaction
•
Artix supports full commit and rollback
– Artix ships an extended version of OTS
which can also be placed subordinate to
other TP monitors
(XA)
(XA)
(XA)
ORACLE
DB2
MQ
Product Information
45
Middleware Interoperability
Middleware Consolidation
Enterprise Web Services
Mainframe Web Services
Bridges middleware
Consolidates aging middleware
Creates Web services
Exposes mainframe
technologies, eliminating
technologies that are
applications with enterprise
transactions as high
roadblocks that slow down
expensive to maintain and
features, that enable IT
performance Web services
innovation
support without business
assets to be re-used in
with minimal risk
interruption
service oriented computing.
Service
Discovery
WS - Security
Transaction
Management
Security
Management
Contract
Management
WSDL Service Contracts
Payload
Mapping
Protocol
Bridging
Artix
Platform
Routing
Security
Propagation
Adaptive Runtime Technology
Format Plug-Ins
Transaction
Propagation
Transport Plug-Ins
HTTP
IIOP
SSL
Tuxedo
Tibco
MQ
SOAP/XML
IIOP
FML
TibRV
MQ
Custom
Enterprise
Management
Development
Tools
Service
Registration
46
• Enterprise Web Services Platform
–
Build sophisticated service-oriented architectures (SOA) using Web
services technology
–
Extend beyond Web services, when necessary
•
Security, Reliability, Session management,
•
SOAP over multiple transports – MQ, IIOP, Tuxedo, Tibco
• Quickly create new Web service clients and servers
• “Web service enable” legacy systems
– And, incorporate them into the SOA
• Interoperate with systems created using
3rd party Web service toolkits
Summary
48
In Closing
 Standards have a long way to go to address the
concerns of mission-critical application integration
 IONA is addressing this gap NOW
 Using Artix developers can build secure, reliable,
transactional and fully interoperable Web services that
are ideal for mission-critical application integration
 Open for questions and comments
49
For More Information
On the Web:
www.iona.com/artix
Download the Service Oriented Integration - Strategy Brief
from www.searchWebservices.com
Technical articles:
http://www.iona.com/info/aboutus/IONAThink.htm
Emails:
Eric.Newcomer @IONA.com
Peter.Cousins @IONA.com
Phone:
1-800-672-4948