490 likes | 636 Views
Using Web Services to Build Mission Critical Integration Solutions. 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
E N D
Using Web Services toBuild Mission Critical Integration Solutions
Agenda Eric NewcomerCTO, IONA Technologies • Introduction • Requirements for mission critical application integration • Web services standards update • Gap analysis Peter CousinsTechnical Director, IONA Technologies • Introduction to Artix • Building secure, reliable, transactional, multi-transport Web services • Use cases
SystemCostand Complexity System Life Worldwide presence • Global HQ in Dublin, Ireland • US HQ in Massachusetts IONA Drives Down the Cost and Complexity of Enterprise IT Customers include world’s largest firms • 80% of Global Telecom • 70% of Financial Services in Global 100 • Blue Chip Partners TheIONA Benefit Our vision extends beyond integration • We improve our customers’ return on current assets • While driving an architecture for future change • Making their infrastructure technology and vendor independent
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 Servicesand co-author of Principles of TransactionProcessing • 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 (WS-CAF) submitted to OASIS
Web Services Offer Great Promise “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 • Web services are highly suitedto 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 therequirements of users • Security, reliability and availability are still only partially addressed • Promise of multi-protocol mappings unfulfilled
The “Web Services Gap” Mission-CriticalIntegration Requirements 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 • Heterogeneous applications and middleware platforms • Enterprise Features: • Scalability • Reliability • Performance • Desire for Flexibility: • Architecture • Tools
The “Web Services Gap” Mission-CriticalIntegration Requirements 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 in balance and leaderless • Heterogeneous applications and middleware platforms • Enterprise Features: • Scalability • Reliability • Performance • Desire for Flexibility: • Architecture • Tools WHAT IS NEEDED ? Reliable, secure, transactional, stateful, multi-transportWeb Services Ideal formission-criticalapplication integration
Competing Standards Bodies Standards “Alphabet Soup” • Lots of activity • Not enough progress • Competing standards • Vendor agendas • Competing bodies • Slow pace Too many to list all Others ?? Web ServicesDistributed Management (WSDM) Management BPEL4WS Orchestration WS-CAF, WS-T & WS-C Transactions XML Encryption, XKMS,XRML, WS-Security, SAML Security WS-Reliability,WS-ReliableMessaging Reliable Messaging WSDL Service Contract UDDI Look-Up & Discovery SOAP Message Payload
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
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 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 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 Logical Contract Physical Contract
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
Creating Your WSDL (or rather ESDL)Development Cycle Code Generation Tools wsdl2cpp wsdl2corba wsdl2java ClientProxy Code + OR Server StubCode ServiceDesigner Security – wire level and / or authentication Routing –Add decision logic to the Web service Tibco CORBA Tuxedo MQ HOST Transports Bindings – SOAP over HTTP, IIOP, MQ, etc.. TibRVMsg. Def. TibRVMsg. Def. COBOLCopyBooks MessageDefinition IDL Transactions – work with MTS, OTS, MQ, Tuxedo transactions Reliability – Failover, scalability, state management
Code Generation • Tools for generating C++, CORBA and Java Web service proxies and stubs • Quickly build new client and server Web service applications • 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 ClientProxy Code OR Server StubsCode Code Generation Tools wsdl2cpp • Generates C++ proxies and stubs from WSDL contract wsdl2corba • Generates CORBA proxies and stubs from WSDL contract wsdl2java • Generates Java proxies and stubs from WSDL contract
WSDL PortType Operation Logical Contract Message Part XML Data Type Binding Physical Contract Port Service Multi-Transport Web ServicesDevelopment Middleware transports are specified in Design Studio • One or more transport bindings • HTTP/S, MQ, IIOP, Tuxedo, Tibco • One or more ports for each transport binding • e.g. HTTP ports are URLs and IP addresses • e.g. MQ ports are queue names • Binding information defined in the physical contract • Bindings are defined as WSDL extensors Run-Time handles: • Synch/Asynch bridging • Payload mapping • Protocol bridging Bindings only involve the physical contract • They can be added and removed without affecting application code • Allows you to modify transport level configuration data at any time
Multi-Transport Web ServicesRun-Time View Web Service Providers Web Service Requestors SOAP HTTP/S HTTP/S SOAP WebService Run-Time Services .NET TUXEDO FML TUXEDO PayloadMapping Service Routing Service Registry Java Java TIBRV TIBCO TIBCO MQ Synch/Asynch Bridging Protocol Bridging Security MQ MQSeries MQSeries MQ C++ Discovery andLoad Balancing Transaction Management C++ AuthorizationAuthentication IIOP IIOP IIOP CORBA TransportPlug-Ins TransportPlug-Ins
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/" >
WSDL Extensors WSDL is a standard 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" 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/" > These standard namespaces are what make it WSDL User defined namespaces help manage complexity
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/" >
WSDL Extensors SOAP namespaces are referenced to use SOAP-based Web services 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/" > Other namespaces can define alternate behavior, such as other transports and bindings
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>
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>
WSDL Extensors SOAP binding extensors allow specifying rules that govern the entire binding, such as rpc or document style 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> Body extensors allow specifying per-message rules, such as literal or encoded use Operation extensors allow specifying per-operation rules, such as soapAction, or overriding style
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)
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 Example Reply 01 CUSTOMER-SEARCH.05 FIRST_NAME PIC X(25).05 LAST_NAME PIC X(25).05 ZIP-CODE PIC X(5). 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 TIMES10 FIRST-NAME PIC X(25).10 LAST-NAME PIC X(25).10 MIDDLE-INITIAL PIC X.10 ADDRESS15 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'. Example MQ Configuration QMgr cssys1QName request_qReplyQ reply_qThe messages should be non-persistentreply msg correlid will have request msg id
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
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> mq ports addressing information is richer to reflect the richness of the underlying middleware (this is a simple example) Message correlation for request/reply operations are handled using simple declarations on the port
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 beregistered to support load balancing and failover • Related specification: WS-Addressing
Technical Need: Fault-tolerant, reliable Web service providers Support in Artix: Locator Service Service Discovery Multiple Servers – Same Service Load balancing, fault tolerance Locator Reliable Web ServicesFault Tolerant, Load Balanced Server Pools .NET, Web services application or IIS/JSP (2) Lookup (3) Invoke (1) Publish Artix EnabledServer Pool
Locator Reliable Web ServicesSession Management .NET, Web services application or IIS/JSP Technical Need: • Stateful client / server interaction • Context management • Related specification: WS-CAF Support in Artix: • Locator Service • Service Discovery • Session manager plug-in provides session context across calls and instance policies (2) Lookup (3) Invoke Session management interceptor plug-ins (1) Publish Artix Enabled Server
Locators Reliable Web ServicesScalable Infrastructure .NET, Web services application or IIS/JSP Technical Need: • Scale to support 1000’sof clients • Configure servers independently 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 (2) Lookup (3) Invoke (1) Publish Locator can be federated like ‘DNS’ servers Artix Enabled Server
Locator Reliable Web ServicesSystem Recovery .NET, Web services application or IIS/JSP • Technical Need: • Require 24 x 7 operations • Locator Host fails or the Locator service is killed - system must recover without restarting the servers • Support in Artix: • Locator can recreate thepre failure state from therunning endpoints • Running servers will not need to be restarted (2) Lookup (3) Invoke (1) Publish On restart of Locator, state rediscovery can be enabled, which recreates active state Artix Enabled Server
Locator .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 • Support in Artix: • Locator Service • Artix .NET plug-in and AXIS plug-in for managing the lookup & forward interaction (2) Lookup (3) Invoke (1) Publish Artix Enabled Server
Secure Web ServicesWire Level Security .NET, Web services application or IIS/JSP • Technical Need: • HTTP wire level security • Support in Artix: • Support for wire level encryption (SSL, HTTPS) • Also, support for wire level security of other middleware transports (CORBA, Tuxedo, Tibco, MQ) (2) Lookup Locator (3) Invoke (1) Publish Artix Enabled Server
Locator Secure Web ServicesAuthentication .NET, Web services application or IIS/JSP • Technical Need: • Access control and authentication to secured services • Support in Artix: • IONA Security Framework (ISF) is used for integration with standard access control systems (Netegrity, LDAP) • No code changes to • the application • Related Spec: WS-Security (2) Lookup (3) Invoke (1) Publish Artix Enabled Secure Server NetigrityorLDAP Artix security plug-in IONA Security Framework
Problem But what about middleware that does not support transactions like Web services Related specifications: WS-CAF, WS-T, WS-C 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 MQ Transactional Web ServicesMaintaining Data Consistency .NET, Web services application or IIS/JSP Invoke (XA) (XA) (XA) ORACLE DB2
ServiceRegistration ServiceDiscovery WS - Security TransactionManagement SecurityManagement ContractManagement WSDL Service Contracts Enterprise Management DevelopmentTools PayloadMapping ProtocolBridging SecurityPropagation Routing TransactionPropagation Format Plug-Ins Transport Plug-Ins HTTP IIOP SSL Tuxedo Tibco MQ SOAP/XML IIOP FML TibRV MQ Custom Artix Platform Adaptive Runtime Technology Middleware Interoperability Middleware Consolidation Enterprise Web Services Mainframe Web Services Bridges middleware technologies, eliminating roadblocks that slow down innovation Consolidatesaging middleware technologies that are expensive to maintain and support without business interruption Creates Web services applications with enterprise features, that enable IT assets to be re-used in service oriented computing. Exposes mainframe transactions as high performance Web services with minimal risk
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
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
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