Transcript 08a-Web servicesx

WEB SERVICES
FIRST AND FOREMOST - LINKS
 Tomcat 6.0 - http://tomcat.apache.org/download-60.cgi
 AXIS2 - http://axis.apache.org/axis2/java/core/download.cgi
 NetBeans - http://netbeans.org/downloads/index.html
 How to setup Tomcat server in NetBeans with Axis -
http://netbeans.org/kb/docs/websvc/gs-axis.html
 Creating Axis2 Web Services on NetBeans http://netbeans.org/kb/docs/websvc/gs-axis.html
 Creating Web Service Client http://netbeans.org/kb/docs/websvc/client.html
 Official JEE tutorial http://download.oracle.com/javaee/6/tutorial/doc/index.html
JAVA AND THE (INTERNAL) WEB
 This is JEE (or J2EE, or Java Enterprise Edition)
 Most programs use client/server paradigm
 Instead of implementing Servers and communication code every time,
there is a framework of protocols for servers that can execute Java
code
 There are different implementations of JEE servers – Apache, Tomcat,
Glassfish (and more, and more…)
 These servers can run multiple types of logic code
 It’s actually more complicated than this… but let’s keep it simple for
now
WEB SERVICES
 Try to solve the problem of exposing data without the need for the
server and client to be written in the same programming
language (or by the same developer, or the same environments, or
anything the same)
 How ?
 Server (da!?)  get requests from Client (da!?!?)  returns responses
(well… da!?)
WEB SERVICES
 There are three protocols that are used here:
 WSDL (Web Services Description Language) - an XML file that
describes the methods, parameters and return values for the service in
the server
 XML (Extensible Markup Language) - for the data (so anyone can read
it… it’s just text in a certain format)
 SOAP (Simple Object Access Protocol) - for moving (that mean
serializing and sending over the net) the data between client and server
 Oh… all this stuff runs over HTTP protocol…
WEB SERVICES WITH AXIS2 AND TOMCAT
 Web services can be implemented in different languages and in each
language with different implementations
 We’re using AXIS2
 But parsing XML messages and send XML messages is not enough
 Someone needs to handle the HTTP requests and responses (just like
any web server)
 And for that we’re going to use Tomcat
TOMCAT
 Tomcat is a JEE web server
 It can run web sites
 But it can also runs Java code
 Just link ANY other web server it handles the protocol of HTTP
requests and HTTP responses
 The Java code that runs on a JEE server is call a Servlet
 If we want to run web services we need a Servlet that runs it
 And that is AXIS2
AXIS2
 AXIS2 is a code that knows how to handle Web Services requests and
responses
 It’s basically an XML parsing engine
 It handles web requests that the Tomcat server send to it
 It extracts the XML message from the HTTP request
 Send it to any logic we deploy in it
 And then do the opposite with the response
 Basically, is a Java code that runs Java code (that going to be YOUR
code!)
THE PROCESS
 You write your server code (with business logic)
 You package it (what !?) into an AXIS web container
 (Packaging means taking all the compiled classes, resource and some
XML files and placing them in a zip file – but with a different extenstion
like JAR, WAR, AAR)
 You deploy this it into AXIS2
 Either AXIS2 will refresh automatically or you’ll need to refresh it
manually
 That’s it! (for the server part)
CLIENT/SERVER PARADIGM
 What does it mean to write client/server code ?
 It means that most of the business logic is written in the server side
 The server and the client have a shared context – meaning, the server
knows how to dispatch different results for the same methods for
different clients
 A Session is the term for the lifespan of a client with a server
 A session is alive only as long as the client is alive
 The clients are “simple” and just show the server data (in their context)
CLIENT/SERVER PARADIGM
 So when converting an application to run in a client/server mode, you’re
actually writing two programs
 The client side should:
 Have a communication layer with the server
 Convert the server data to its own internal model
 The server side should:
 Know how to handle multiple clients
 Save a context for each client session