10/23/2005

Web Services
Overview

1
10/23/2005

Sang Shin
sang.shin@sun.com
Java™ Technology Evangelist
Sun Microsystems, Inc.
www.javapassion.com/webservices
2

2
10/23/2005

Disclaimer
? Even though Sang Shin is a full-time employee of Sun
Microsystems, the contents here are created as his
own personal endeavor and thus does not reflect any
official stance of Sun Microsystems.
? Sun Microsystems is not responsible for any
inaccuracies in the contents.

3
10/23/2005

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
4

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.

4
10/23/2005

Evolution of
Network Computing

5
10/23/2005

Things - 10 14
Waves of Embedded Computers
10 11
Network Computing Thermostats
Cars
Switches
TVs
Computers
10 8
Packages
Phones
Games Clothes
Desktops
Clients
Functions Transfers
Transfers Transactions
Transactions Content
Content Telemetry
Telemetry Control
Control
IP v4 IP Layer IP v6
Protocols

Organization
10/23/2005

Things - 10 14
Waves of Embedded Computers
10 11

Network Computing Thermostats

Cars Cars
Switches
TVs
Computers Packages
10 8 Phones
Games Clothes
Desktops
Clients
Functions Transfers
Transfers Transactions
Transactions Content
Content Telemetry
Telemetry Control
Control
IP v4 IP Layer IP v6
Protocols FTP SMTP X RMI/IIOP
RMI/IIOP
Telnet RPC/XDR LDAP Identity
Identity
Organization HTTP LDAP SOAP
SOAP
Jini
Client/Server UDDI Jini
UDDI JXTA
JXTA
N-tier Web
Web Applications
Applications

Web
Web Polyarchical
Services
Services
Fractal
10/23/2005

The New Software

Payment
Developer X1
Locater X10 66

New
X1066 User’s
Service Device

Calendar
Authentication

Shrink Wrap Software-as-a-Service

10/23/2005

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.

9
10/23/2005

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

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

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

Leaf
Leaf XX XX +HTTP
+HTTP +XML
+XML +RM Unknown
+RM Unknown
Protocol(s)
Protocol(s) (+JVM)
(+JVM) Portal
Portal

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

Session RPC, +CORBA,

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

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

10/23/2005

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.
10/23/2005

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.
10/23/2005

Communication Patterns: Sun

ONE

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

Context
Context and
and Identity
Identity
(LDAP,
(LDAP, Policy,
Policy, Liberty)
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.
10/23/2005

What is
Web Services?

14

14
10/23/2005

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
15

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.

15
10/23/2005

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.

16
10/23/2005

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

17

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

17
10/23/2005

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)

18

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.

18
10/23/2005

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
19

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.

19
10/23/2005

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.

20
10/23/2005

Service Assembly

Macro
Service Micro
Service
Business
Process
Management

Micro
Service
Micro
Service

21

Anatomy of an assembled macro service.

21
10/23/2005

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

22

Anatomy of an assembled macro service.

22
10/23/2005

Why Web Services?

23

23
10/23/2005

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

24

24
10/23/2005

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
amount of heterogeneous applications
25

(read the slide)

25
10/23/2005

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.”
26

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.

26
10/23/2005

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

27

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.

27
10/23/2005

Macro web services – Virtual

Systems
Web Services
A web service is accessed
programmatically by Bank Balance
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 28

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.

28
10/23/2005

Micro web services – Virtual Apps

A web service is accessed Web Services
programmatically by
applications or other Bank balance
Spell Check
web services
Grammar Dictionary

Thesaurus
Word Processing

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

29
10/23/2005

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

30

30
10/23/2005

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

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.

31
10/23/2005

Myth: Web Services is a New

Concept
? Web services is distributed computing all over
again – only now it is based on the web

Concept Distributed Computing ala CORBA / 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 ?

32

32
10/23/2005

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

33

33
10/23/2005

Where is &
Where is Web Services
going?

34

34
10/23/2005

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

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 toward 35
Web services model.
10/23/2005

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
36

36
10/23/2005

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
37

37
10/23/2005

Web Services Adoption Phases

? 1st Phase – Simple Web Services (Now)
? Consumer-focused, stateless, SOAP over HTTP/S
nd
? 2 Phase – EAI Web Services (Begun)
? Deployed within organization boundaries to
enable internal integration
? 3rd Phase – Business Web Services (2004?)
? Deployed on extranets to enable business
transactions with trading partners, suppliers, and
customers, ebXML & UBL
38

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.

