Web Services Overview

Web Services Overview

1

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

3

Waves of Network Computing Computers 108

Embedded Computers 1 011

Cars

TVs

Thermostats Switches Packages

Phones Games

Desktops

Things - 1 014

Clothes

Clients Functions Protocols Organization

Transfers

Transactions

IP v4

Content IP Layer

Telemetry

IP v6

Control

Waves of Network Computing

Things - 1 014

Embedded Computers 1 011

Thermostats Switches

Cars

TVs

Computers 10 8

Phone s

Desktops

Packages Clothes

Games

Clients Functions

Transfers

Transactions

Content

IP v4 IP Layer FT SMTP RMI/IIOP RMI/IIOP X Telnet RPC/XDR P Identity LDAP LDAP SOAP SOAP Organization HTTP Jini Client/Server UDDI

IP v6

Protocols

N-tier

Control

Telemetry

JXTA

Web Applications Web Services

Polyarchical Fractal

The New Software Payment X1

Developer

Locater

X10 66 New Service

X10 66 Calendar

Authentication

Shrink Wrap

Software-as-a-Service

User’s Device

History of Distributed Computing 7

Now let's talk a little bit of background history of distributed computing and see where web-application and web services model fit in.

7

Platform Evolution Catch Phrase

The Network Is the Computer

Scale

The Computer Network of Is the Embedded Network Things

Objects

Legacy to the Web

Network of Things

100s

1,000s

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

When/Peak

1984/1987

1990/1993

1996/1999

2001/2003

1998/2004

2004/2007

Leaf Protocol(s)

X

X

+HTTP (+JVM)

+XML Portal

+RM

Unknown

Directory(s)

NS, NS+

+CDS

+LDAP(*)

+UDDI

+Jini

+?

Session

RPC, XDR

+CORBA

+CORBA, RM

+SOAP, XML

+RM/Jini

+?

100,000,000 s

Schematic

This table shows the evolution of distributed computing considering several factors such as the number participating computing devices or software entities in the network, interaction behavioral or pattern among the participants, and underlying technologies used to enable those interactions. The commonality among these distributed computing technologies is that they are all used to deliver services in one form or another in a networking environment. In the beginning, we had a simple client and server model, which has then evolved into 3-tier and object-based remote computing model, which we will talk about later again in a bit more detail. Then they evolved into the current state of distributed computing technologies, which are illustrated in the middle tiers of the table bounded by a yellow box and they are web-based computing of today and web services computing of tomorrow. And they are the focus of J2EE architecture and Sun technologies and products right now. In the future where we expect massive number of computing devices and software entities are forming massive number of networks in a very dynamic fashion, we expect other service delivery technologies such as Jini and Jxta could be quite useful. Let's take a look at the communicating patterns of the different phases.

Communication Patterns ClientServer

3-Tier

Web Web Application Services

Hybrid P2P

Fractal

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

Communication Patterns: TM Java 2 Business Systems DB Server App Server

J2EE

Web Server Browser Client

J2SE/ 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. DB App Web Browser

XML (UDDI, SOAP)

J2EE J2SE/ J2ME

Context and Identity (LDAP, Policy, Liberty)

Web Service

This picture shows communicating pattern of web services in which business organizations are beginning to talk to each other leveraging loosely-coupled nature of web services.

What is a Web Service?

12

12

Web Services Definition by W3C ? ? ?

?

? ?

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

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

13

Distributed Computing Evolution

ClientServer(C/S) silos computing Web Services/Peer-to14 Peer

Let's think a little bit on how distributed computing technology has evolved. In the beginning, things were built and deployed typically in the form of client and server model in which clients talk to a single server, for example, doing remote procedure calls. The second phase can be called web-based computing in which many clients talk to many servers through the net. In this phase, communicating partners still have to go through some pre-arrangement in terms of what common object model they have to use or what common communication protocol they have to agree upon. Finally, the web services model. As we will see in the following slides, under web services model, service users and service providers can be dynamically connected. And the pretty much every computing device and application participate as both service user and service provider.

14

Traditional C/S vs. Web Services Web Service

Traditional C/S ? ?

? ?

? ?

