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. 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. Who Deals with Application Integration?
Companies with heterogeneous internal systems
Accounting/
Finance
(Oracle)
Marketing
(Microsoft)
Operation
(SAP)
Human Resources
(JD Edwards)
Information
Systems
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. 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
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. 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. 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. 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. 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. 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. 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
18. Web Services
Defining Web Services
Why Web Services?
Characteristics of Web Services
Web Services Quick Study Cases
Web Services Technologies
19. 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
20. 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
21. Characteristics of Web Services
Web services provides an interface – a Web API
Web services is typically registered
Loosely couple connection
22. Web Service Study Case
Kinko’s
Google
Amazon
UPS
Merrill Lynch
23. 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)
26. 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
28. 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.
30. 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
34. 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
35. 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
36. 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
45. 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)
47. 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
48. 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
49. 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
50. 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.
52. 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
53. 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
54. 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.
55. <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)
56. <faultstring> element
It is a mandatory element when a <fault> element
exists.
It should provide a human-readable description of the
fault
57. <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
58. 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
60. SOAP Message Exchange Patterns
Messaging Exchange Patterns refers to the flows of
messages on the network
One Way (Unidirectional)
Request/Response (Bidirectional)
61. 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
62. 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
63. 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
64. 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
65. 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
66. Securing SOAP Messages
Secure Sockets Layer/ Transport Layer Security
(SSL/TLS)
Hypertext Transfer Protocol Secure (HTTPSS)
Digital Signature
67. 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
68. 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)
69. 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
71. 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
74. 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)
75. 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
76. 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
77. 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
78. 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://…”.
……………………..
79. 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>
80. 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>
81. 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
84. 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
86. 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>
87. 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>
90. 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)
91. 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
92. 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
93. 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
94. 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
97. <businessEntity>
It represents the primary information about business
such as:
contact info
categorization of the business
Identifiers
description of the business
98. <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
99. <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>
100. <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
101. <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
102. 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.
110. 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
111. 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
112. 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
113. 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>
114. Example of WSDD (Undeployment)
<undeployment
name="UndeploymentTemperatureConverterService"
xmlns="http://xml.apache.org/axis/wsdd/">
<service name="HumanResourceSystem"/>
</undeployment>
115. 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
116. 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>
117. 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
118. 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
121. 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)
122. 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
125. 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);
126. 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
127. 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)
128. 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…);
129. 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
132. 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
134. 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
135. 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
136. 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