You are on page 1of 72

Web Services

Overview

1
Agenda
? Evolution of network computing
? What is Web Services?
? Why Web Services?
? Where is Web Services?
? Web Services Architecture
? Web Services Standards
? Java ™ APIs for Web Services
? J2EE as platform of choice for Web Services
? Web Services Tools
? Roadmap and Summary
2

So what are we going to talk about? In the first part of this overview session, I will
spend some time talking about the evolution of distributed computing and see where
web services fits into the whole evolution path. Then I will talk about what and why
aspects of web services. And then I will talk about the reality of web services.

2
Evolution of
Network Computing

3
Things - 1 014
Waves of Embedded
Computers
Network Computing 1 011 Thermostats
Cars
Switches
TVs
Computers
108 Packages
Phones
Games Clothes
Desktops
Clients
Functions Transfers Transactions Content Telemetry Control
IP v4 IP Layer IP v6
Protocols

Organization
Things - 1 014
Waves of Embedded
Computers
Network Computing 1 011 Thermostats
Cars
Switches
TVs
Computers
Packages
10 8
Phone
s Games Clothes
Desktops
Clients
Functions Transfers Transactions Content Telemetry Control
IP v4 IP Layer IP v6
Protocols FT SMTP
Telnet RPC/XDR
X RMI/IIOP
RMI/IIOP
P LDAP Identity
Organization HTTP LDAP SOAP
SOAP
Client/Server Jini
UDDI JXTA
N-tier Web Applications

Web Polyarchical
Services
Fractal
The New Software
Payment
Developer X1
Locater X10 66

New User’s
X10 66 Service Device

Calendar
Authentication

Shrink Wrap Software-as-a-Service


History of
Distributed Computing

Now let's talk a little bit of background history of distributed computing


and see where web-application and web services model fit in.

7
Platform Evolution
The Network The Computer Network of
Catch Is the Legacy to Is the Embedded Network
Phrase Computer Objects the Web Network Things of Things

Scale 100s 1,000s 1,000,000s 10,000,000s 100,000,000s 100,000,000


s

When/Peak 1984/1987 1990/1993 1996/1999 2001/2003 1998/2004 2004/2007

Leaf X X +HTTP +XML +RM Unknown


Protocol(s) (+JVM) Portal

Directory(s) NS, NS+ +CDS +LDAP(*) +UDDI +Jini +?

Session RPC, XDR +CORBA +CORBA, +SOAP, +RM/Jini +?


RM XML

Schematic

This table shows the evolution of distributed computing considering several factors
such as the number participating computing devices or software entities in the
network, interaction behavioral or pattern among the participants, and underlying
technologies used to enable those interactions. The commonality among these
distributed computing technologies is that they are all used to deliver services in one
form or another in a networking environment.

In the beginning, we had a simple client and server model, which has then evolved
into 3-tier and object-based remote computing model, which we will talk about later
again in a bit more detail. Then they evolved into the current state of distributed
computing technologies, which are illustrated in the middle tiers of the table bounded
by a yellow box and they are web-based computing of today and web services
computing of tomorrow. And they are the focus of J2EE architecture and Sun
technologies and products right now.

In the future where we expect massive number of computing devices and software
entities are forming massive number of networks in a very dynamic fashion, we expect
other service delivery technologies such as Jini and Jxta could be quite useful.

Let's take a look at the communicating patterns of the different phases.


Communication Patterns

Client- Web Web Hybrid


Server 3-Tier Application Services P2P Fractal

This slide shows the communicating pattern in terms of number of tiers and
interaction among internal entities and external entities. As you can tell, until Web
services model, things are pretty much confined to intranet communication.
Communication Patterns:
TM
Java 2

Business Systems

DB Server
App Server J2EE
Web Server
Browser J2SE/
Client J2ME
Web
Application

Now since the web application and web services models are two dominant
communication patterns, let's look into them in a bit more detail.

Here this slide shows web application communication model in which J2EE
architecture is made of web server, application server, and database server tiers while
J2SE and J2ME handles client tier.
Communication Patterns: Sun
ONE

Bus.
Sys. XML
DB (UDDI,
SOAP)
App J2EE
Web
J2SE/
Browser J2ME

Context and Identity


(LDAP, Policy, Liberty)
Web
Service

This picture shows communicating pattern of web services in which business


organizations are beginning to talk to each other leveraging loosely-coupled nature of
web services.
What is a
Web Service?

12

12
Web Services Definition by W3C
? A Web service is a software application
? identified by a URI,
? whose interfaces and binding are
capable of being defined, described and
discovered by XML artifacts and
? supports direct interactions with other
software applications
? using XML based messages
? via internet-based protocols
13

Let me define what web service is first since web service is becoming one
of those overly overloaded buzzwords these days. W3C recently has come
up with a decent definition of web services. According to W3C, “A Web
service is a software application identified by a URI, whose interfaces and
binding are capable of being defined, described and discovered by XML
artifacts and supports direct interactions with other software applications
using XML based messages via internet-based protocols.

