Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Application
Integration
What is Application Integration?
 Mechanism to allow different software to share, route,
or aggregate information
 Shari...
Why care about application integration?
 It improves the flow of information
 It reduces errors and friction in business...
Who Deals with Application Integration?
 Companies with heterogeneous internal systems
Accounting/
Finance
(Oracle)
Marke...
Who Deals with Application Integration?
 Companies that are exposing their systems to
business partners
Supplier
Supplier...
Study Case: Hershey ERP Integration
 1999: $112 million on ERP integration involving
software from SAP, Manugistics, and ...
How is application integration executed?
 Data-level
How is application integration executed?
 Application-level integration
Data-level Integration
 Applications share information by sharing databases
 Minimum needs to modify existing applicatio...
Application-level Integration
 Applications share information by exposing their
Application Programming Interfaces (APIs)...
Communication Middleware
 Communication Middleware helps applications to
interact to each others
 Hides complexities of ...
MOM Middleware Styles
 Message-oriented middleware (MOM)
 Asynchronous, peer based style of communication for
passing me...
RPC Middleware Styles
 Remote Procedure Call (RPC) middleware
 Synchronous, client/server based style of communication
...
Challenges with Traditional Middleware
 RPC Middleware uses tightly coupled connection
 MOM Middleware uses loosely coup...
Web Service to the rescue
Web Services promote several benefits that transform
application integration process less painfu...
W e b S e r v i c e s
Web Services
 Defining Web Services
 Why Web Services?
 Characteristics of Web Services
 Web Services Quick Study Case...
Defining Web Services
 Web Service is a service oriented application that
communicates over the Internet using XML
messag...
Why Web Services
Reviewing issues with traditional middleware:
 Does not support heterogeneity
 Does not work across the...
Characteristics of Web Services
 Web services provides an interface – a Web API
 Web services is typically registered
 ...
Web Service Study Case
 Kinko’s
 Google
 Amazon
 UPS
 Merrill Lynch
Web Services Technologies
 The Web
 Global interconnection
 XML (XML Schema, XSLT)
 Platforms & languages independent
...
SOA
 Service-Oriented Architecture
SOA (Continued…)
 SOA Patterns on Web Services
WSDL
 Web Services Descriptor Languages
 WSDL is an XML language that describes a Web
Service.
 WSDL is contract betwee...
WSDL (Continued…)
UDDI
 Universal Description, Discovery, and Integration
 UDDI provides a mechanism to publish and discover
Web services....
UDDI (Continued…)
SOAP
 Simple Object Access Protocol
 SOAP is an XML protocol used to communicate with
Web services
 SOAP provides a con...
SOAP (Continued…)
S O A P
Simple Object Access Protocol
Introducing SOAP
 Simple Object Access Protocol
 SOAP is a protocol used to exchange message between
SOAP applications o...
Why SOAP?
 Programming language independent
 Firewall friendly with HTTP Tunneling
 Appropriate/ better choice for appl...
SOAP Message
 SOAP Message is an instance of SOAP XML Document
 SOAP defined how messages can be structured and
processe...
SOAP Message
SOAP Message
SOAP Message
SOAP Message
SOAP Message
SOAP Nodes
 Types of SOAP Nodes
 SOAP Sender (generates & sends message)
 SOAP Receiver (receives & processes message)
...
SOAP Nodes - Intermediaries
 Auditing/ logging a message
 Storing the message for reliability
 Checking security creden...
SOAP’s Basic Structure
SOAP Envelope
 It is the primary, mandatory, and root of SOAP Message
 SOAP Envelope that does not follow the namespace ...
SOAP Envelope
SOAP Header
 SOAP Header contains useful information in decoding a
payload (from, to, service, action, etc)
 It is the f...
SOAP Header
 Two special attributes for SOAP Header
 mustUnderstand (do not process if you do not
understand)
o mustUnde...
SOAP actor Attribute
 Actor attribute is used in combination with XML
namespace to determine which code modules will
proc...
SOAP mustUnderstand attribute
 SOAP nodes must be able to process any header
block that’s marked as mandatory if they pla...
SOAP Header
SOAP Body
 It is a required element in a SOAP Message
 There must be 1 or more SOAP Body elements in the
body
 Body blo...
SOAP Fault
 It is contained inside SOAP Body
 It is a mechanism to handle and report error “upstream”,
to the nodes earl...
SOAP Fault
Faults are usually caused by improper message
formatting, version mismatch, trouble processing
a header, and a...
<faultcode> element
 <faultcode> may use any of for standard SOAP fault