Within enterprise Tied to a set of programming languages Procedural Usually bound to a particular transport Tightly-coupled Efficient processing (space/time)

? ?

? ?

? ?

Between enterprises Program language independent Message-driven Easily bound to different transports Loosely-coupled Relatively not efficient processing

15

Now let's compare traditional RPC which is the typical communication model used in the first generation distributed computing technology we just saw against Web services. First, traditional RPC is typically used within an enterprise while the real value of web services is to enable enterprise to enterprise communication in an ad-hoc manner over the internet. RPC is typically programming language dependent while Web services is programming language independent because as we will talk about again, the communication under Web services model is done by exchanging XML messages, which has no dependence on a particular programming language. RPC is typically tied up with a particular transport protocol while under Web services model, multiple transports can be easily supported because any transport protocol that can transport XML message can be used. You will hear a lot about "loosely-coupled" nature of Web services. Because, the only contract that have to be agreed upon between communicating parties under Web services is the syntax and semantics of XML messages, in other words, there is no need to agree on anything else. For example, there is no need to agree on object model, there is no need to agree on programming language, there is no need to agree on programming APIs. This is why we call Web services "loosely-coupled".

15

Web Application vs. Web Services Web Service

Web Application ?

?

?

User-to-program interaction Static integration of components Monolithic service

?

?

?

Program-to-program interaction Possibility of dynamic integration of components (in the future) Possibility of service aggregation (in the future) 16

Just to give you a sense on the differences between Web application which is the second generation distributed computing we saw and web service model. Web application in its current form is typically focused on between an end user and program while under web services model, program to program communication would be much more common form of communication. Also under web application model, things are pretty much in static mode. That is, in order to integrate various applications, you have to statically configure them to talk each other. Under web services model, things could be a lot more dynamic, that is, service users will find service provider and use the services of those providers more dynamically. Also under Web services model, services can be aggregated again in a adhoc and dynamic fashion.

16

Characteristics of Web Services ? ? ? ? ?

? ? ?

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

Just to recap the characteristics of Web services, Web services is XMLbased throughout. Pretty much everything in the domain of Web services is defined in XML. For example, the format of the data being exchanged between service user and service provider is defined in XML or the description of web service is defined in XML. Because the only contract that have to be agreed upon between service user and service provider is syntax and semantics of XML messages, as long as valid messages can be generated and understood, it does not matter what programming language is used. So Web service is said to be programming language independent. Web services can be dynamically located and invoked. And typically they will be accessed and invoked over both internet and intranet. We talked about the loosely-coupled nature of Web service already. And all these will be based on de facto and de jure industry standards such as SOAP, WSDL,UDDI and ebXML.

17

This is the high level web services architecture. The cloud at the top right hand side, the service grid, is a set of web services on the internet. These services are accessible to the various client devices shown at the bottom of the picture. When a web service is created, it registers itself to a service registry. By registering in the the service registry, the Web service exposes its interface to any client that is interested in accessing it. When a client requires a certain service, it first looks in the service registry, this is the service discovery phase. Once an appropriate web service has been located, the client then invokes the web service, which delivers the service to the client.

18

Service Assembly Macro Service

Micro Service

Business Process Management

Micro Service

Micro Service 19

Anatomy of an assembled macro service.

19

Service Aggregation User

Nasdaq Input: Symbol Output: Price

News feed 1

Stock Service Portal

Input: Symbol Output: News links

Input: Symbol Output: Price, News, Trade

News feed n Input: Symbol Output: News links

Brokerage 1

Brokerage n

Input: Symbol, Price, Qty

Input: Symbol, Price, Qty

20

Anatomy of an assembled macro service.

20

Why Web Services?

21

21

Why Web Services? Web Services: ? ?

?

?

? ?

Are platform neutral Are accessible in a standard way Are accessible in an interoperable way Use simple and ubiquitous plumbing Are relatively cheap Simplify enterprise integration 22

22

Why Web Services? ?

?

?

?

?

?

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

(read the slide)

23

Web Services Usage Example Distributor XML XML

Supplier

Internet XML

Manufacturing Facility

XML

Logistics

“Growing need for a standard lightweight infrastructure for data exchange in e-business applications.” 24

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

24

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

