java web service - summer 2004

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 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

http://www.sjsu.edu/validateStudent

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


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>


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>


<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>

java web service - summer 2004

Technology