13
Distributed Computing
Evolution

Client-
Server(C/S) silos

computing

Web Services/Peer-to-
Peer 14

Let's think a little bit on how distributed computing technology has


evolved.

In the beginning, things were built and deployed typically in the form of
client and server model in which clients talk to a single server, for
example, doing remote procedure calls.

The second phase can be called web-based computing in which many


clients talk to many servers through the net. In this phase, communicating
partners still have to go through some pre-arrangement in terms of what
common object model they have to use or what common communication
protocol they have to agree upon.

Finally, the web services model. As we will see in the following slides,
under web services model, service users and service providers can be
dynamically connected. And the pretty much every computing device and
application participate as both service user and service provider.

14
Traditional C/S vs. Web Services

Traditional C/S Web Service


? Within enterprise ? Between enterprises
? Tied to a set of ? Program language
programming languages independent
? Procedural ? Message-driven
? Usually bound to a ? Easily bound to different
particular transport transports
? Tightly-coupled ? Loosely-coupled
? Efficient processing ? Relatively not efficient
(space/time) processing

15

Now let's compare traditional RPC which is the typical communication model used in
the first generation distributed computing technology we just saw against Web services.
First, traditional RPC is typically used within an enterprise while the real value of web
services is to enable enterprise to enterprise communication in an ad-hoc manner over
the internet.

RPC is typically programming language dependent while Web services is programming


language independent because as we will talk about again, the communication under
Web services model is done by exchanging XML messages, which has no dependence
on a particular programming language.

RPC is typically tied up with a particular transport protocol while under Web services
model, multiple transports can be easily supported because any transport protocol that
can transport XML message can be used.

You will hear a lot about "loosely-coupled" nature of Web services. Because, the only
contract that have to be agreed upon between communicating parties under Web
services is the syntax and semantics of XML messages, in other words, there is no need
to agree on anything else. For example, there is no need to agree on object model, there
is no need to agree on programming language, there is no need to agree on
programming APIs. This is why we call Web services "loosely-coupled".

15
Web Application vs. Web Services

Web Application Web Service

? User-to-program ? Program-to-program
interaction interaction
? Static integration of ? Possibility of dynamic
components integration of
? Monolithic service components (in the
future)
? Possibility of service
aggregation (in the
future)

16

Just to give you a sense on the differences between Web application which
is the second generation distributed computing we saw and web service
model.

Web application in its current form is typically focused on between an end


user and program while under web services model, program to program
communication would be much more common form of communication.

Also under web application model, things are pretty much in static mode.
That is, in order to integrate various applications, you have to statically
configure them to talk each other. Under web services model, things could
be a lot more dynamic, that is, service users will find service provider
and use the services of those providers more dynamically.

Also under Web services model, services can be aggregated again in a ad-
hoc and dynamic fashion.

16
Characteristics of Web
Services
? XML based everywhere
? Message-based
? Programming language independent
? Could be dynamically located
? Could be dynamically assembled or
aggregated
? Accessed over the internet
? Loosely coupled
? Based on industry standards
17

Just to recap the characteristics of Web services, Web services is XML-


based throughout. Pretty much everything in the domain of Web services
is defined in XML. For example, the format of the data being exchanged
between service user and service provider is defined in XML or the
description of web service is defined in XML.

Because the only contract that have to be agreed upon between service user
and service provider is syntax and semantics of XML messages, as long as
valid messages can be generated and understood, it does not matter what
programming language is used. So Web service is said to be programming
language independent.

Web services can be dynamically located and invoked. And typically they
will be accessed and invoked over both internet and intranet.
We talked about the loosely-coupled nature of Web service already.
And all these will be based on de facto and de jure industry standards such
as SOAP, WSDL,UDDI and ebXML.

17
This is the high level web services architecture. The cloud at the top right
hand side, the service grid, is a set of web services on the internet. These
services are accessible to the various client devices shown at the bottom
of the picture.

When a web service is created, it registers itself to a service registry. By


registering in the the service registry, the Web service exposes its
interface to any client that is interested in accessing it.

When a client requires a certain service, it first looks in the service


registry, this is the service discovery phase.

Once an appropriate web service has been located, the client then invokes
the web service, which delivers the service to the client.

18
Service Assembly

Macro
Service Micro
Service
Business
Process
Management

Micro
Service
Micro
Service

19

Anatomy of an assembled macro service.

19
Service Nasdaq
Aggregation Input: Symbol
Output: Price

News feed 1
Stock Service Input: Symbol
Output: News links
Portal
User Input: Symbol
Output: Price, News,
Trade

News feed n
Input: Symbol
Output: News links

Brokerage 1 Brokerage n
Input: Symbol, Price, Input: Symbol, Price,
Qty Qty

20

Anatomy of an assembled macro service.

20
Why Web Services?

21

21
Why Web Services?
Web Services:
? Are platform neutral
? Are accessible in a
standard way
? Are accessible in an
interoperable way
? Use simple and
ubiquitous plumbing
? Are relatively cheap
? Simplify enterprise
integration

22