App Service

App Service

App Service

System Service

System Service

System Service

Application System Software A Computer

The Network 25

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

25

Macro web services – Virtual Systems A web service is accessed programmatically by applications or other web services

Web Services Bank Balance Net worth

Insurance Cash Value

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

Stock Position

Biz News

News

World News 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 accessed programmatically by applications or other web services

Web Services Bank balance Spell Check

Grammar

Thesaurus

Word Processing Media “Word processing” can be an application, a capability, or a web service itself

Dictionary

c:\...

Publishing

http://... 27

W

27

Three Laws of Computing ?

Moore's Law –

?

Gilder's Law –

?

Computing power doubles every 18 months Network bandwidth capacity doubles every 12 months

Metcalfe's Law (Net Effect) –

Value of network increases exponentially as number of participants increases 28

S

28

Impact on Integration: Trigger the Network Effect

Custom Integration

Web Services

Metcalfe’s Law: The value of the network is proportional to the square of the number of

29

Another impact of web services is that they will trigger the Network Effect for integration technology. Metcalfe’s Law describes the an effect that is often illustrated with an example of FAX machines. The first FAX machine had zero value because it could communicate with no one. When a second came on line, the value increased. And as the network reached a critical mass, it compelled more and more users to get FAX machines. This is also called the Network Effect.

29

Myth: Web Services is a New Concept ?

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

Concept Interface Description RPC support Service Registry Messaging support Transaction support Secuity support

Distributed Computing ala CORBA / Java CORBA IDL, Java interface ORBs, Idl2java compilers, rmic CORBA naming service, JNDI CORBA Event/Notification service, JMS CORBA Transaction service, JTS CORBA Security service, Java security

Basic Web Services WSDL SOAP, compilers for WSDL UDDI ? ? ?

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 toward Web services model.

33

State of Web Services ?

Technology/Standards are still evolving –

?

Business web services is the next big thing, but more works are needed in – – – –

?

SOAP, WSDL, UDDI are not enough

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

?

2nd phase (1 to 2 years) – –

?

Concerted deployment internally within an organization mainly for interoperability SOAP over HTTP/S 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) ?

?

2nd Phase – EAI Web Services (Begun) ?

?

Consumer-focused, stateless, SOAP over HTTP/S 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 ?

?

ebXML and UBL ? ?

?

?

Service implementation platform standard 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

37

Even though we believe simple web services and EAI are important forms of web services, we also believe the real value of web services lies with business web services. That is the reason why we are investing quite a bit of our engineering resources to key technologies that will enable business web services. First, we believe J2EE provides a standard-based implementation and deployment platform where not only simple web services and EAI web services but also business web services can be developed and deployed while maintaining all the benefits that come with the architecture, that is, scalability, reliability, availability, performance, security, flexibility, maintenability, portability, and extensibility. Second, we firmly believe ebXML and UBL (Universal Business Language) provide viable and only open-standards based business web services framework. And II want to say it loud and clear. ebXML is real and in fact there are more than 16 commercial vendors and open source-based products that support ebXML right now including Sun Microsystems's Secure Trading Agent. In fact, real life customers are using ebXML right now for solving real-life problems. For example, austrailian energy industry is using ebXML mesasging service for secure and reliable XML message delivery. And we believe ebXML adoption will accerlate during the next year or so. Third, Liberty project as Identity management standard which we strongly believe is critical to business web services and e-commerce of the future.

37

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

? ? ?

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

i

38

Simple Web Services (WUS) vs. B2B Collaboration (ebXML) Simple Web Services l l l l

l l

l

l

l

S

Simple interaction Consumer oriented Short-living process No business collaboration No partner profile Not secure, not reliable Does not support non-repudiation No repository support No legal binding

B2B Collaboration l l l l

l

l

l

l

Complex interaction Business oriented Long-running process Supports business collaboration Supports partner profile Secure and reliable and non-repudiation Supports nonrepudiation Registry and

39

EAI vs. B2B Collaboration (ebXML) EAI l

l

l l

Within a business organization Centralized control Implicit contract Small number of business processes and participants

B2B Collaboration l

l

l l

Between business organizations Distributed control Explicit contract Potentially large number of business processes and 40 participants

