Java Web Service - Summer 2004

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)
Information
Systems

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

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

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.

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

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 Envelope
o Header
o Body
o Attachment

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 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 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 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 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
 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 Registries
o 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>

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

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

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
 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 located
o 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 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…);

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (17)

Semelhante a Java Web Service - Summer 2004

Semelhante a Java Web Service - Summer 2004 (20)

Último

Último (20)

Java Web Service - Summer 2004