22
Why Web Services?
? Interoperable – Connect across heterogeneous
networks using ubiquitous web-based standards
? Economical – Recycle components, no
installation and tight integration of software
? Automatic – No human intervention required
even for highly complex transactions
? Accessible – Legacy assets & internal apps are
exposed and accessible on the web
? Available – Services on any device, anywhere,
anytime
? Scalable – No limits on scope of applications and
23
amount of heterogeneous applications

(read the slide)

23
Web Services Usage Example
Distributor

XML

XML
Manufacturing
Supplier Internet Facility
XML

XML

Logistics

“Growing need for a standard lightweight infrastructure


for data exchange in e-business applications.”
24

Now let's talk about motivation of Web services a bit from real-life example point of view.
That is, what is the value proposition of Web services? I would like to explain this by
giving you an e-commerce example.
One great opportunity and at the same time great challenge in e-commerce is to allow
business entities to perform business transactions over the internet without having to invest
a lot of resource in their IT infrastructure and without a lot of pre-arrangement with their
communicating partners. For example, suppose I am in the retail business in the United
States, and as a retailer, I would like to work with any potential supplier or distributor in the
world. And I would like to change my supplier as often as needed and whenever there is a
business requirement for the change. And that means my information system needs to be
able to talk to the system of my potential supplier without that much of pre-arrangement
and pre-agreement on programming language or middleware or platform.
What it means is that there is a growing need for standard lightweight infrastructure for
business data exchange.
Now everybody seems to agree that XML and messaging based business transaction will
address these needs. XML messaging based business communication is lightweight
because the only agreement between communicating parties is commonly agreed-upon
XML business messages. Of couse, you will need a lot more than that. But commonly
agreed-upon XML-based business messages will these previously isolated business
organizations to be able to communicate. And that is basically what web services is all
bout. It provides lightweight infrastructure for business to communicate through exchange
of XML messages.

24
Impact of Web Services on Software:
“Application Dis-Integration”
Web Services

Monolithic App App App


Software Service Service Service

Application

System Software System System System


Service Service Service

A Computer

The Network

25

I told you already a web service is some business


functionality exposed over the internet. What it entails is
that today's monolithic applications will be disintegrated into
several forms of web services which exposed as services over
the internet.
We believe web services can be categorized into application
and system service web services.
Examples of Application Services are a commerce shopping
cart or a calendar appointment service.
System services are expected to provide common services
that would be used by application servers and the examples of
System Services are identity, policy/authorization, directory
service, notification, logging, file storage service, and so on.

25
Macro web services – Virtual
Systems
Web Services
A web service is
accessed Bank Balance
programmatically by
applications or other
web services Net worth Stock Position

Insurance
Portfolio Cash Value

Stock ticker
Biz News
“Portfolio” can be an News
application, a portal
channel, or a web World News
service itself 26

Web services are accessed programmatically, not by a human user directly. In the
case of an online broker, the user can surf the HTML pages regarding the purchase
of a stock, such as finding stock symbol, finding price, entering number of shares
requested, confirming the purchase request, getting a confirmation number, etc.
But it would be very difficult to write a program to access these pages. HTML is
hard to parse and the website might change the contents and organization of its
pages on a daily basis. If the broker offered a stock-buying web service, the
program to access it is simple—send an XML message over the SOAP RPC and
get and XML message back. You could write a simple Perl script or Visual Basic
program to accomplish this.

Web services are well-defined, modular services that perform a specific task, but
can be interlinked together to provide a larger set of services. This example shows
how a Portfolio application can be developed out of web services assembled from
all over the Internet. As noted, Portfolio could be a desktop or server application, a
channel in the Portal Server desktop, or it could be a web service itself, ready for
assembly into an even larger service or application.

Side note: Today you can develop components following the J2EE model, such as
with EJBs. Thus, this concept can be achieved today with Sun ONE. More
importantly it should be noted Java and web services are complementary. You
need to write the code to implement each micro service in some language. The
industry has accepted the standard of writing enterprise applications using the
J2EE model.

26
Micro web services – Virtual Apps
A web service is Web Services
accessed
Bank balance
programmatically by Spell Check
applications or other
web services Grammar Dictionary

Thesaurus
Word Processing

Media
“Word processing” c:\...
can be an Publishing
application, a
capability, or a web http://...
service itself 27

27
Three Laws of Computing
? Moore's Law
– Computing power doubles every 18 months
? Gilder's Law
– Network bandwidth capacity doubles every 12
months
? Metcalfe's Law (Net Effect)
– Value of network increases exponentially as
number of participants increases

28

28
Impact on Integration:
Trigger the Network Effect

Custom
Integration Web Services

Metcalfe’s Law: The value of the network is


proportional to the square of the number of 29

Another impact of web services is that they will trigger the Network Effect
for integration technology.

Metcalfe’s Law describes the an effect that is often illustrated with an


example of FAX machines. The first FAX machine had zero value because
it could communicate with no one. When a second came on line, the value
increased. And as the network reached a critical mass, it compelled more
and more users to get FAX machines. This is also called the Network
Effect.