1.Centralization vs. Collaboration. A "Centralized model" allows the implementation of integration for EAI because in an Enterprise (even very big and sparse) the different departments are part of the same challenge and, normally, IT is a "shared service" among all the departments. The quality of integration (Integration Server vs MOM) models the ability to describe the "challenge" in a top-down or in a bottom-up way. A "Collaboration model" allows the implementation of integration for different entities, where there is no "central IT" shared by the different entities and where each entity needs to play a peer role. In this model, the "global challenge" of the integrated solution needs to be implemented in a way where each peer contributes to the overall goal (unless the partners agree on the fact that one of them is more important of the other... or agree to elect an ASP as a "shared" resource) 2.Explicit vs. Implicit contract. It is often the case that, within an enterprise, the integrated solution is mandated by the Board of Management (or equivalent) in order to optimize the use of internal resources and to decrease costs. In these situations, the participating departments are "mandated" to participate to the integrated solution; the "contract" linking each of them to the others is, in some way, defined "upfront". This translates into the fact that the EAI solution does not, normally, need to implement any kind of "agreement" because such agreement is, in some way, enforced by the shared IT department.

Trends Towards Service Orientation ? ? ? ?

Evolution of EAI to web service standards XML RPC => Asynchronous XML Messaging Towards de-centralization Componentized services – Composable and composite services – Data encapsulated within component – Data ownership follows component ownership

? ?

Brokered web services Flexible relationships => Adaptive businesses 41

41

Simple Web Services Architectural Components (WUS) ? ?

?

Service Description Service Registration (Publication) and Discovery Service Invocation

42

What are the core building blocks of web services architecture? At the minimum, you need a standard way of describing a web service that are universally understood by all potential service users and service providers. This is important because without commonly agreed upon description of service, a service provider might have to produce individually tailored way of describing its service to all its potential service users. There has to be registry by which a service can be published and discovered. Then there has to be standard way of invoking a service. Finally, for business transactions in which secure and reliable message delivery is important, there has to be a standard electronic business framework.

42

Core Web Services Standards

43

43

(Simplified) Web Service Architecture Registry 2. Client Request Service Location FIND

1. Service Registers PUBLISH

Web Service

3. Client calls Service BIND

Service Client 44

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

44

SOAP (Simple Object Access Protocol) 45

N

45

SOAP ? ?

Simple Object Access Protocol Wire protocol similar to – –

?

XML is used for data encoding –

?

IIOP for CORBA JRMP for RMI “text” based protocol vs. “binary” protocol

Supports XML-based RPC 46

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

46

What SOAP is Not ?

Not a component model –

?

Not a programming language –

?

So it will not replace objects and components, i.e. EJB, JavaBeans 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 (text/xml)

Header Entry Header Entry

Attachment Attachment

Attachment

SOAP Body Body Entry Body Entry

49

This picture shows the format of SOAP message, actually SOAP message with attachments. SOAP message is made of SOAP Envelope and zero or more attachments. The SOAP Envelope in turn is then made of header and body. What is SOAP attachment for? It allows the SOAP message to contain not only the XML data but also non-XML data such as binary graphics file. And it uses the MIME multipart as container for these non-XML data.

49

SOAP Message Envelope ? ?

Encoding information Header – –

Optional Could contain context knowledge ? ?

?

Security Transaction

Body – –

RPC methods and parameters Contains application data 50

We will see an example of SOAP message soon but the header is optional and it can contain so called context knowledge such as security or transaction related information while the body contains application data or remote procedure call method and it parameter information. Please note that the SOAP specification does not specify any of these contexts. But SOAP header structure can be extensible, and that is how ebXML messaging service provides security and reliability by defining elements that can be embedded in the header structure. And we will see an example later on. The message envelope also carries information on encoding.

50

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

• Compound values – Structs, arrays, complex types 51

Now what is encoding? As I mentioned before, it is a set of rules of how to express application-defined data types on the wire in XML form. SOAP encoding is based on W3C XML schema. What that means is that the SOAP messages are constructed using the data types defined in W3C XML schema. SOAP encoding supports both simple values and compound values. Simple values are the values of of built-in types from XML schema part 2 or enumeration or byte array. Compound values is constructed as a composite of several parts, each with a type and can be of struct or arrays or complex type.