38
10/23/2005

Business Web Services

? J2EE TM
? 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
?
Identity system standard
39

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.

39
10/23/2005

Business Web Services (B2B)

Architectural Components (ebXML)
? B2B collaboration
? Secure and reliable message delivery
? Non-repudiation
? Partner profile
? Repository for business data objects

40

40
10/23/2005

Simple Web Services (WUS) vs.

B2B Collaboration (ebXML)
Simple Web Services B2B Collaboration
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 profile
l Not secure, not l Secure and reliable and
reliable non-repudiation
l Does not support l Supports non-
non-repudiation repudiation
l No repository support l Registry and repository
l No legal binding l Supports legal binding
41

S
10/23/2005

EAI vs. B2B Collaboration (ebXML)

EAI B2B Collaboration

l Within a business l Between 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
participants
42

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.
10/23/2005

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
43

43
10/23/2005

Simple Web Services Architectural

Components (WUS)

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

44

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.

44
10/23/2005

Core Web Services

Standards

45

45
10/23/2005

(Simplified) Web Service

Architecture

Registry

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

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.

46
10/23/2005

SOAP
(Simple Object
Access Protocol)

47

47
10/23/2005

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

48

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.

48
10/23/2005

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
49

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.

49
10/23/2005

What does SOAP Define?

? Message Envelope
? Encoding Rules
? RPC Convention
? Binding with underlying protocols

50

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.

50
10/23/2005

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

51

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.

51
10/23/2005

SOAP Message Envelope

? Encoding information
? Header
– Optional
– Could contain context knowledge
? Security
?
Transaction
? Body
– RPC methods and parameters
– Contains application data
52

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.

52
10/23/2005

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

53

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.

53
10/23/2005

SOAP RPC Request Example

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=" … "
SOAP-ENV:encodingStyle=" … " >
<SOAP-ENV:Header>
<!-- Optional context information -->
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m=“some_URI " >
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
54

Now let's talk about SOAP RPC. This is a very simple example of SOAP
RPC message. As you can see here, the SOAP message envelope contains
namespace information and could contain encoding information as
attributes of Envelope element.
It contains optional SOAP header which could contain context
information.
Then it contains SOAP body part which contains a single method with its
parameters. And in this case, the method is GetLastTradePrice with a
single parameter SUNW whose type is tickerSymbol.

54
10/23/2005

SOAP RPC Response Example

<SOAP-ENV:Envelope
xmlns:SOAP-ENV=" … "
SOAP-ENV:encodingStyle=" … " >
<SOAP-ENV:Header>
<!-- Optional context information -->
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m=“some_URI " >
<price>30.5</price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
55

And this is the response to the previous request. In this example, the body
contains GetLastTradePriceResponse and price elements.

55
10/23/2005

SOAP RPC
? Information needed for a method call:
– The URI of the target object

<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes" >
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

56

Just to recap what you need to construct SOAP RPC message. First you
need to specify the URI of the target object as name space attribute of the
method element. Target object is the destination to which you are sending
the SOAP message.

56
10/23/2005

SOAP RPC
? Information needed for a method call:
– The URI of the target object
– Method name

<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes" >
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

57

Next, you have to provide the method. In this case, GetLastTradePrice is

the name of the method. Please note that all these are represented in XML.

57
10/23/2005

SOAP RPC
? Information needed for a method call:
– The URI of the target object
– Method name
– Parameters
<SOAP-ENV:Body>
<m:GetLastTradePrice
xmlns:m=“http://stocks.com/StockQuotes" >
<tickerSymbol>SUNW</tickerSymbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>

58

Finally, you have to specify parameters that go with the method. In this
case, there is only one parameter, SUNW, whose type is tickerSymbol.

58
10/23/2005

Quick WSDL Tutorial

59

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

59
10/23/2005

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

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.

60
10/23/2005

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

61

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.

61
10/23/2005

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

62

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.

62
10/23/2005

WSDL Elements
? Types
? Message
? Operation
? Port Type
? Binding
? Port
? Service
63

WSDL specification defines 7 element types.

63
10/23/2005

WSDL Elements
? Types
– Data type definitions
– Used to describe exchanged messages
– Uses W3C XML Schema as canonical type
system

64

First, types element. Types element in WSDL document

define data types such as string or integer or custom data
type. These data types are used to describe the messages
being exchanged. And they use W3C XML schema as a
canonical type system. So let's take a look at an example.