29
Myth: Web Services is a New
Concept
? Web services is distributed computing all
over again – only now it is based on the web

Distributed Computing ala CORBA /


Concept Java Basic Web Services
Interface Description CORBA IDL, Java interface WSDL
RPC support ORBs, Idl2java compilers, rmic SOAP, compilers for WSDL
Service Registry CORBA naming service, JNDI UDDI
Messaging support CORBA Event/Notification service, JMS ?
Transaction support CORBA Transaction service, JTS ?
Secuity support CORBA Security service, Java security ?

30

30
Other Popular Myths
Surrounding Web Services
? Web services require only SOAP, WSDL,
UDDI: We need more high-level semantics
? Web services are based on the RPC
paradigm: Document-driven model would
be more popular communication model
? Web services must be based on HTTP:
Other transports such as SMTP can be
also used

31

31
Where is &
Where is Web Services
going?

32

32
Myths about Web Services
? Web Services cure cancer: Not for a
very very long time!
? Web Services are something
completely new: Not True!
? You have to write Web Services
from scratch: Not True!
? J2EE Platform does not support
web services: Not True!
33

Just like any other new technology that promises a brand new world, Web services comes
with its own set of confusion and myths. So let's clarify some of those myths here.
First myth is that web services is going to cure cancer. I can promise you with 100%
certainty that it will not... at least for a very very long time and it will not make all your
issues you have to be concerned about when writing good quality applications go away. You
still have to write good software that works. Also Web services, despite its promising future,
still have to prove itself in the real world.

Another myth people might have is that Web services is something completely new. That is
not true either. Distributing computing has been around for quite a while in which remote
service can be invoked over the wire. As for service definition, people used to use IDL to
define service definitions. As for service publication and discovery, there is also directory
service like LDAP. What is unique about Web service, however, is that now everybody
agrees on a common XML-based standards on service description, service invocation, and
service publication and discovery.

Another myth is that you have to write Web services from scratch. That is not true at all. In
fact, as I will talk about later on, Web services happened to be just another delivery channel
of your service. And the service implementation you currently have can be exposed as web
services without any modification.

Lastly, a myth about J2EE and web service. Web services model can be easily added to J2EE
platform without any change to the existing architecture. In fact, existing J2EE components
such as EJB's can be easily exposed as Web services. And as we will talk more about this
later on, this is one of the significant differences between SunONE and .Net in that in Sun
ONE architecture, the investment you made can be preserved when you are moving toward33
Web services model.
State of Web Services
? Technology/Standards are still evolving
– SOAP, WSDL, UDDI are not enough
? Business web services is the next big
thing, but more works are needed in
– Quality of Service, management
– Security, transaction, state and user context
– Work flow, Identity management,
– Provisioning, Accounting
? Will be adopted in phases
34

34
Web Services Adoption Phases
?
1st phase (current state)
– Concerted deployment internally within an
organization mainly for interoperability
– SOAP over HTTP/S
? 2nd phase (1 to 2 years)
– Selective and non-aggregate deployment with
trusted outside business partners
– Private registry deployment
? 3rd phase (at least 3 to 4 years away)
– Wider, more dynamic and aggregate deployment
with outside business partners
– Public registry deployment 35

35
Web Services Adoption Phases
? 1st Phase – Simple Web Services (Now)
?
Consumer-focused, stateless, SOAP over
HTTP/S
? 2nd Phase – EAI Web Services (Begun)
? Deployed within organization boundaries to
enable internal integration
? 3rd Phase – Business Web Services
(2007?)
? Deployed on extranets to enable business
transactions with trading partners, suppliers, 36
and customers, ebXML & UBL
First, let me tell you this up front, J2EE community incuding Sun microsystems
strongly believe in the vision and promise of web services. Now we believe
web services will be adopted in phases.

First phase is where simple web services are used in consumer oriented settings
typically for the purpose of simple consumer-oriented transaction.

In the second phase, we believe that web services could be used for enterprise
application integration, EAI in short, within an intranet. And in fact many
organizations have started looking at Web services as one way of doing EAI.
And we believe this phase has already begun.

The 3rd phase could be dubbed as business web services where business
organizations are performing business transactions with their trading partners,
suppliers, or even customers through the exchange of XML-based business
messsages over the internet.

36
Business Web Services
? J2EETM
? Service implementation platform standard
? ebXML and UBL
?
Business web services standards
? More than 16 vendors and several open
source projects support ebXML
?
ex) Australian gas industry uses ebXML
NOW!
? Liberty Project
37
?
Identity system standard

Even though we believe simple web services and EAI are important forms of web
services, we also believe the real value of web services lies with business web
services. That is the reason why we are investing quite a bit of our engineering
resources to key technologies that will enable business web services.

First, we believe J2EE provides a standard-based implementation and deployment


platform where not only simple web services and EAI web services but also business
web services can be developed and deployed while maintaining all the benefits that
come with the architecture, that is, scalability, reliability, availability, performance,
security, flexibility, maintenability, portability, and extensibility.

