Marc Krisjanous

1
WebSphere and .Net Web Services Interoperability
E3131

• Marc Krisjanous
• WebSphere Pre-Sales Technical
• marckris_at_au1.ibm.com

2
Agenda

• Status of Web services standards
• New joint specification proposals to assure an
  interoperable base
• Web Services Interoperability Organization
• Examples and guidelines
• Demo of Interoperability between WebSphere and
  Windows.Net

3
Web Services

• Web Services are self-contained, modular
  applications that can be described, published,
  discovered, and invoked over a network

Service Requester
Service Providers
Company A
Open
Company C
Internet
Legacy Clients Web Clients
Open
Company B
Open
Services Registry
4
Key Technologies
Legacy Systems
WSDL Web Services Definition Language SOAP
Simple Object Access Protocol UDDI Universal
Description, Discovery Integration
Publish
Locate
Internet
Service Publisher
Service Requester
SOAP
SOAP
SOAP
Bind
SOAP
WSDL Reference
Service Registry
UDDI
5
Status of Web Services Standards

• XML 1.0
• W3C recommendation
• XML Schema
• W3C recommendation
• Simple Object Access Protocol (SOAP)
• W3C draft spec, not final recommendation
• Final recommendation expected this spring
• Web Services Description Language (WSDL)
• W3C working group formed in February.
• WSDL 1.1 (from IBM and Microsoft) is de facto
  standard in the meantime
• Universal Description Discovery and Integration
• UDDI.org working on V3 of UDDI spec
• Then will be turned over to a formal standards
  body

6
The Evolving Standards Stack
7
Standardizing additional parts of the stack

• Starting with security
• The major requirement from early adopters and
  those planning to deploy Web services
• Worked together with Microsoft to publish two
  documents on April 11, 2002
• WS-Security Specification
• Verisign was also a coauthor
• Web Services Security Strategy and Roadmap

8
WS-Security

• This specification defines a foundational set of
  SOAP extensions that can be used when building
  secure Web services to implement integrity and
  confidentiality.
• It describes how to exchange signed and encrypted
  messages in a Web services environment.
• WS-Security works with multiple security
  approaches PKI, Kerberos, SAML, XrML,
  Basic/Digest, SSL, etc.
• This is the first specification in a planned
  series that will help address end-to-end Web
  services security including federation across
  security domains.
• WS-Security extends and subsumes previous Web
  services security specifications published
  individually and jointly by Microsoft and IBM.

9
Goals of joint security announcement

• WS-Security will jumpstart the standardization
  program for Web services security in the same way
  that SOAP jumpstarted Web services itself.
• Web services standards in general are being
  created in a composable way, and therefore so too
  should those that focus on security
• Through the introduction of this security
  architecture for Web services we hope to
• enable customers to easily build interoperable
  solutions using heterogeneous systems, and
• enable enterprises to protect their investments
  and assets as business processes become
  increasingly recast as Web services.

10
Web Services Interoperability Organization

• Industry initiative for Web services
• Open to any organization committed to Web
  services
• Promote and accelerate adoption, deployment
• Focused on promoting Web service interoperability
  
• Across platforms, applications, and programming
  languages
• Promote a common, clear definition for Web
  services
• Promote customer adoption deployment
• Integrate specifications from standards bodies
• Implementation guidance tools for customers
  building and deploying Web services

11
WS-I.org Deliverables

• Profiles
• Named groups of specifications at given version
  levels with conventions about how they work
  together
• Implementation Scenarios
• Solution scenarios based on customer requirements
• Test suites and supporting materials
• Sample solutions
• Implementation aids
• Conformance testing tools
• Supporting documentation and white papers

12
WS-I.org Profiles

• Provide guidance on general purpose Web services
  functionality
• Address interoperability at a level above
  specification-by-specification
• Supporting specifications and standards will be
  considered from multiple industry sources
• Profile development will reflect market needs and
  requirements

Profile
Links to Specs
ConventionsandBestPractices
13
WS-I.org Scenarios