64
10/23/2005

WSDL Example: Types

<definitions name="StockQuote"
targetNamespace="http://example.com/stockquote.wsdl"
xmlns:tns="http://example.com/stockquote.wsdl"
xmlns:xsd1="http://example.com/stockquote.xsd"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/”>
<types>
<schema targetNamespace="http://example.com/stockquote.xsd"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<element name="TradePriceRequest">
<complexType>
<all>
<element name=”tickerSymbol" type="string"/>
</all>
</complexType>
</element>
<element name="TradePrice">
<complexType>
<all>
<element name="price" type="float"/>
</all>
</complexType>
</element>
</schema>
</types> 65

By the way, this WSDL document that I am going to show you in several
slides is a complete WSDL document.
First, it defines several XML namespaces.

The types element in this example define two data types whose names
happened to be TradePriceRequest and TradePrice. TradePriceRequest
defines tickerSymbol which is a string type and TradePrice defines price
which is float type.

And as you will see later on, these data types, TradePriceRequest and
TradePrice will be used to describe messages.

65
10/23/2005

WSDL Elements
? Messages
– Abstract, typed definitions of data being
exchanged
? Operations
– Abstract description of an action
– Refers to an input and/or output messages
? Port type
– Collection of operations
– Abstract definition of a service

66

I mentioned to you, WSDL contains abstract definitions of

messages and operations.
So message element define abstract and typed definitions of
data being exchanged while operation is an abstract description
of an action using those messages. And finally port type
element is just a collection of operations.
Now before I lose you folks completely, let's take a look an
example.

66
10/23/2005

Example:
Messages, Operation, Port type
<message name="GetLastTradePriceInput">
<part name="body" element="xsd1:TradePriceRequest"/>
</message>

<message name="GetLastTradePriceOutput">
<part name="body" element="xsd1:TradePrice"/>
</message>

<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
<input message="tns:GetLastTradePriceInput" />
<output message="tns:GetLastTradePriceOutput"/>
</operation>
<!-- More operations -->
</portType>
67

In this example, two messages are defined - the first one is called
GetLastTradePriceInput and the other one is called GetLastTradePriceOutput. As you
can tell, these are request and response messages of stock quote service. Now please
note that message definitions refer to the data types we just defined, TradePriceRequest
and TradePrice.

Now I said portType is just a collection of operations. In this example, we have only
one operation. What is an operation? As I said in previous slide, it is an action, and an
action is made of input and/or output messages we just defined using message
elements. So in this example, the GetLastTradePrice operation will be performed as a
combination of input message, GetLastTradePriceInout, and output message,
GetLastTradePriceOutput message.

Please note that here there is no mentioning on which XML protocol or transport will be
used. This is why we call these elements as abstract definitions. And obviously they
have to be bound to a concrete XML and transport protocol. And that is what we are
going to see in the next slide.

67
10/23/2005

WSDL Elements
? Binding
– Concrete protocol and data format for a particular
Port type
– Protocol example: SOAP 1.1 over HTTP or SOAP 1.1
over SMTP
? Port
– Defines a single communication endpoint
– Endpoint address for binding
– URL for HTTP, email address for SMTP
? Service
– Aggregate set of related ports 68

So WSDL document has Binding element which specifies the binding of a

port type, which is a collection of abstract operations, to a concrete
transport protocol and data format.

I mentioned that a service is a set of communication endpoints and those

endpoints are called as ports. So port element defines an address for
transport protocol that was selected for binding. For the HTTP protocol, it
would be in the form of URL while for SMTP protocol, it will be in the
form of email address.So let's take a look an example.

68
10/23/2005

Example: Binding, Port, Service

< binding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
< operation name="GetLastTradePrice">
<soap:operation
soapAction="http://example.com/GetLastTradePrice"/>
<input> <soap:body use="literal" />
</input>
<output> <soap:body use="literal" />
</output>
< /operation>
< /binding>

< service name="StockQuoteService">

<documentation>My first service</documentation>
< port name="StockQuotePort" binding="tns:StockQuoteBinding ">
<soap:address location="http://example.com/stockquote"/>
< /port>
< /service>

69

So in this example, the portType called StockQuotePortType is bound to

SOAP as communication protocol. SOAP can support either document
style or RPC style. In this example, document style is chosen.

And the data format of the operation named GetLastTradePrice will use
literal.