Second, we firmly believe ebXML and UBL (Universal Business Language) provide
viable and only open-standards based business web services framework. And II want
to say it loud and clear. ebXML is real and in fact there are more than 16 commercial
vendors and open source-based products that support ebXML right now including Sun
Microsystems's Secure Trading Agent. In fact, real life customers are using ebXML
right now for solving real-life problems. For example, austrailian energy industry is
using ebXML mesasging service for secure and reliable XML message delivery. And
we believe ebXML adoption will accerlate during the next year or so.

Third, Liberty project as Identity management standard which we strongly believe is


critical to business web services and e-commerce of the future.

37
Business Web Services (B2B)
Architectural Components (ebXML)

? B2B collaboration
? Secure and reliable message
delivery
? Non-repudiation
? Partner profile
? Repository for business data objects
38

38
Simple Web Services (WUS) vs.
B2B Collaboration (ebXML)
Simple Web B2B Collaboration
Services
l Simple interaction l Complex interaction
l Consumer oriented l Business oriented
l Short-living process l Long-running process
l No business l Supports business
collaboration collaboration
l No partner profile l Supports partner
l Not secure, not profile
reliable l Secure and reliable
l Does not support and non-repudiation
non-repudiation
l No repository l Supports non-
support repudiation
Registry and 39
l No legal binding l

S
EAI vs. B2B Collaboration (ebXML)

EAI B2B Collaboration

l Within a l Between
business business
organization organizations
l Centralized l Distributed
control control
l Implicit contract l Explicit contract
l Small number of l Potentially large
business number of
processes and business
participants processes and 40
participants
1.Centralization vs. Collaboration.
A "Centralized model" allows the implementation of integration for EAI because in an
Enterprise (even very big and sparse) the
different departments are part of the same challenge and, normally, IT is a "shared
service" among all the departments.
The quality of integration (Integration Server vs MOM) models the ability to describe
the "challenge" in a top-down or in a bottom-up
way.

A "Collaboration model" allows the implementation of integration for different


entities, where there is no "central IT" shared by the
different entities and where each entity needs to play a peer role. In this model, the
"global challenge" of the integrated solution needs to
be implemented in a way where each peer contributes to the overall goal (unless the
partners agree on the fact that one of them is more
important of the other... or agree to elect an ASP as a "shared" resource)

2.Explicit vs. Implicit contract.


It is often the case that, within an enterprise, the integrated solution is mandated by the
Board of Management (or equivalent) in order
to optimize the use of internal resources and to decrease costs. In these situations, the
participating departments are "mandated" to
participate to the integrated solution; the "contract" linking each of them to the others
is, in some way, defined "upfront". This translates
into the fact that the EAI solution does not, normally, need to implement any kind of
"agreement" because such agreement is, in some
way, enforced by the shared IT department.
Trends Towards Service Orientation
? Evolution of EAI to web service standards
? XML RPC => Asynchronous XML Messaging
? Towards de-centralization
? Componentized services
– Composable and composite services
– Data encapsulated within component
– Data ownership follows component ownership
? Brokered web services
? Flexible relationships => Adaptive businesses
41

41
Simple Web Services Architectural
Components (WUS)

? Service Description
? Service Registration (Publication)
and Discovery
? Service Invocation

42

What are the core building blocks of web services architecture?


At the minimum, you need a standard way of describing a web
service that are universally understood by all potential service
users and service providers. This is important because without
commonly agreed upon description of service, a service provider
might have to produce individually tailored way of describing its
service to all its potential service users.

There has to be registry by which a service can be published and


discovered. Then there has to be standard way of invoking a
service.

Finally, for business transactions in which secure and reliable


message delivery is important, there has to be a standard
electronic business framework.

42
Core Web Services
Standards

43

43
(Simplified) Web Service
Architecture

Registry

2. Client Request
1. Service Registers
Service Location
PUBLISH
FIND
3. Client calls
Service
Web BIND
Service
Service Client

44

The Universal Description, Discovery, and Integration standard provides a


mechanism for businesses to "describe" themselves and the types of
services they provide and then register and publish themselves in a UDDI
Registry. Such published businesses can be searched for, queried, or
"discovered" by other businesses using SOAP messages.

44
SOAP
(Simple Object
Access Protocol)
45

45
SOAP
? Simple Object Access Protocol
? Wire protocol similar to
– IIOP for CORBA
– JRMP for RMI
? XML is used for data encoding
– “text” based protocol vs. “binary” protocol
? Supports XML-based RPC

46

What is SOAP? First of all, as its name implies, it is a wire-protocol. It is a wire-


protocol in the same sense that IIOP is a wire protocol for CORBA and JRMP is a wire
protocol for RMI.