51

WSDL 52

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

52

What is WSDL? • XML language for describing web services • Web service is described as – A set of communication endpoints (ports)

• Endpoint is made of two parts – Abstract definitions of operations and messages – Concrete binding to networking protocol (and corresponding endpoint address) and message format

• Why this separation? – Enhance reusability (as we will see in UDDI reference to WSDL document)

53

What is WSDL? WSDL is industry-agreed-upon XML language that can be used to describe web services. Under WSDL, a Web service is described as a set of communication endpoints that are capable of exchanging messages. These communication endpoints are called ports. An endpoint is made of two parts: The first part is abstract definitions of operations and messages. As you will see later on, operations and messages are related in that messages are exchanged for the purpose of performing the operations. The 2nd part is concrete binding of those abstract definitions of operations to concrete network protocol and message format. And one concrete example of network protocol is SOAP over HTTP. The whole idea of this separation of abstract definitions from concrete binding is to allow the reuse of abstraction definitions regardless of present or future network protocols.

53

Why WSDL? • Enables automation of communication details between communicating partners – Machines can read WSDL – Machines can invoke a service defined in WSDL

• Discoverable through registry • Arbitration – 3rd party can verify if communication conforms to WSDL 54

The key value proposition of WSDL as a standard description of web service is it enables automation of communication details in application to application communication. That is, machines can figure out from WSDL document what services are available and how to invoke them without manual pre-arrangement or pre-configuration between the two.

54

WSDL Document Example ? ?

? ?

?

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

Now, I am going to explain WSDL by using a simple WSDL document example. This example describes a very simple service which provides stock price quote, the same example we used in SOAP part of the presentation. That is, this service supports a single operation called GetLastTradePrice. And this service is deployed using SOAP 1.1 over HTTP. So from this WSDL document, a soap message we saw in our SOAP presentation can be automatically generated. The request takes a ticker symbol of type string and the response returns price whose type is float. As you will see, WSDL XML vocabularies define 7 XML elements.

55

UDDI

56

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

56

Service Architecture UDDI Registry 2. Client Request Service Location FIND

1. Service Registers PUBLISH

Web Service

3. Client calls Service BIND

Service Client

UDDI defines a way to publish and find information about Web services. 57

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

57

UDDI (Universal Description, Discovery and Integration) ?

“White pages” – address, contact, and known identifiers

?

“Yellow pages” – industrial categorizations ? ? ?

?

Industry: NAICS (Industry codes - US Govt.) Product/Services: UN/SPSC (ECMA) Location: Geographical taxonomy

“Green pages”

– technical information about services 58

Now what kind of information will be contained in the business registration data? They can be categorized into white pages, yellow pages, and green pages. The concept of white pages and yellow pages are not that much different from the ones we know in that white page contains information on a particular business entity, for example, name, contact information, address, or unique identification number while yellow page contains categorization information according to industry, product and service, or geographic location. Finally, green pages contains so-called technical information about the service which is basically meta information on services and this meta information has references to service definitions represented by WSDL document.

58

Web Services Framework for J2EE

59

59

J2EE Platform& Web Services B2B Applications Existing Applications

B2C Applications

Web Services

Application Server Wireless Applications

Enterprise Information Systems 60

60

Why J2EE for Web Services? ?

?

Web services is just one of many service delivery channels of J2EE –

No architectural change is needed

–

Existing J2EE components can be easily exposed as Web services

Many benefits of J2EE are preserved for Web services – –

Portability, Scalability, Reliability No single-vendor lock-in 61