• Scenarios
• Within a given Profile, a set of simple Web
  services are defined
• used to exercise a specific set of functionality
  within a profile
• Test Input and Resources
• Identified issues become test/compliance cases
  for future activity, and are incorporated into
  supporting tools
• Implementation guidance and source code will be
  available
• Guidance is consistent across all the WS-I
  Working Groups

14
WS-I.org Test Activity

• Test Materials
• Developed by Working Groups to test Web service
  implementations and detect errors
• Final materials available to all Web service
  developers
• Based on the Profiles adopted by the organization
• Sample Applications
• Working Group members implement the scenarios and
  identify interoperability issues
• Implementations are developed with multiple
  platforms, tools, and programming languages
• Source code for the implementations will be
  available
• Provide implementation guidance to Web service
  developers

15
WS-I.org Test Activity

• Test Resources
• Monitoring tools (Sniffer) will be provided to
  collect Web service message traces and generate a
  log for subsequent analysis
• Analysis tools (Analyzer) examine traces for
  correctness and use of recommended practices
• Output of analysis tools is used as a basis for
  WS-I compliance claims
• Tools are intended for use by any Web service
  developer
• Source code will be available

16
SOAP Interoperability

• Interoperability test results for 35 SOAP
  implementations, including those by all the major
  vendors and open source groups
• http//www.apache.org/rubys/ApacheClientInterop.h
  tml
• IBM uses (and contributes to) the apache SOAP
  project Axis
• Microsoft represented by SOAP Toolkit
• All interoperability tests successful between the
  two
• However, problems can be found passing complex
  structures
• Avoid nesting of arrays and structures in a given
  RPC parameter
• Axis supports some Java-specific encoding
  extensions
• Avoid using these ex. HashMap, JavaBean, Vector

17
WSDL Interoperability

• WSDL interoperability amounts to tools
  interoperability
• Publish WSDL from one tool
• Consume that WSDL in the other tool
• Generate Web service client Stubs (proxies)
• Generate skeleton Web service implementation
• Tools
• IBM WebSphere Application Developer (WSAD)
• Microsoft Visual Studio.Net

18
Tool Specifics

• Document versus RPC style SOAP interaction
• Visual Studio.Net defaults to Document Style
• This is a .Net Common Language Runtime default
• Can only be overridden by coding SoapRpcMethod
  in the C or VB source
• WSAD focuses on RPC style
• Wizards create RPC Web service
• Can consume WSDL for document style Web service
  and create stubs
• Tool Interoperability summary
• Use WSAD 4.0.2 and GA Visual Studio.Net for best
  results
• In most cases, no problems
• Follow SOAP guidelines (previous slide)
• Follow other general guidelines (following slide)

19
General Guidelines

• SOAP Specification allows custom encoding styles
  (mappings into XML) for basic data types plus
  arrays and structures, beyond the standard SOAP
  encoding
• Custom styles are not interoperable
• Better to use Document Style interface and
  provide a full XML schema for the data you need
  to pass.
• Let your partner decide how to map the XML into
  programming language objects
• WSDL specifies four interaction models
• Request-response
• One-way
• Solicit-Response
• Notification
• Use only Request-Response or One-way since others
  are not fully specified and may be dropped from
  the final W3C WSDL specification

20
A Typical .Net/WebSphere Topology
Web Service Wrapper
ASP.Net
EJBs
Web Browser Client
IIS Server
WebSphere Application Server
21
Interoperability Demo

• Create Web service and Web service client
• Use IBM tools to build web service
• Use Microsoft tools to build client
• Export and import of WSDL between development
  tools

22
Demo
23
Conclusion

• IBM and Microsoft are cooperating to ensure Web
  services are interoperable
• Cooperating on new specification to standardize
  needed parts of the stack
• Founding the Web Services Interoperability
  Organization to to provide guidance, profiles and
  test suites
• Testing with each others execution environments
  and tools
• WS-I will help interoperability
• Check WS-I.org for White Papers, guidelines and
  test cases
• Stay within a few simple guidelines to ensure the
  widest interoperability for your Web services