Académique Documents
Professionnel Documents
Culture Documents
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
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
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.
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
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
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.
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
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 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
? 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.
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
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.
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
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
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
23
Web Services Usage Example
Distributor
XML
XML
Manufacturing
Supplier Internet Facility
XML
XML
Logistics
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
Application
A Computer
The Network
25
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
Another impact of web services is that they will trigger the Network Effect
for integration technology.
29
Myth: Web Services is a New
Concept
? Web services is distributed computing all
over again – only now it is based on the web
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.
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.
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)
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.
41
Simple Web Services Architectural
Components (WUS)
? Service Description
? Service Registration (Publication)
and Discovery
? Service Invocation
42
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
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
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.
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.
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
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.
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
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
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
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
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
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
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
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
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
Sun ONE is open framework for service on demand paradigm and web
services is part of it.
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