code to identify an error
 Client (receiver is u...
<faultstring> element
 It is a mandatory element when a <fault> element
exists.
 It should provide a human-readable desc...
<faultactor> and <detail> elements
 <faultactor> indicates which role in the node that
encountered the error and generate...
SOAP Attachment
 SOAP Message may contain SOAP Attachments in any
data formats (ASCII/ Binary)
 SOAP Attachments are not...
SOAP Attachment
SOAP Message Exchange Patterns
 Messaging Exchange Patterns refers to the flows of
messages on the network
 One Way (Uni...
SOAP Messaging Modes
 Two types of SOAP Communication Models
 SOAP RPC/Literal mode
o Remote Procedural Call-based synch...
Document/Literal Mode (Messaging)
 SOAP Body contains any valid XML message (such
as purchase order)
 Maybe respond imme...
RPC/Literal Mode
 Suitable for synchronous processing (bidirectional MEP)
 It enables SOAP message to model a call to pr...
SOAP RPC vs. SOAP Document
 SOAP RPC Mode
 More intuitive more developer to use
 Message can be validated according to ...
Security Issues
 Authentication
 Verifying identity of user/application
 Authorization
 Determine the authenticated en...
Securing SOAP Messages
 Secure Sockets Layer/ Transport Layer Security
(SSL/TLS)
 Hypertext Transfer Protocol Secure (HT...
Utilizing SOAP Header for Security Use
 Provide login information
 Make sure it’s encrypted
 Provide a security token
...
SOAP with Apache Axis
 Apache eXtensible Interaction Systems
 A middleware engine that processes SOAP Message
 Open-sou...
Axis as Core Web Services Solution
 Axis Programming Model
 Creating the Service & Client
 Axis Deployment Model
 Easy...
Roles of Axis SOAP Engine
Roles of Axis SOAP Engine
 Receive a message from transport
 Check the SOAP semantics
 Process the SOAP Headers
 De-se...
W S D L
(Web Services Description Language)
Introducing WSDL
 Web Service Descriptor Language
 A document that describes the service a Web Service (It tells
you how...
Introduction to WSDL
 It’s not simple due to designer’s intention to create IDC
(Interface Definition Language) for Web S...
Role of WSDL in Web Service
 Provides what kind of services that are available
 Provides the location of a Web services
...
WSDL Basic Structure
 It adheres WSDL XML Schema
 Important elements in a WSDL document:
Elements: Category:
<definition...
WSDL Root Element
 <definitions>
 Root of WSDL document
 Name attribute is optional. It’s just to provide a name for th...
WSDL Declaration
 <types>
 Serves as a container for defining any data types that are not
described by XML schema built-...
WSDL Declaration
 <import>
 It provides a way to make other elements from other WSDL
documents available in to the prese...
WSDL Abstract Interface
 <message>
 It describe the payload of a message used by web service
 It can also describe the ...
WSDL Abstract Interface
 The <message> for RPC-style
<message name=“GetBookPriceRequest”>
<part name=“isbn” type=“amz:isb...
WSDL Abstract Interface
 The <message> for Document-Style
<types>
<xsd:schema targetNamespace=“http://…”>
<xsd:import nam...
WSDL Abstract Interface
 <portType>
 It defines the abstract interface of Web Service, similar to
Java interface
 <oper...
WSDL Abstract Vs. Java Interface
WSDL
<portType name=“BookQuote”>
<operation name=“GetBookPrice”>
<input name=“ticker” mes...
WSDL Implementation
 <binding>
 Maps an abstract <portType> to a set of concrete protocol
(SOAP and HTTP), messaging sty...
WSDL Implementation
 <service>
 Service element contains one/more <port> elements
 Each <port> represents a different w...
UDDI
Universal Description, Discovery, and
Integration
UDDI
 Enables the businesses providing e-commerce
services to register their information.
 It becomes a B2B market place...
UDDI Registries
 It is the implementation of UDDI Specification
 It is a database that supports a set of standard data
s...
UDDI Registries
 Public Registries
 Available for everyone to publish/query business and service
information
 UDDI Busi...
Interacting with a UDDI Registry
 Graphical User Interface
 Microsoft
 IBM
 HP
 Systinet
 SAP
 Programmatic Interfa...
Business’ Uses of UDDI Registry
1. White pages level – to publish business’ basic
business information such as company nam...
UDDI Data Structures
 <businessEntity>
 <publisherAssertion>
 <businessService>
 <bindingTemplate>
 <tModel>
UDDI Data Structures
<businessEntity>
 It represents the primary information about business
such as:
 contact info
 categorization of the bu...
<publisherAssertion>
 It represents active business relationships with other business
 UDDI Registry will not make the r...
<businessService>
 It represents the service of business in a logical manner
 It’s merely a logical representation of th...
<bindingTemplate>
 It points to technical descriptions and access URLs of the
service
 tModel
 Access Point/ End Point
...
<tModel>
 It represents a description of a particular specification
or behavior of the service that is managed
somewhere ...
UDDI Programming API
 Inquiry API
Consists of XML messages defined using UDDI schema which can
be used to locate informat...
Inquiry API
 <find_business>
 <find_relatedBusiness>
 <find_service>
 <find_binding>
 <find_tModel>
 <get_businessDe...
Publishing API
 <save_business>
 <set_publisherAssertions>
 <add_publisherAssertions>
 <save_service>
 <save_binding>...
Examples of <find_service>
 Request SOAP
<uddi:find_service>
<findQualifiers>
<findQualifier>
caseSensitiveMatch
</findQu...
Examples of <find_service>
 Response SOAP
<serviceList operator="IBM" xmlns="urn:uddi-org:api_v2">
<serviceInfos>
<servic...
Limitations of UDDI
 UDDI has limited information model compared to
ebXML Registry/ Repository
 UDDI is just a registry,...
AXIS
WSDD and BeanSerializer
Limitations of Axis JWS
 It is intended for a simple web services
 You cannot use packages
 You cannot discover error u...
Axis WSDD
 Axis Web Service Deployment Descriptor
 XML-based that describe the process of the web
services deployment an...
Benefits from using Axis WSDD
 You write a regular Java class
 WSDD can provide alias/mapping to the services
 You can ...
Example of WSDD (Deployment)
<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/w...
Example of WSDD (Undeployment)
<undeployment
name="UndeploymentTemperatureConverterService"
xmlns="http://xml.apache.org/a...
BeanSerializer
 You can include custom Java object as parameter or
return value on a method call
 You are registering th...
Example of WSDD with BeanSerializer
<deployment
xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org...
How to Deploy and Undeploy?
 Deploying web services
java org.apache.axis.cleint.AdminClient
-l http://localhost:8080/Huma...
How to Deploy and Undeploy?
1. Compile your classes
2. Deploy your application by placing it into Tomcat’s
WEB-INF folder
...
JAX-RPC
Introducing JAX-RPC
One of JAX-RPC features is to provide a way for
client to invoke a method remotely
It can be used by...
Generated Stubs
 Stubs are Java classes/objects provides implementation codes
to communicate to your Web Services functio...
Generated Stubs (Deployment)
Generated Stubs (Run Time)
Generated Stubs
 Sample Codes
// 1. Instantiate TemperatureConverterServiceLocator as a
// TemperatureConcerterService
Te...
DII (Dynamic Invocation Interface)
 No stub is being used . You manually need to program
what the stub is doing for you.
...
DII (Dynamic Invocation Interface)
 JAX-RPC Interfaces
 javax.xml.rpc.Service
o You need this to create “virtual service...
DII (Dynamic Invocation Interfaces)
 Sample Codes:
// In order to create a service type object, we need to use ServiceFac...
DII (Dynamic Invocation Interfaces)
 Side Notes:
 With DII, there is no specific java data type provided when
you send d...
SAAJ & JAXM
SAAJ
 SOAP with Attachments API for Java
 API-based SOAP toolkit that models structure of
SOAP Messages
 SAAJ is used t...
SAAJ Structures
JAXM
 Java API for XML Messaging
 It is used to send pure XML document from one node
to another without calling methods
...
JAXM
 Not part of J2EE specification
 Rejected by major J2EE vendors (BEA and IBM)
 Overlap capabilities with other mes...
Programming Steps
 Create SOAPConnection using SOAPConnectionFactory
 Create SOAPMessage using MessageFactory
 Create r...
Exercise
Exercise
 Purchase Order
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
xmlns:soapenv=”http://schemas.xmlsoap.o...
Exercise
 Confirmation
<?xml version="1.0" encoding="UTF-8"?>
<soap-env:Envelope xmlns:soap-
env="http://schemas.xmlsoap....
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Java Web Service - Summer 2004
Prochain SlideShare
Chargement dans…5
×

Java Web Service - Summer 2004

504 vues

Publié le

Slides I developed in Summer 2004 to discuss related underlying Java Web Services technology.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Java Web Service - Summer 2004

  1. 1. Application Integration
  2. 2. What is Application Integration?  Mechanism to allow different software to share, route, or aggregate information  Sharing, routing, or aggregating information among application is fundamental to business process
  3. 3. Why care about application integration?  It improves the flow of information  It reduces errors and friction in business process  It helps people get access to information easily  It HELPS your business.
  4. 4. Who Deals with Application Integration?  Companies with heterogeneous internal systems Accounting/ Finance (Oracle) Marketing (Microsoft) Operation (SAP) Human Resources (JD Edwards) Information Systems
  5. 5. Who Deals with Application Integration?  Companies that are exposing their systems to business partners Supplier Supplier Supplier Widget Corp. Distributors (US) Distributors (Asia) Distributors (Europe)
  6. 6. Study Case: Hershey ERP Integration  1999: $112 million on ERP integration involving software from SAP, Manugistics, and Siebel  2000: Problem arises on Order Processing, revenues drop 19%, blamed and systems problem. Promised to improve information flow  2002: Successfully integrating 95% of its business processing. Benefits:  Reduced costs and processing times  Near zero-defect production environment  Reduced packaging stock outs
  7. 7. How is application integration executed?  Data-level
  8. 8. How is application integration executed?  Application-level integration
  9. 9. Data-level Integration  Applications share information by sharing databases  Minimum needs to modify existing application  Useful to build data warehouse (extract and aggregate data to produce useful report)  Less costly and easier to execute than Application – level integration
  10. 10. Application-level Integration  Applications share information by exposing their Application Programming Interfaces (APIs).  Reduce code duplicates and maintain business rules  Good to use when applications perform transactional process  More difficult and expansive to execute than Data- level integration
  11. 11. Communication Middleware  Communication Middleware helps applications to interact to each others  Hides complexities of performing network communication  Programmers/developers concentrate on solving business problem  Figure of Communication Middleware
  12. 12. MOM Middleware Styles  Message-oriented middleware (MOM)  Asynchronous, peer based style of communication for passing messages  IBM WebSphereMQ, Microsoft MQ,Sonic Software SonicMQ, TIBCO Rendezvous  Two application using different MOM products cannot interact
  13. 13. RPC Middleware Styles  Remote Procedure Call (RPC) middleware  Synchronous, client/server based style of communication  Client invokes methods provided by the middleware that are routed/mapped to the server  More intuitive than MOM  Open Network Computing (ONC) RPC, Microsoft DCOM, Common Object Request Broker Architecture (CORBA), and Java RMI  It’s hard to find single RPC systems that all your programming languages
  14. 14. Challenges with Traditional Middleware  RPC Middleware uses tightly coupled connection  MOM Middleware uses loosely coupled connection, but harder to use than RPC styles  Most of RPC & MOM Middleware uses proprietary protocol  Traditional middleware solutions are expensive  Traditional middleware does not work across the Internet
  15. 15. Web Service to the rescue Web Services promote several benefits that transform application integration process less painful:  It solves the heterogeneous communication problems  It is easier to learn and implement  It is less expensive than the traditional middleware  It promotes the promise of reusability
  16. 16. W e b S e r v i c e s
  17. 17. Web Services  Defining Web Services  Why Web Services?  Characteristics of Web Services  Web Services Quick Study Cases  Web Services Technologies
  18. 18. Defining Web Services  Web Service is a service oriented application that communicates over the Internet using XML messages  Web Service is a Web resource that provides an API  Web Service is an application with a Web API
  19. 19. Why Web Services Reviewing issues with traditional middleware:  Does not support heterogeneity  Does not work across the Internet  Does not promote reusability  Hard to use  Expensive
  20. 20. Characteristics of Web Services  Web services provides an interface – a Web API  Web services is typically registered  Loosely couple connection
  21. 21. Web Service Study Case  Kinko’s  Google  Amazon  UPS  Merrill Lynch
  22. 22. Web Services Technologies  The Web  Global interconnection  XML (XML Schema, XSLT)  Platforms & languages independent  SOA  Describe a service (WSDL)  Advertise and discover a service (UDDI)  Communicate with other services (SOAP)
  23. 23. SOA  Service-Oriented Architecture
  24. 24. SOA (Continued…)  SOA Patterns on Web Services
  25. 25. WSDL  Web Services Descriptor Languages  WSDL is an XML language that describes a Web Service.  WSDL is contract between the service provider and service consumer  WSDL describes WHAT, HOW, and WHERE
  26. 26. WSDL (Continued…)
  27. 27. UDDI  Universal Description, Discovery, and Integration  UDDI provides a mechanism to publish and discover Web services.  UDDI provides a mechanism to categorize business and services  UDDI manages information about service types and service providers  UDDI conceptually is a yellow page, a white page, and a green page.
  28. 28. UDDI (Continued…)
  29. 29. SOAP  Simple Object Access Protocol  SOAP is an XML protocol used to communicate with Web services  SOAP provides a container for an XML message (a header and a body)  The SOAP body contains the message payload  SOAP message can be sent over any transport protocol
  30. 30. SOAP (Continued…)
  31. 31. S O A P Simple Object Access Protocol
  32. 32. Introducing SOAP  Simple Object Access Protocol  SOAP is a protocol used to exchange message between SOAP applications on the network (Intranet & Internet)  Utilizing text-based data representation using XML  Enabling communication between heterogeneous applications in a distributed environment
  33. 33. Why SOAP?  Programming language independent  Firewall friendly with HTTP Tunneling  Appropriate/ better choice for application-to- application communication (B2B)  Problems with current Client-Server Protocols (DCOM or RMI IIOP)  A format that is agreed by all major industry players that will work over the common internet protocols
  34. 34. SOAP Message  SOAP Message is an instance of SOAP XML Document  SOAP defined how messages can be structured and processed by software  Two types of SOAP Message: SOAP Request and SOAP Response  SOAP 1.1 specifies that a SOAP Message contains: o Envelope o Header o Body o Attachment
  35. 35. SOAP Message
  36. 36. SOAP Message
  37. 37. SOAP Message
  38. 38. SOAP Message
  39. 39. SOAP Message
  40. 40. SOAP Nodes  Types of SOAP Nodes  SOAP Sender (generates & sends message)  SOAP Receiver (receives & processes message)  SOAP Intermediary (can switch role as a sender & receiver)
  41. 41. SOAP Nodes - Intermediaries  Auditing/ logging a message  Storing the message for reliability  Checking security credentials  Encrypting and decrypting the message  Validating payload  Transforming the payload  Etc…
  42. 42. SOAP’s Basic Structure
  43. 43. SOAP Envelope  It is the primary, mandatory, and root of SOAP Message  SOAP Envelope that does not follow the namespace is considered to be invalid  It contains 2 possible children (SOAP-Header & SOAP Body)
  44. 44. SOAP Envelope
  45. 45. SOAP Header  SOAP Header contains useful information in decoding a payload (from, to, service, action, etc)  It is the first immediate child element of a SOAP Envelope and it has to be a namespace qualified  It may contain 0/more optional child elements commonly called as “header block”  SOAP specification defines rules by which header block must be processed in the message path
  46. 46. SOAP Header  Two special attributes for SOAP Header  mustUnderstand (do not process if you do not understand) o mustUnderstand=“0” | “1”  actor (determines which code modules will process the particular header block) o actor=http://www.sjsu.edu/validateStudent
  47. 47. SOAP actor Attribute  Actor attribute is used in combination with XML namespace to determine which code modules will process the particular header block  Process:  A node receives a SOAP message  The node checks if it has a role designated by the actor attribute in the header block  If yes, choose the correct module to process the header block  Else, ignore the SOAP header block
  48. 48. SOAP mustUnderstand attribute  SOAP nodes must be able to process any header block that’s marked as mandatory if they play the role specified by the actor attribute  Understand means the node must recognize the header block by its XML structure and know how to process it  If a node fails to understand a mandatory header block, it must generate SOAP fault and discard the message.
  49. 49. SOAP Header
  50. 50. SOAP Body  It is a required element in a SOAP Message  There must be 1 or more SOAP Body elements in the body  Body block can contain: • Information defining the RPC Call • Business document in XML • SOAP Fault for reporting error/status information
  51. 51. SOAP Fault  It is contained inside SOAP Body  It is a mechanism to handle and report error “upstream”, to the nodes earlier in the message path  It is generated by receivers, either an intermediary or the ultimate receiver of a message  A receiver is required to send a SOAP fault back to sender only if bidirectional MEP is used. SOAP faults are returned to the receiver’s immediate sender  If unidirectional MEP is used, the receiver should generate a fault and may store it somewhere, but it must not attempt to transmit it to sender
  52. 52. SOAP Fault Faults are usually caused by improper message formatting, version mismatch, trouble processing a header, and application specific error When fault message is generated, a SOAP Body must contain only a single fault element and nothing else. A <soap:fault> element must contain a <faultcode> element, a <faultstring> element, and optionally <faultactor> and <detail> elements.
  53. 53. <faultcode> element  <faultcode> may use any of for standard SOAP fault code to identify an error  Client (receiver is unable to process the SOAP message)  Server (Malfunctioned occurs in the receiver)  Mismatch (Receiver does not understand the namespace specified on the SOAP envelope)  MustUnderstand (Fail to recognize/understand the required header block)
  54. 54. <faultstring> element  It is a mandatory element when a <fault> element exists.  It should provide a human-readable description of the fault
  55. 55. <faultactor> and <detail> elements  <faultactor> indicates which role in the node that encountered the error and generated the fault. It’s an optional element  <detail> provides a detail information about the specific error
  56. 56. SOAP Attachment  SOAP Message may contain SOAP Attachments in any data formats (ASCII/ Binary)  SOAP Attachments are not part of SOAP Envelope  Each attachment is identified with a content-id or a content-location that can be refer by the SOAP Body block element
  57. 57. SOAP Attachment
  58. 58. SOAP Message Exchange Patterns  Messaging Exchange Patterns refers to the flows of messages on the network  One Way (Unidirectional)  Request/Response (Bidirectional)
  59. 59. SOAP Messaging Modes  Two types of SOAP Communication Models  SOAP RPC/Literal mode o Remote Procedural Call-based synchronous communication and tightly coupled using  SOAP Document/Literal mode (Messaging) o Document-driven communication and loosely coupled
  60. 60. Document/Literal Mode (Messaging)  SOAP Body contains any valid XML message (such as purchase order)  Maybe respond immediately (bidirectional MEP) or later (unidirectional MEP)  Suitable for asynchronous processing  Expose and exploit lower-level SOAP APIs to build the SOAP Message and send it
  61. 61. RPC/Literal Mode  Suitable for synchronous processing (bidirectional MEP)  It enables SOAP message to model a call to procedure/method with parameters and return values  An RPC Request message contains the method name and input parameters of the call  An RPC Response contains the return value and any output parameters  RPC mode is commonly used to expose traditional components as Web Service
  62. 62. SOAP RPC vs. SOAP Document  SOAP RPC Mode  More intuitive more developer to use  Message can be validated according to the schema  SOAP Document Mode  A more loosely coupled approach  A more peer to peer approach
  63. 63. Security Issues  Authentication  Verifying identity of user/application  Authorization  Determine the authenticated entity has permission to perform a specific action  Confidentiality  Preventing unauthorized access  Integrity  Preventing unauthorized modification  No repudiation  Provides a proof that a particular entity sent a message
  64. 64. Securing SOAP Messages  Secure Sockets Layer/ Transport Layer Security (SSL/TLS)  Hypertext Transfer Protocol Secure (HTTPSS)  Digital Signature
  65. 65. Utilizing SOAP Header for Security Use  Provide login information  Make sure it’s encrypted  Provide a security token  Digital certificates  Kerberos  Security Assertions Markup Language (SAML) authentication
  66. 66. SOAP with Apache Axis  Apache eXtensible Interaction Systems  A middleware engine that processes SOAP Message  Open-source implementation  Provides a Java-based SOAP implementation for developing Web Services  Pluggable to Tomcat/Servlet Engine  Portable for non-J2EE application (as long as JVM is available)
  67. 67. Axis as Core Web Services Solution  Axis Programming Model  Creating the Service & Client  Axis Deployment Model  Easy deployment toolkit  JWS and WSDD  Apache Axis SOAP Engine  Provides classes to create and parse SOAP Message
  68. 68. Roles of Axis SOAP Engine
  69. 69. Roles of Axis SOAP Engine  Receive a message from transport  Check the SOAP semantics  Process the SOAP Headers  De-serialize the message  Route the message to the service  Serialize the response  Send the response back over the transport
  70. 70. W S D L (Web Services Description Language)
  71. 71. Introducing WSDL  Web Service Descriptor Language  A document that describes the service a Web Service (It tells you how to use a Web Service)  It is used to specify the exact message format, Internet protocol, and address that a client must use to communicate with a particular web service  Contract between Web services providers and the clients  Combination of Microsoft SCL (SOAP Contract Language) and IBM NASSL(Network Accessible Service Specification Language)
  72. 72. Introduction to WSDL  It’s not simple due to designer’s intention to create IDC (Interface Definition Language) for Web Services that’s not tied to any specific protocol, programming language, or operating systems  It’s not specific to SOAP. It can be used to describe non- SOAP based Web Services.  It’s well suited for code generator which can read a WSDL document and generate a programmatic interface for accessing a web service
  73. 73. Role of WSDL in Web Service  Provides what kind of services that are available  Provides the location of a Web services  Provides what kind of data that client must provide to invoke a Web services  Defines the structure of the messages that a Web services sends and receives
  74. 74. WSDL Basic Structure  It adheres WSDL XML Schema  Important elements in a WSDL document: Elements: Category: <definitions> WSDL Root Element <types> <import> WSDL Declaration <messages> <portType> <operation> WSDL Abstract Interface <binding> <service> <port> WSDL Implementation
  75. 75. WSDL Root Element  <definitions>  Root of WSDL document  Name attribute is optional. It’s just to provide a name for the WSDL document  Namespace declarations <?xml version=“1.0” encoding=“UTF-8”?> <declarations name=“StockQuoteWS” targetNamespace=“http://…” xmlns:xsd=“http://…” xlmns:soapbind=“http://…”. ……………………..
  76. 76. WSDL Declaration  <types>  Serves as a container for defining any data types that are not described by XML schema built-in types  These data types will be used by <message> definition when declaring parts of messages <types> <xsd:schema targetNamespace=“http…”> <xsd:simpleType name=“ISBN”> <xsd:restriction base=“xsd:string”> <xsd:pattern value=“[0-9]{9}[0-9x]” </xsd:restriction> </xsd:simpleType> </xsd:schema> </types>
  77. 77. WSDL Declaration  <import>  It provides a way to make other elements from other WSDL documents available in to the present WSDL document  It’s a way to modularize the WSDL document  It’s a way to consolidate several WSDL documents that are maintained separately into one WSDL document <import namespace=“http://…./StockQuote” location=“http://…/wsdl”/> <import namespace=“http://…./Fortune500” location=“http://…/wsdl>
  78. 78. WSDL Abstract Interface  <message>  It describe the payload of a message used by web service  It can also describe the content of the header blocks/ <detail> fault elements that the payload could carry  It can be defined according to RPC-style or document-style messaging o RPC style <message> elements describe the payloads of the SOAP request and response message o Document style <message> elements refer to the top level elements in type definition
  79. 79. WSDL Abstract Interface  The <message> for RPC-style <message name=“GetBookPriceRequest”> <part name=“isbn” type=“amz:isbn”/> </message> <message name=“GetBookPriceResponse”> <part name=“price” type=“xsd:float”/> </message> <message name=“InvalidArgumentFault”> <part name=“error” element= “amz:InvalidIsbnFaultDetail”/> </message>
  80. 80. WSDL Abstract Interface  The <message> for Document-Style <types> <xsd:schema targetNamespace=“http://…”> <xsd:import namespace=“http://…/purchaseOrder” schemaLocation=“http://…/purchaseOrder.xsd” </xsd:schema> </types> <message name=“SubmitPurchaseOrderMessage”> <part name=“order” element=“amz:purchaseOrder” </message>
  81. 81. WSDL Abstract Interface  <portType>  It defines the abstract interface of Web Service, similar to Java interface  <operation>  Methods of the <portType>  Each <portType> may have one or more <operation> where each operation elements is defined as rpc or document-style web service method  Each operation uses one or more message definitions to define its input, output, faults
  82. 82. WSDL Abstract Vs. Java Interface WSDL <portType name=“BookQuote”> <operation name=“GetBookPrice”> <input name=“ticker” message=“GetBookPriceRequest”/> <output name=“price” message=“GetBookPriceResponse”> <fault name=“exception” message=“InvalidArgumentFault”> </operation> JAVA public interface BookQuote { public float getBookPrice(Strinbg isbn) throws InvalidArgumentException; }
  83. 83. WSDL Implementation  <binding>  Maps an abstract <portType> to a set of concrete protocol (SOAP and HTTP), messaging style (RPC or document) <binding name=“BookPrice_Binding” type=“BookQuote”> <soapbind:binding style=“rpc” <transport=“ http://schemas.xmlsoap.org/soap/http/ “> …… </binding>
  84. 84. WSDL Implementation  <service>  Service element contains one/more <port> elements  Each <port> represents a different web service and assigned to a specific <binding> <service name=“BookPriceService”> <port name=“BookPrice_Port” binding=“BookPrice_Binding”> <soapbind:address location=“http://…/BookQuote1”/> </port> <port name=“BookPrice_Failover_Port” binding=“BookPrice_Binding”> <soapbind:address location=“http://…/BookQuote2”/> </port> </service>
  85. 85. UDDI Universal Description, Discovery, and Integration
  86. 86. UDDI  Enables the businesses providing e-commerce services to register their information.  It becomes a B2B market place.  Initially started by IBM, Microsoft, and Ariba  Version released 1.0, 2.0, and 3.0  UDDI.org and OASIS (IBM, Microsoft, Sun, Oracle, Fujitsu, Systinet, etc)
  87. 87. UDDI Registries  It is the implementation of UDDI Specification  It is a database that supports a set of standard data structure defined by UDDI Spec  Data structure represents information about organizations (corporation, business units, government agencies, etc) and technical requirements for access to web services hosted by these organizations  It can be implemented using a relational database, LDAP services, and XML databases
  88. 88. UDDI Registries  Public Registries  Available for everyone to publish/query business and service information  UDDI Business Registry (UBR): Massive Public Registries o Operator Site (Microsoft, IBM, SAP, and NTT) o Synchronized process  Private Registries  Available for participating organizations or groups
  89. 89. Interacting with a UDDI Registry  Graphical User Interface  Microsoft  IBM  HP  Systinet  SAP  Programmatic Interface (JAX-R, UDDI4J, or other vendor API specific)  Communication model to UDDI Registry is using SOAP Messages
  90. 90. Business’ Uses of UDDI Registry 1. White pages level – to publish business’ basic business information such as company name, contact info, business identifier number, etc 2. Yellow pages level – to classify business based on its service category 3. Green pages level – to classify technical information describing its web services information
  91. 91. UDDI Data Structures  <businessEntity>  <publisherAssertion>  <businessService>  <bindingTemplate>  <tModel>
  92. 92. UDDI Data Structures
  93. 93. <businessEntity>  It represents the primary information about business such as:  contact info  categorization of the business  Identifiers  description of the business
  94. 94. <publisherAssertion>  It represents active business relationships with other business  UDDI Registry will not make the relationship visible to public until both parties has created similar <publisherAssertion> structure
  95. 95. <businessService>  It represents the service of business in a logical manner  It’s merely a logical representation of the services  <businessService> share many to many relationships with <businessEntity>
  96. 96. <bindingTemplate>  It points to technical descriptions and access URLs of the service  tModel  Access Point/ End Point  Note: it does not represent details of the service specification
  97. 97. <tModel>  It represents a description of a particular specification or behavior of the service that is managed somewhere else  WSDL reference is usually published here  It does not contain service specification directly, but it contains a link to some specification
  98. 98. UDDI Programming API  Inquiry API Consists of XML messages defined using UDDI schema which can be used to locate information about business  Publisher API Consist of XML messages which can be used to create, update, and delete information presents in the registry. Require authentication.
  99. 99. Inquiry API  <find_business>  <find_relatedBusiness>  <find_service>  <find_binding>  <find_tModel>  <get_businessDetail>  <get_businessDetailExt>  <get_serviceDetail>  <get_tModelDetail>
  100. 100. Publishing API  <save_business>  <set_publisherAssertions>  <add_publisherAssertions>  <save_service>  <save_binding>  <save_tModel>  <delete_business>  <delete_publisherAssertions>  <delete_service>  <delete_binding>  <delete_tModel>
  101. 101. Examples of <find_service>  Request SOAP <uddi:find_service> <findQualifiers> <findQualifier> caseSensitiveMatch </findQualifier> </findQualifiers> <uddi:name> Sumatra Widget Corporation </uddi:name> </uddi:find_service>
  102. 102. Examples of <find_service>  Response SOAP <serviceList operator="IBM" xmlns="urn:uddi-org:api_v2"> <serviceInfos> <serviceInfo serviceKey="uuid:12345-1234-e3433" businessKey="uuid:3456-s123-3435"> <name> Import Widget Services </name> </serviceInfo> </serviceInfos> </serviceList>
  103. 103. Limitations of UDDI  UDDI has limited information model compared to ebXML Registry/ Repository  UDDI is just a registry, not a repository
  104. 104. AXIS WSDD and BeanSerializer
  105. 105. Limitations of Axis JWS  It is intended for a simple web services  You cannot use packages  You cannot discover error until deployment  You cannot undeploy the web services  You cannot give an alias or mapping to the web services  You are exposing your source code
  106. 106. Axis WSDD  Axis Web Service Deployment Descriptor  XML-based that describe the process of the web services deployment and undeployment  Axis WSDD provides extra power and flexibility in deploying your web services
  107. 107. Benefits from using Axis WSDD  You write a regular Java class  WSDD can provide alias/mapping to the services  You can just deploy your Java classes  You can deploy all or limited Web API  You can undeploy without removing your classes  You can include Java Bean as parameter or return value
  108. 108. Example of WSDD (Deployment) <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HumanResourceSystem" provider="java:RPC"> <parameter name="className" value="com.xyz.service.HumanResourceSystem"/> <parameter name="allowedMethods“ value="getEmployeeByEmployeeId"/> </service> </deployment>
  109. 109. Example of WSDD (Undeployment) <undeployment name="UndeploymentTemperatureConverterService" xmlns="http://xml.apache.org/axis/wsdd/"> <service name="HumanResourceSystem"/> </undeployment>
  110. 110. BeanSerializer  You can include custom Java object as parameter or return value on a method call  You are registering the classes that will be serialized or deserialized WSDL will recognize and describe the Java object
  111. 111. Example of WSDD with BeanSerializer <deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"> <service name="HumanResourceSystem" provider="java:RPC"> <parameter name="className" value="com.xyz.service.HumanResourceSystem"/> <parameter name="allowedMethods" value="getEmployeeByEmployeeId"/> <beanMapping qname="myNS:Employee" xmlns:myNS="urn:xyz" languageSpecificType="java:com.xyz.valueobject.Employee"/> </service> </deployment>
  112. 112. How to Deploy and Undeploy?  Deploying web services java org.apache.axis.cleint.AdminClient -l http://localhost:8080/HumanResourceService/services/AdminService deployService.wsdd  Undeploying web services java org.apache.axis.cleint.AdminClient -l http://localhost:8080/HumanResourceService/services/AdminService undeployService.wsdd
  113. 113. How to Deploy and Undeploy? 1. Compile your classes 2. Deploy your application by placing it into Tomcat’s WEB-INF folder 3. Restart Tomcat 4. Deploy/Undeploy Web Services
  114. 114. JAX-RPC
  115. 115. Introducing JAX-RPC One of JAX-RPC features is to provide a way for client to invoke a method remotely It can be used by Java applications, servlet, jsp, and EJBs to exchange SOAP messages with remote Web Services on any platforms 2 kind of JAX-RPC approaches  Generated Stubs  DII (Dynamic Invocation Interface)
  116. 116. Generated Stubs  Stubs are Java classes/objects provides implementation codes to communicate to your Web Services functionalities (methods)  As a developer, you can just see the Web Service provider just as another regular java object.  When a stub’s method is invoked, the JAX-RPC stub sends a SOAP Request message to the Web Service endpoint that will return a SOAP Response message to stub  You don’t need to understand WSDL that much
  117. 117. Generated Stubs (Deployment)
  118. 118. Generated Stubs (Run Time)
  119. 119. Generated Stubs  Sample Codes // 1. Instantiate TemperatureConverterServiceLocator as a // TemperatureConcerterService TemperatureConverterService myService = new TemperatureConverterServiceLocator(); // 2. Get TemperatureConverter object from TemperatureConverterService TemperatureConverter converter = myService.getTemperatureConverter() // 3. Convert Fahrenheit to Celsius by using the method provided by the // TemperatureConverter object double result = converter.convertFahrenheitToCelsius(34.00);
  120. 120. DII (Dynamic Invocation Interface)  No stub is being used . You manually need to program what the stub is doing for you.  Use classes provided by JAX-RPC library  More complicated approach since you are not seeing the Web Service as a regular java object anymore  You need to know and understand more details about WSDL  Provides you more flexibility since you are not tied to the stubs
  121. 121. DII (Dynamic Invocation Interface)  JAX-RPC Interfaces  javax.xml.rpc.Service o You need this to create “virtual service” that represents the Web Service application (TemperatureConverterService) o You need this to get a Call type object  javax.xml.rpc.Call o You can the endpoint where the web service is located o This is a “virtual mapping” to your web service application component (TemperatureConverter.jws)
  122. 122. DII (Dynamic Invocation Interfaces)  Sample Codes: // In order to create a service type object, we need to use ServiceFactory ServiceFactory sfactory = serviceFactory.new Instance(); // Creating service type object from the factory Service service = sfactory.creaetService(…pass service info…); // Create a call object from service type object Call call = service.createCall(…pass port info…); // Set the endpoint property call.setTargetEndpoint(..pass endpoint info..); // Set the operation name call.setOperationName(..pass method…);
  123. 123. DII (Dynamic Invocation Interfaces)  Side Notes:  With DII, there is no specific java data type provided when you send data as parameters or receives data from Web Services  When you are invoking a connection with Web Service, you use the invoke method from the call object Object result = call.invoke(Object[] array);  Invoke method only take 1 parameter (Object array)  Invoke method will return a generic java Object
  124. 124. SAAJ & JAXM
  125. 125. SAAJ  SOAP with Attachments API for Java  API-based SOAP toolkit that models structure of SOAP Messages  SAAJ is used to manipulate SOAP Messages  “Attachment” part is still work in progress  It can be used independently (synchronous)  It can be used with JAX-RPC and JAXM
  126. 126. SAAJ Structures
  127. 127. JAXM  Java API for XML Messaging  It is used to send pure XML document from one node to another without calling methods  Supports synchronous and asynchronous communication mode  Approved by JCP
  128. 128. JAXM  Not part of J2EE specification  Rejected by major J2EE vendors (BEA and IBM)  Overlap capabilities with other messaging API (JMS and JavaMail)  Demand for JAXM is not enough in marketplace  Future of JAXM is uncertain  No tool to create WSDL with JAXM
  129. 129. Programming Steps  Create SOAPConnection using SOAPConnectionFactory  Create SOAPMessage using MessageFactory  Create reference to SOAP Part object  Create reference to SOAP Envelope from SOAP Part object  Create reference to SOAP Header from SOAP Envelope and remove it  Create reference to SOAPBody from SOAP Envelope  Add SOAP Body Element to SOAP Body and get its reference  Add Other elements to SOAP Body Element  Send to receiver  Close connection
  130. 130. Exercise
  131. 131. Exercise  Purchase Order <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/” xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <soapenv:Body> <amz:purchaseOrder xmlns:amz="http://www.amazon.com"> <amz:book> <amz:book-title>Head First Java</amz:book-title> <amz:price>30.00</amz:price> <amz:quantity>10</amz:quantity> </amz:book> </amz:purchaseOrder> </soapenv:Body> </soapenv:Envelope>
  132. 132. Exercise  Confirmation <?xml version="1.0" encoding="UTF-8"?> <soap-env:Envelope xmlns:soap- env="http://schemas.xmlsoap.org/soap/envelope/"> <soap-env:Body> <ori:confirmation xmlns:ori="http://www.oreilly.com"> Thank you for your order </ori:confirmation> </soap-env:Body> </soap-env:Envelope>

×