Now, let's talk about the motivation for using J2EE as development and deployment platform for web services. As most of you already know, J2EE is an open standard platform for building enterprise applications in which business logic are captured and deployed as components. J2EE is also an end-to-end architecture where there are multiple programming models to implement and deploy these business logics. That is, there is servlet, there is JSP, there are EJB beans, and there is JMS. All these programming models provide somewhat different ways of implementing and deploying business logics over J2EE and you as developers choose one ore more of these programming models according to the needs and requirements of your applications. Now if you think about it, web services model is just another way of exposing the business logic of these components. There is no architectural or code change required to expose the existing J2EE components as web services . For example, as a service provider, in addition to exposing business functions captured in EJB beans by EJB remote interface over RMI/IIOP, you can also expose them via WSDL and handle the service by receiving SOAP message and send the result back in SOAP messages. What it means is that the existing J2EE components can be exposed as web services without any change in their code which also means the key benefits of J2EE such as open and standard platform, portability of code, availability of highly scalable and highly reliable platform products, are still preserved. And most of all, you can still choose the best of breed J2EE platform or J2EE applications including web services components without compromising the code portability.

61

Where Are We Now? ?

?

?

Java APIs for Web Services are being developed very rapidly Tools are available now for exposing existing J2EE components as Web services J2EE community has defined overall framework for Web Services (J2EE 1.4, JSR 109) 62

J2EE has proved itself as the platform of choice for building enterprise applications. Now what about web services? Where are we now and where are we going in terms of using J2EE as Web services platform? As many of you already know, Java community is feverishly working on defining Java APIs for web services. And THE primary platform that these Java APIs are designed for is J2EE. Tool vendors already have products out there that you can use to expose existing J2EE components such as EJBs as web services by basically providing a tool that can generate WSDL document from EJB beans and from the WSDL, a client stub can be generated which knows how to send and receive SOAP messages in order to use the service defined in WSDL. So you can expose business functions that you already have in J2EE as web services right now. Finally J2EE community is in the works to define overall Web services framework for J2EE through J2EE 1.4 and JSR 109 for the sake of portability of Web services.

62

Design Goals J2EE Web Services Framework ?

Portability of Web services component – –

?

?

Over different vendor platform Over different operational environment

Leveraging existing J2EE programming models for service implementation Easy to program and deploy – –

High-level Java APIs Use existing deployment model 63

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

63

J2EE Web Services Framework ?

J2EE 1.4 and Java EE 5 – –

?

Umbrella framework for Web services JSR 109, JAX-RPC, JAXR, EJB 2.1, Servlet 2.4,

JAX-RPC (JAX-WS) – –

Defines client programming model Defines Servlet-based Web services endpoint model 64

64

J2EE Web Services Framework ?

EJB 2.1 –

?

Servlet 2.4 –

?

Defines Stateless Session Bean-based Web services endpoint model Will be aligned with JAX-RPC

JSR 109 –

Defines standard Web services packaging and deployment model 65

65

Web Services Architecture over J2EE

66

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

66

What Is a Web Service? ?

?

A set of endpoints (ports) operating on messages Ports are operating within a container – –

?

Container provides runtime environment Contract for runtime environment are specified in JAX-RPC, EJB 2.1, JSR 109

Service is described in WSDL document and published to a registry –

WSDL specifies a contract between service provider and client 67

So what is a Web service? Under J2EE context, Web services are defined as a set of endpoints operating on messages meaning the endpoints receive request messages and then send back response messages. These endpoints are operating within a container, which provides Web services runtime environment in the same way EJB container provides runtime environment for EJB beans. And the contract between the Web services endpoints and the container are specified in JAX-RPC, EJB 2.1, and JSR 109. Another aspect to note is that a Web service is described in WSDL document and this service description can be published to a registry. What this means is that the WSDL document is the only thing that is needed between web service user and service provider in order to communicate.

67

Web Service Component and Container ?

?

Container vs. Component model –

Web services components get executed within a container

–

Components are portable (under J2EE 1.4)

Web service components –

Web-tier (Servlet-based endpoint)

–

EJB-tier (Stateless session bean-based endpoint) 68

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

68

Web Service Components Web services components

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

69

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

69

Summary

70

70

Summary ?

?

?

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

71

So in summary, Web services provides a new paradigm for program to program communication. Sun ONE is open framework for service on demand paradigm and web services is part of it. Java community is working feverishly to come up with a complete set of Java APIs for web services. And finally J2EE is the platform of choice for web services development and deployment. One last thing I would like emphasize is that we believe the real value of web services is in the area of business web services not in the things you see right now like temperature convertor or traffic report. And that is the area we will put lots of our resources.

71

Passion!

72

72