Finally this service has one communication endpoint which is represented

by one port element which specifies the endpoint address for a particular
protocol. And in this example, the address happened to be
http://example.com/stockquote.

69
10/23/2005

UDDI

70

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

70
10/23/2005

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

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.

71
10/23/2005

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
72

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.

72
10/23/2005

Other
Web Services
Standards

73

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

73
10/23/2005

ebXML

A global electronic market place where

enterprises of any size, anywhere can:
– Find each other electronically
– Conduct business through exchange of XML
based business messages
74

ebXML effort was started by two international organizations,

UN/CEFACT (United Nations Center for Trade Facilitation and Electronic
Business) and OASIS (Organization for Advancement of Structured
Information Standards) with a vision to build a open framework in which
any business organization regardless of its size can participate in a global
electronic market place.
In other words, ebXML will enable businesses find each other
electronically and conduct businesses through the exchange of XML-based
business messages.

74
10/23/2005

More Web Services Standards

? Security
– XML Signature, XML Encryption, XKMS, XACML, SAML,
Liberty, WS-Security
? Transaction
– BTP, WS-Transaction
? Business collaboration and choreography
– ebXML BPSS, ebXML CPP/CPA, BPML, WSFL, XLANG,
WSCI, BPEL4WS

75

75
10/23/2005

More Web Services Standards

? Business Language
– UBL (Universal Business Language)
? Component model
– WSIA (Web Services for Interactive Application)
? Portal
– WSRP (Web Services for Remote Portals)

76

76
10/23/2005

Java APIs
for Web Services

77

Now let's quickly go over Java APIs for web services.

77
10/23/2005

Java APIs for SOAP, WSDL,

UDDI
? SOAP Messaging
– JAXM (JSR 67), SAAJ, JAX-RPC (JSR 101), JMS
? WSDL
– Java API for WSDL (JSR 110)
– JAX-RPC (JSR 101)
? UDDI
– JAXR (JSR 67)

78

Now what is Java community doing regarding Web services?

First, Java APIs for SOAP, WSDL, UDDI. For SOAP messaging, we have JAXM,
SAAJ, JAX-RPC, and even JMS.

For WSDL, we have Java API for WSDL for creating, manipulating, querying
WSDL documents. This API is expected to be used by tool vendors. The more
important API for developers is JAX-RPC.

For UDDI, there is JAXR.

78
10/23/2005

Java APIs for ebXML

? ebXML Message Service (TR&P)
– JAXM (JSR 67) with ebXML Message Service profile
? ebXML Registry/Repository
– JAXR (JSR 93)
? CPP/CPA
– Java API for ebXML CPP/CPA (JSR 157)

79

For electronic business framework. JAXM with ebXML message service profile
will let you perform service invocation with higher level of security and
reliability.

JAXR will also support ebXML reg/rep.

There is also a new JSR, JSR-157, which was submitted recently whose goal is to
define standard Java APIs for creating, manipulating, and processing ebXML
CPP/CPA.

79
10/23/2005

J2EE Web Services Framework

? J2EE 1.4 (JSR 151)
? Web services for J2EE (JSR 109)
? JAX-RPC (JSR 101)
? JAXR
? SAAJ
? EJB 2.1

80

This slide is here for the sake of completeness. Since we already talked
about these, I will not talk about them here again.

80
10/23/2005

Java APIs for XML

Document Management
? JAXP (Java API for XML processing, JSR 05)
– Assembly language for XML document processing
? JAXB (Java API for XML data-binding, JSR 31)
– Higher level language for XML document processing
? Streaming API for XML (JSR 173)
– Pull-parsing API based on Iterator
– Gives parsing control to programmers
81

There are also Java APIs for XML document management, JAXP for parsing and
transformation of XML documents and JAXB for XML data binding.

The way I explain the difference between JAXP and JAXB is that JAXP is like
assembly language of XML document management because you have to create
yourself the Java objects from the parsed XML document while JAXB is like high-
level language like Java since from XML schema you can create corresponding Java
class.

Now there is another JSR effort which got just started. And that is JSR 173, the
Streaming API for XML (StAX) parsing. It will specify a Java-based, pull-parsing
API for XML. The streaming API gives parsing control to the programmer by
exposing a simple iterator based API. This allows the programmer to ask for the next
event (pull the event) and allows state to be stored in a procedural fashion. Two
recently proposed JSRs, JAXB and JAX-RPC, highlight the need for an XML
Streaming API. Both data binding and remote procedure calling (RPC) (need better
statement here.). A streaming API makes this type of code much more natural to write
than SAX, and much more efficient than DOM.