As a wire protocol, it defines data encoding. In other words, it specifies rules of how
data types get serialized over the wire. For example, it specifies how integer value 23
or string value xyz are to be represented on the wire. Defining standard encoding rules
is important for interoperability, if you think about it, because without the agreed-upon
encoding rules, communicating partners would not be able to understand the data that
gets delivered on the wire. (For example, the communiting partners have to agree on
whether integer value 23 is going to be represented in 2 bytes or a single byte and in
what form.) The difference between SOAP encoding and others is that under SOAP,
the encoded data are in XML representation, which is text based encoding while others
are in binary encoding.
SOAP also supports remote procedure call mechanism which is used to invoke a
procedure call on a remote machine again the using XML notation.

46
What SOAP is Not
? Not a component model
– So it will not replace objects and
components, i.e. EJB, JavaBeans
? Not a programming language
– So it will not replace Java
? Not a solution for all
– So it will not replace other distributed
computing technologies such as RMI
47

Now, I would like to make sure you understand what SOAP is not as well because there
seems to be some confusion about this.

First, SOAP is not a component model. So it will not replace existing component models
such as Javabeans or EJB. In fact, component models and SOAP are very complementary
in that SOAP can be used as communication protocol for invoking business logics that
are captured in those components.

Second, SOAP is not a programming language. That is, it will not replace programming
language like Java. In fact, SOAP and Java are very complementary as well. That is, Java
is for portable code and SOAP is in a sense a portable communication protocol.

Now, if you think about it, SOAP messages have to be produced and processed and
manipulated by a programming language. What is the programming language of choice
for SOAP message production, manipulation, and processing? It is Java. In fact, most of
the SOAP packages out there are written in Java.

Third, SOAP is not an answer for all problems in distributed computing. In many cases,
tightly-coupled and non-XML based technology such as RMI is in fact a better solution,
for example when you need to build high-performance and secure intranet applications.

47
What does SOAP Define?
? Message Envelope
? Encoding Rules
? RPC Convention
? Binding with underlying protocols

48

What are the things that SOAP define as communication protocol? The
SOAP specification covers four aspects: Message envelope, Encoding
rules, and remote procedure call convention, and finally how to bind SOAP
message with underlying transport protocol such as HTTP. Now let's take
a look at each of these in detail.

48
SOAP Message Format
SOAP Message SOAP Envelope

SOAP Header
Primary MIME part Header Entry
(text/xml)

Header Entry
Attachment
SOAP Body
Attachment
Body Entry

Body Entry
Attachment

49

This picture shows the format of SOAP message, actually SOAP message
with attachments.

SOAP message is made of SOAP Envelope and zero or more attachments.

The SOAP Envelope in turn is then made of header and body.


What is SOAP attachment for? It allows the SOAP message to contain
not only the XML data but also non-XML data such as binary graphics
file. And it uses the MIME multipart as container for these non-XML
data.

49
SOAP Message Envelope
? Encoding information
? Header
– Optional
– Could contain context knowledge
? Security
? Transaction
? Body
– RPC methods and parameters
– Contains application data
50

We will see an example of SOAP message soon but the header is optional
and it can contain so called context knowledge such as security or
transaction related information while the body contains application data or
remote procedure call method and it parameter information.

Please note that the SOAP specification does not specify any of these
contexts. But SOAP header structure can be extensible, and that is how
ebXML messaging service provides security and reliability by defining
elements that can be embedded in the header structure. And we will see an
example later on.

The message envelope also carries information on encoding.

50
SOAP Encoding
• Rules of expressing application-defined
data types in XML
• Based on W3C XML Schema
• Simple values
– Built-in types from XML Schema, Part 2
(simple types, enumerations, arrays of
bytes)
• Compound values
– Structs, arrays, complex types
51

Now what is encoding? As I mentioned before, it is a set of rules of how to express


application-defined data types on the wire in XML form.
SOAP encoding is based on W3C XML schema. What that means is that the SOAP
messages are constructed using the data types defined in W3C XML schema.

SOAP encoding supports both simple values and compound values. Simple values
are the values of of built-in types from XML schema part 2 or enumeration or byte
array.

Compound values is constructed as a composite of several parts, each with a type


and can be of struct or arrays or complex type.

51
WSDL

52

Now since we talked about the web services architecture over J2EE, let's
go over the steps needed for developing web services over J2EE.

52
What is WSDL?
• XML language for describing web services
• Web service is described as
– A set of communication endpoints (ports)
• Endpoint is made of two parts
– Abstract definitions of operations and messages
– Concrete binding to networking protocol (and
corresponding endpoint address) and message
format
• Why this separation?
– Enhance reusability (as we will see in UDDI
reference to WSDL document) 53

What is WSDL? WSDL is industry-agreed-upon XML language that can be used to


describe web services.

Under WSDL, a Web service is described as a set of communication endpoints that


are capable of exchanging messages. These communication endpoints are called ports.

An endpoint is made of two parts: The first part is abstract definitions of operations
and messages. As you will see later on, operations and messages are related in that
messages are exchanged for the purpose of performing the operations. The 2nd part is
concrete binding of those abstract definitions of operations to concrete network
protocol and message format. And one concrete example of network protocol is
SOAP over HTTP.

The whole idea of this separation of abstract definitions from concrete binding is to
allow the reuse of abstraction definitions regardless of present or future network
protocols.

