java web service - summer 2004
TRANSCRIPT
Application Integration
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
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.
Who Deals with Application Integration?
Companies with heterogeneous internal systems
Accounting/Finance(Oracle)
Marketing(Microsoft)
Operation(SAP)
Human Resources(JD Edwards)
InformationSystems
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)
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
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 application
Useful to build data warehouse (extract and aggregate data to produce useful report)
Less costly and easier to execute than Application –level integration
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
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
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
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
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
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
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 Cases Web Services Technologies
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
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
Characteristics of Web Services
Web services provides an interface – a Web API Web services is typically registered Loosely couple connection
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 Describe a service (WSDL) Advertise and discover a service (UDDI) Communicate with other services (SOAP)
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 between the service provider and service consumer
WSDL describes WHAT, HOW, and WHERE
WSDL (Continued…)
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.
UDDI (Continued…)
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
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 on the network (Intranet & Internet)
Utilizing text-based data representation using XML
Enabling communication between heterogeneous applications in a distributed environment
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
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 Envelopeo Headero Bodyo Attachment
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 Intermediary (can switch role as a sender &
receiver)
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…
SOAP’s Basic Structure
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)
SOAP Envelope
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
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
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
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.
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 block can contain:
• Information defining the RPC Call
• Business document in XML
• SOAP Fault for reporting error/status information
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
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.
<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)
<faultstring> element
It is a mandatory element when a <fault> element exists.
It should provide a human-readable description of the fault
<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
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
SOAP Attachment
SOAP Message Exchange Patterns
Messaging Exchange Patterns refers to the flows of messages on the network
One Way (Unidirectional)
Request/Response (Bidirectional)
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
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
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
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
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
Securing SOAP Messages
Secure Sockets Layer/ Transport Layer Security (SSL/TLS)
Hypertext Transfer Protocol Secure (HTTPSS) Digital Signature
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
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)
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
Roles of Axis SOAP Engine
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
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 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)
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
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
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
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://…”.
……………………..
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>
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>
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
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>
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>
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
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; }
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>
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>
UDDI Universal Description, Discovery, and Integration
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)
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
UDDI Registries
Public Registries Available for everyone to publish/query business and service
information
UDDI Business Registry (UBR): Massive Public Registrieso Operator Site (Microsoft, IBM, SAP, and NTT)o Synchronized process
Private Registries Available for participating organizations or groups
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
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
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 business Identifiers description of the business
<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
<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>
<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
<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
UDDI Programming API Inquiry API
Consists of XML messages defined using UDDI schema which can be used to locate information about business
Publisher APIConsist of XML messages which can be used to create, update, and delete information presents in the registry. Require authentication.
Inquiry API <find_business> <find_relatedBusiness> <find_service> <find_binding> <find_tModel> <get_businessDetail> <get_businessDetailExt> <get_serviceDetail> <get_tModelDetail>
Publishing API <save_business> <set_publisherAssertions> <add_publisherAssertions> <save_service> <save_binding> <save_tModel> <delete_business> <delete_publisherAssertions> <delete_service> <delete_binding> <delete_tModel>
Examples of <find_service>
Request SOAP
<uddi:find_service>
<findQualifiers>
<findQualifier>
caseSensitiveMatch
</findQualifier>
</findQualifiers>
<uddi:name>
Sumatra Widget Corporation
</uddi:name>
</uddi:find_service>
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>
Limitations of UDDI
UDDI has limited information model compared to ebXML Registry/ Repository
UDDI is just a registry, not a repository
AXIS WSDD and BeanSerializer
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
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
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
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>
Example of WSDD (Undeployment)
<undeployment
name="UndeploymentTemperatureConverterService" xmlns="http://xml.apache.org/axis/wsdd/"> <service name="HumanResourceSystem"/>
</undeployment>
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
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>
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
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
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 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)
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
Generated Stubs (Deployment)
Generated Stubs (Run Time)
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);
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
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 locatedo This is a “virtual mapping” to your web service application
component (TemperatureConverter.jws)
DII (Dynamic Invocation Interfaces)
Sample Codes:// In order to create a service type object, we need to use ServiceFactoryServiceFactory sfactory = serviceFactory.new Instance();
// Creating service type object from the factoryService service = sfactory.creaetService(…pass service info…);
// Create a call object from service type objectCall call = service.createCall(…pass port info…);
// Set the endpoint property call.setTargetEndpoint(..pass endpoint info..);
// Set the operation namecall.setOperationName(..pass method…);
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
SAAJ & JAXM
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
SAAJ Structures
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
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
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
Exercise
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>
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>