81
10/23/2005

Java APIs for XML Security

? XML Digital Signature (JSR 105)
? XML Encryption (JSR 106)
? XML Trust Service (JSR 104)
? Secure Assertion Markup Language
(SAML, JSR 155)
? WS-Security (JSR 183)

82

Also there are Java community efforts defining APIs for XML-based
security schemes.

First, Java API for XML digital signature for authentication, non-
repudiation, and tamper-proofing. And XML encryption is for
confidentiality. XML trust service is for XML-based PKI system
mainly based on XKMS (Extensible Key Management Specification).
JSR 155 defines standards Java APIs for SAML, Secure Assertion
Markup Language. A newly started JSR defines Java APIs for WS-
Security effort of OASIS.

82
10/23/2005

More Java APIs for Web

Services
? XML Transactioning API for Java (JSR 156)
– Java API for OASIS BTP
? Web Services for J2ME (JSR 172)
– SOAP messaging for J2ME devices
? Web Services Metadata for J2EE (JSR 181)
– Metadata based Web services

83

Now there are even more Java API initiatives going on.
JSR 156 defines standard Java APIs for XML based transactioning.
This is based on BTP, Business Transaction Protocol effort going on
in OASIS.

Java Process component API is for defining a loosely coupled, event

based process component model that will simplify the
development of composable, customizable services

Web services for J2ME defines optional packages that would be

needed for J2ME devices to access web services.

The web services metadata for J2EE effort will enable the metadata
based web services development and deployment over J2EE, which
will be leveraged by tool vendors. The idea is to allow developers to
specify web services functionality in metadata instead of being forced
to do web services programming.

83
10/23/2005

Web Services Framework

for J2EE

84

84
10/23/2005

J2EE Platform& Web Services

B2B
Applications

Existing
Applications
B2C
Applications

Web
Services
Application Server
Wireless Enterprise
Applications Information
Systems

85

85
10/23/2005

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
86

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.
86
10/23/2005

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

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.

87
10/23/2005

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

88

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.

88
10/23/2005

J2EE Web Services Framework

? J2EE 1.4
– Umbrella framework for Web services
– JSR 109, JAX-RPC, JAXR, EJB 2.1, Servlet 2.4,
? JAX-RPC
– Defines client programming model
– Defines Servlet-based Web services endpoint
model

89

89
10/23/2005

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

90

90
10/23/2005

Web Services Architecture

over J2EE

91

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

91
10/23/2005

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
92

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.

92
10/23/2005

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)

93

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)

93
10/23/2005

Web Service Components

Web services
components

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

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.

94
10/23/2005

Java Technology-based
Web Services Tools

95

95
10/23/2005

Web Services Tools for Java

Platform
? Web Services Tools (Available Now!)
– Tools that come with reference implementations of Java
APIs for Web services (JAX-RPC RI)
– Systinet (Idoox), Iopsys, Cape Clear, Apach SOAP
? IDE's (Now!)
– Sun Java Enterprise Studio 7
– JBuilder ™ from Borland
– JDeveloper™ from Oracle
– WebGain™ from WebGain
96

Another areas that is very important to developers is of course tools.

As I mentioned earlier, there are already Java-based commercial and open

source tools out there that you can use to implement simple Web services.
Please note that the reference implementations of Java APIs for Web
Services come with their own set of tools. For example, JAX-RPC has
xrpcc which can be used to create WSDL file from existing Java classes
and vice versa.

You can be also assured that leading IDE vendors will provide Java-based
web service modules that are well-integrated with their existing
development environments.

96
10/23/2005

J2EE 1.4
? Focus is Web services
– Umbrella JSR for all Java APIs for Web services
?
JSR 109, JAX-RPC, JAXR, EJB 2.1
– Web services framework for J2EE
– J2EE component model, deployment,
packaging, and container requirements
? Released in Nov. 2003
– http://java.sun.com/j2ee/1.4/download-
dr.html

97

97
10/23/2005

J2EE 1.4 SDK

? Web services APIs are well integrated
? Contains
– JAXP, SAAJ, JAX-RPC, JAXR
– Sun Java App Server PE 8
– Extensive tutorial

98

98
10/23/2005

Summary

99

99
10/23/2005

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

100

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.

100
10/23/2005

Passion!

101

101