53
Why WSDL?
• Enables automation of communication
details between communicating partners
– Machines can read WSDL
– Machines can invoke a service defined in
WSDL
• Discoverable through registry
• Arbitration
– 3rd party can verify if communication conforms
to WSDL
54

The key value proposition of WSDL as a standard description of web service is it


enables automation of communication details in application to application
communication. That is, machines can figure out from WSDL document what
services are available and how to invoke them without manual pre-arrangement or
pre-configuration between the two.

54
WSDL Document Example
? Simple service providing stock quotes
? A single operation called
GetLastTradePrice
? Deployed using SOAP 1.1 over HTTP
? Request takes a ticker symbol of type
string
? Response returns price as a float

55

Now, I am going to explain WSDL by using a simple WSDL document


example. This example describes a very simple service which provides
stock price quote, the same example we used in SOAP part of the
presentation. That is, this service supports a single operation called
GetLastTradePrice. And this service is deployed using SOAP 1.1 over
HTTP. So from this WSDL document, a soap message we saw in our
SOAP presentation can be automatically generated.

The request takes a ticker symbol of type string and the response returns
price whose type is float.
As you will see, WSDL XML vocabularies define 7 XML elements.

55
UDDI

56

Now since we talked about the web services architecture over J2EE, let's
go over the steps needed for developing web services over J2EE.

56
Service Architecture

UDDI
Registry
2. Client Request
1. Service Registers Service Location
PUBLISH FIND

Web Service
3. Client calls Client
Service Service
BIND

UDDI defines a way to publish and find


information about Web services.
57

The Universal Description, Discovery, and Integration standard provides a mechanism


for businesses to "describe" themselves and the types of services they provide and
then register and publish themselves in a UDDI Registry. Such published businesses
can be searched for, queried, or "discovered" by other businesses using SOAP
messages.

57
UDDI (Universal Description,
Discovery and Integration)
? “White pages”
– address, contact, and known identifiers
? “Yellow pages”
– industrial categorizations
? Industry: NAICS (Industry codes - US Govt.)
? Product/Services: UN/SPSC (ECMA)
? Location: Geographical taxonomy
? “Green pages”
– technical information about services
58

Now what kind of information will be contained in the business registration


data? They can be categorized into white pages, yellow pages, and green
pages. The concept of white pages and yellow pages are not that much
different from the ones we know in that white page contains information on
a particular business entity, for example, name, contact information, address,
or unique identification number while yellow page contains categorization
information according to industry, product and service, or geographic
location.

Finally, green pages contains so-called technical information about the


service which is basically meta information on services and this meta
information has references to service definitions represented by WSDL
document.

58
Web Services Framework
for J2EE

59

59
J2EE Platform& Web Services
B2B
Applications

Existing
Applications
B2C
Applications

Web
Services
Application Server
Wireless Enterprise
Applications Information
Systems

60

60
Why J2EE for Web Services?
? Web services is just one of many
service delivery channels of J2EE
– No architectural change is needed
– Existing J2EE components can be easily
exposed as Web services
? Many benefits of J2EE are
preserved for Web services
– Portability, Scalability, Reliability
– No single-vendor lock-in
61

Now, let's talk about the motivation for using J2EE as development and deployment
platform for web services.

As most of you already know, J2EE is an open standard platform for building enterprise
applications in which business logic are captured and deployed as components. J2EE is also
an end-to-end architecture where there are multiple programming models to implement and
deploy these business logics. That is, there is servlet, there is JSP, there are EJB beans, and
there is JMS. All these programming models provide somewhat different ways of
implementing and deploying business logics over J2EE and you as developers choose one
ore more of these programming models according to the needs and requirements of your
applications.

Now if you think about it, web services model is just another way of exposing the business
logic of these components. There is no architectural or code change required to expose the
existing J2EE components as web services . For example, as a service provider, in addition
to exposing business functions captured in EJB beans by EJB remote interface over
RMI/IIOP, you can also expose them via WSDL and handle the service by receiving SOAP
message and send the result back in SOAP messages.

What it means is that the existing J2EE components can be exposed as web services without
any change in their code which also means the key benefits of J2EE such as open and
standard platform, portability of code, availability of highly scalable and highly reliable
platform products, are still preserved. And most of all, you can still choose the best of breed
J2EE platform or J2EE applications including web services components without
compromising the code portability.
61
Where Are We Now?
? Java APIs for Web Services are
being developed very rapidly
? Tools are available now for
exposing existing J2EE
components as Web services
? J2EE community has defined
overall framework for Web Services
(J2EE 1.4, JSR 109)
62

J2EE has proved itself as the platform of choice for building enterprise applications.
Now what about web services? Where are we now and where are we going in terms of
using J2EE as Web services platform?

As many of you already know, Java community is feverishly working on defining Java
APIs for web services. And THE primary platform that these Java APIs are designed
for is J2EE.

