Download COMP534B Software Design Overview Server

Overview
COMP534B Software Design
Server-side component programming
• Intro to Java server-side components
• Java’s EJBs (Enterprise Java beans)
• Application servers (J2EE) and web services
• We’ll take a look at coding and deploying some
simple java components as server-side SOAP
web services
• Apache Axis (open source SOAP engine written in
Java)
• Installing an Axis server on a servlet engine (such as
Tomcat)
• Writing simple web services using the Axis SOAP
libraries
Server-side Components
• Form the basis of large scale distributed services
• Actual components tend to be pretty straight-forward
• Technologies involved in supporting them are many
and varied, and things tend to get complicated
• Many buzzwords and acronyms :-)
• Issues include:
• Communications (many a protocol)
• IIOP (CORBA), ORPC (DCOM), RMI (Java), SOAP…
• Scalability
• Database transaction handling
• Security
J2EE Platform
Server-side Components
• Enterprise JavaBeans (Java’s offering)
• Standard java components that implement various interfaces
to allow them to interact and be managed by a J2EE
application server
• Application servers are typically large, complicated and
expensive beasts
• J2EE application server abstracts away the details of
underlying services
• Made implicit rather than explicit via deployment descriptors
• Programmers use a tool to provide declarative statements that form
deployment descriptors
J2EE Containers
• Three kinds of containers/components
• A J2EE application server that is compliant with the
J2EE specification must provide services and APIs for:
•
•
•
•
•
•
•
•
•
•
Enterprise JavaBeans (EJB)
Java Database Connectivity (JDBC)
Java Servlets
JavaServer Pages (JSP)
Java Message Service (JMS)
Java Naming and Directory Interface (JNDI)
Java Transaction API (JTA)
Java Mail API
Java API for XML processing
Java Authentication and Authorization Service (JAAS)
• Client components (correlate to client containers)
• Web components—servlets and JSPs
• EJB components
• Any or all of the containers and components may be on the
same or multiple machines
• Communication is via Java RMI (remote method invocation)
1
Types of EJBs
• Two main types of EJBs: Session beans and
Entity beans
• Session beans
• Encapsulate application logic
• Act as controllers for other beans
• Carry out tasks on behalf of a client
• Entity beans
• Represent persistent objects—basically data—that
exists beyond a specific application’s lifetime
• Typically stored in a relational database
• Persistence can be handled entirely by the container or
implemented manually by the developer
EJB Components
• Two interfaces:
• Home interface
• Defines lifecycle methods
• Creating, removing and finding beans
• Allows the container and the client to obtain a reference to a
specific bean
• Developer writes the interface and the container generates
the implementation
• Component interface
• Defines business methods callable by clients
• Client uses a bean’s Home interface to obtain a local
proxy object for the bean that implements the
Component interface
• Proxy object hides comms “plumbing”—i.e. RMI code
Web Services
• Definition
A Web service is a software system identified by a URI, whose public
interfaces and bindings are defined and described using XML. Its definition
can be discovered by other software systems. These systems may then interact
with the Web service in a manner prescribed by its definition, using XML
based messages conveyed by Internet protocols
• Key defining factor is the use of XML to describe the
service and carry messages
• Since it is plain text, XML is easily accessible from a variety
of platforms
• From a Java perspective a web service can be thought
of as a set of functions provided by a set of Java
objects available at a particular network address
Why Use SOAP-based Web
Services?
• Obtaining services provided by a platform other than
the one you are working can be tedious
• E.g. Java client accessing a DCOM service
• Requires a Java/COM bridge that translates JRMP (Java Remote
Method Protocol) to ORPC (Object Remote Procedure Call), and
vice versa
• Web services based on XML are easier to debug
• Easier to read XML than a binary stream
• Protocols such as SOAP are based on vendor-agnostic
technology: XML, HTTP, SMTP
Web Services
• Success and adoption of web services depends on
• WSDL (Web Services Definition Language)
• Standards-based way of describing a Web service
• SOAP (Simple Object Access Protocol)
• XML-based wire protocol
• HTTP as transport
• UDDI (Universal Description, Discovery, and
Integration)
• Standards-based way of publishing and locating a Web
service
• Public UDDI registries are provided by IBM, Microsoft
etc.
Disadvantages
• Objects can’t be transmitted
• Can transmit simple types, data structures
composed of simple types and arrays
• Minor performance hit due to having to
marshal / unmarshal (convert) each request
into relatively bulky XML text, as opposed
to binaries
• Appeals to all vendors
• Toolkits are freely available to developers
2
SOAP
• SOAP uses XML as the data-encoding format
• Not original to SOAP—XML-RPC and ebXML use
XML as well
• Consider the following Java interface:
public interface Hello {
public String sayHelloTo(String name);
}
• Client calling sayHelloTo() would receive a
personalized “Hello” message from the server
SOAP
• Say we wanted to serialize the method call to
XML for sending to a server, we might use a
request format something like:
<?xml version="1.0"?>
<Hello>
<sayHelloTo>
<name>John</name>
</sayHelloTo>
</Hello>
• Root node is the interface name Hello
• Method and parameter names are also nodes
SOAP
SOAP
• Assume the response looks like:
• Now we must deliver this request to the server
• Could create our own TCP/IP protocol, but easier
just to use an existing one like HTTP
• Package the request into the form of an HTTP
POST request and send to the server
• Server receives the request, decodes the XML
and sends the client a response in XML
<?xml version="1.0"?>
<Hello>
<sayHelloToResponse>
<message>Hello John, How are you?</message>
</sayHelloToResponse>
</Hello>
• The root node is still the interface name Hello
• The node name is the method name plus the string
Response
• Client knows which method it called, therefore to find the
response it only has to look for an element with that named
method plus “Response”
• This is basically the roots of SOAP
SOAP
SOAP
• Here is the same request encoded in SOAP:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”
xmlns:xsi=“http://www.w3.org/1999/XMLSchema-instance”
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Header>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<ns1:sayHelloTo
xmlns:ns1="Hello”
SOAP-ENV:encodingStyle=”
http://schemas.xmlsoap.org/soap/encoding/">
<name xsi:type="xsd:string">John</name>
</ns1:sayHelloTo>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
• Looks more complicated, but is actually
similar to what we did before
• SOAP document is organized into
• An Envelope (root node)
• A header section
• Used to encapsulate data that is not tied to a specific
method
• Could be used to provide context knowledge such as a
transaction ID or security info
• A body section
• Contains method specific info
3
SOAP
• Heavy use of XML namespaces
• SOAP-ENV, xsi and xsd map to standard namespaces that
all SOAP documents have
• Hello is not a node. Now it refers to a namespace, ns1
• Along with the parameter value, type info is also sent
to the server
• Envelope’s encodingStyle attribute
• Value informs the server of the encoding style used to
encode—i.e., serialize—the method
• Server requires this info to successfully deserialize the
method
SOAP
• The response would be:
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance”
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:sayHelloToResponse
xmlns:ns1="Hello”
SOAP-ENV:encodingStyle=”
http://schemas.xmlsoap.org/soap/encoding/">
<return xsi:type="xsd:string">
Hello John, How are you doing?
</return>
</ns1:sayHelloToResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Part V Assignment (25%)
• Aim: to explore session-oriented component
programming in Java using the Apache Axis SOAP
libraries
• Due: Friday, 22nd September
• Learning goals:
• Understanding web services
• Some experience with programming server-side components
• Some experience with using a widely available SOAP library
• Use Axis SOAP libraries to develop components for a
web service that simulates an online bookstore
• E.g. like Amazon but much, much, much simpler :-)
Part V Assignment (25%)
• You will need to:
• Design a programmatic interface to your online
bookstore
• Generate server-side implementation skeleton,
client-side stubs, WSDL and WSDD descriptors
using the tools provided with Axis
• Find out how Axis supports “Session” scoped
services
• Fill in the implementation for the generated files
• Write a client program to access your web service
Part V Assignment (25%)
• Requirements—a client that accesses your web
service will be able to:
•
•
•
•
•
Obtain a list of books by genre
Add books to their “shopping cart”
See how many items are in their shopping cart
View their shopping cart
Proceed to checkout
• Get a summary of their purchases
• See the total cost
• Files and in memory data structures are sufficient for
holding the book catalogue and shopping cart contents
Part V Assignment (25%)
• Deliverables
• A ready to deploy jar file that I can install on the
Axis SimpleServer or on the Axis web app
• Source code, WSDL and WSDD files
• User docs
• Design write up
• Including description of the approach taken, assumptions made,
program structure, algorithms, class hierarchy etc.
• An elegant, well designed system that meets the
requirements can achieve a grade of A
4
Part V Assignment (25%)
• Extra credit (some ideas)
• Having finite stock and allowing an “admin” client to restock
the bookstore
• Using a web-based Servlet or JSP as a client
• In this case your entire system should be able to be deployed on the
Tomcat Servlet engine
• Using a database instead of in memory data structures for
book and cart info
• Providing persistence beyond the session
• i.e. allow users to save the state of their cart
• Would require a login procedure
5