Tool vendors already have products out there that you can use to expose existing J2EE
components such as EJBs as web services by basically providing a tool that can
generate WSDL document from EJB beans and from the WSDL, a client stub can be
generated which knows how to send and receive SOAP messages in order to use the
service defined in WSDL. So you can expose business functions that you already have
in J2EE as web services right now.

Finally J2EE community is in the works to define overall Web services framework for
J2EE through J2EE 1.4 and JSR 109 for the sake of portability of Web services.

62
Design Goals J2EE Web Services
Framework
? Portability of Web services component
– Over different vendor platform
– Over different operational environment
? Leveraging existing J2EE programming
models for service implementation
? Easy to program and deploy
– High-level Java APIs
– Use existing deployment model
63

So what are the design goals of J2EE web services framework?


I already explained the container and component model of J2EE. And one of the benefits
of building application as components is its portability. And the same benefit applies to
web services as well.
Another important goal is that the existing J2EE programming models such as EJBs and
servlets or message driven beans should be leveraged for service implementation.
Next, runtime support of multiple transport bindings. One of the distinctive
characteristics of Web services is that web services can be accessed over different
message delivery protocols such as SOAP over HTTP or SMTP or JMS and web services
framework should be able to support various message delivery protocols and these these
different message delivery protocols can be selected during runtime through what is called
binding. ( If you think about it, this is one of the differences of Web services from other
communication protocols in that because information is being transported as XML text
data, that is, the data is not really tied up with underlying transport protocol, there can be
multiple ways to transport that data instead of just one way for many object-based
communication protocols. So that is what I meant here as "multiple bindings")
Next, we want to make sure that building and deploying web services is easy. What that
means is that programmers will be able to use high-level Java APIs for building web
services instead of dealing with low-level plumbings.

63
J2EE Web Services Framework
? J2EE 1.4 and Java EE 5
– Umbrella framework for Web services
– JSR 109, JAX-RPC, JAXR, EJB 2.1, Servlet
2.4,
? JAX-RPC (JAX-WS)
– Defines client programming model
– Defines Servlet-based Web services endpoint
model

64

64
J2EE Web Services Framework

? EJB 2.1
– Defines Stateless Session Bean-based Web
services endpoint model
? Servlet 2.4
– Will be aligned with JAX-RPC
? JSR 109
– Defines standard Web services packaging and
deployment model
65

65
Web Services Architecture
over J2EE

66

Now let's talk about Web services architecture over J2EE in a bit more
detail.

66
What Is a Web Service?
? A set of endpoints (ports) operating on
messages
? Ports are operating within a container
– Container provides runtime environment
– Contract for runtime environment are specified in
JAX-RPC, EJB 2.1, JSR 109
? Service is described in WSDL document
and published to a registry
– WSDL specifies a contract between service
provider and client
67

So what is a Web service?

Under J2EE context, Web services are defined as a set of endpoints


operating on messages meaning the endpoints receive request messages
and then send back response messages. These endpoints are operating
within a container, which provides Web services runtime environment in
the same way EJB container provides runtime environment for EJB beans.
And the contract between the Web services endpoints and the container
are specified in JAX-RPC, EJB 2.1, and JSR 109.

Another aspect to note is that a Web service is described in WSDL


document and this service description can be published to a registry.
What this means is that the WSDL document is the only thing that is
needed between web service user and service provider in order to
communicate.

67
Web Service Component
and Container
? Container vs. Component model
– Web services components get executed within a
container
– Components are portable (under J2EE 1.4)
? Web service components
– Web-tier (Servlet-based endpoint)
– EJB-tier (Stateless session bean-based endpoint)

68

Now I would like to talk about component and container model of J2EE and how it
relates to web services.

One of the key architectural characteristics of J2ee is that business logic are
implemented as components, which are in turn executed in a host execution
environment called containers. And this container and component model will be
used for implementing and deploying web services as well. That is, you will build
web services as components which will be then executed in a web service container.
In other words, web services components are going to be a 1st-class citizen of
J2EE along with servlet, JSP and EJB.
(add more speaker notes)

68
Web Service Components
Web services
components

Source: Web Services for J2EE (JSR 109), V1.0 69

This picture shows what I just explained in the previous slide. Web
services components can reside either at web-tier or EJB-tier. When web
services component is built as a servlet-based endpoint, it is running
within the web container while when it is built as a session bean based
endpoint, it will be running within the EJb container. So you can see we
are leveraging existing container architecture for Web services
components.

69
Summary

70

70
Summary
? Web services provides a new paradigm for
program to program communication
? Comprehensive set of Java APIs for Web
Services are now available!
? J2EE is the platform of choice for Web
services

71

So in summary, Web services provides a new paradigm for program to


program communication.

Sun ONE is open framework for service on demand paradigm and web
services is part of it.

Java community is working feverishly to come up with a complete set of


Java APIs for web services.

And finally J2EE is the platform of choice for web services development
and deployment.

One last thing I would like emphasize is that we believe the real value of
web services is in the area of business web services not in the things you
see right now like temperature convertor or traffic report. And that is the
area we will put lots of our resources.

71
Passion!

72

72