CPE3010 Lecture 5

1
CPE3010 Lecture 5

• Java and Web Services

2
Java and Web Services

• Many Java gurus/ developers HATE XML and Web
  services.
• - too slow, too high an overhead, and back to
  the future because RPC is used and real objects
  can not be passed. Also no leasing in UDDI
  (yet).
• BUT, Web Services are THE ONLY GAME IN TOWN, so
  Sun offers Java frameworks/ APIs for dealing with
  Web Services
• - Java APIs for XML Processing and Web
  Services JAXB, JAX- RPC
• - J2EE 1.4 provides support for web services
  through the JAX-RPC 1.1 API. It also supports JSR
  109, that builds on JAX-RPC.

3
Java APIs for XML Processing Web Services

• Document-oriented
• Java API for XML Processing (JAXP) -- processes
  XML documents using various parsers
• Java Architecture for XML Binding (JAXB) --
  processes XML documents using schema-derived
  JavaBeans component classes
• SOAP with Attachments API for Java (SAAJ) --
  sends SOAP messages over the Internet in a
  standard way
• Procedure-oriented
• Java API for XML-based RPC (JAX-RPC) -- sends
  SOAP method calls to remote parties over the
  Internet and receives the results
• Java API for XML Registries (JAXR) -- provides a
  standard way to access business registries and
  share information

4
Using Java and Web Services
5
Present and Future Java APIs
6
Java APIs

• Not used extensively
• Java API for XML Processing (JAXP) parsing and
  processing XML documents and a transformation
  engine supporting XSLT
• Java API for XML Registries (JAXR) defines Java
  APIs for accessing XML registries. It will
  support both ebXML registries and repositories
  and UDDI
• Java API for XML Messaging (JAXM) provides Java
  support for sending and receiving SOAP messages
• Used extensively
• Java Architecture for XML Binding (JAXB) makes it
  easy to map XML data into Java objects
• Java API for Remote Procedure Call (JAX-RPC), a
  procedure call is transmitted as XML.

7
JAXP

• - parses data as a stream of events or builds an
  object representation of it.
• - supports XSLT (XML Stylesheet Language
  Transformations), providing control over the
  presentation of the data and enabling you to
  convert the data to other XML documents or to
  other formats, such as HTML.
• - provides namespace support.
• - allows you to use any XML-compliant parser
  from within your application
• - also allows you to plug in an XSL processor,
  to control how your XML data is displayed.

8
Example Using JAXP

• http//java.sun.com/developer/technicalArticles/xm
  l/brazil/index.html

9
SAX API Simple XML Parsing

• Event-based parser that reads an XML document
  from beginning to end. Each time it recognizes a
  syntax construction, it notifies the application
  that is running it by calling methods from the
  ContentHandler interface.
• For example, when the parser comes to a less than
  symbol ("lt"), it calls the startElement method
  when it comes to character data, it calls the
  characters method when it comes to the less than
  symbol followed by a slash ("lt/"), it calls the
  endElement method, and so on.

10
Running XML Example

• ltpriceListgt   
• ltcoffeegt     
• ltnamegtMocha Javalt/namegt     
• ltpricegt11.95lt/pricegt   
• lt/coffeegt   
• ltcoffeegt     
• ltnamegtSumatralt/namegt     
• ltpricegt12.50lt/pricegt   
• lt/coffeegt
• lt/priceListgt

11
SAX Example

• ltpriceListgt   parser calls startElement   
• ltcoffeegt    parser calls startElement     
• ltnamegtMocha Javalt/namegt    parser calls
  startElement,  characters, and endElement     
• ltpricegt11.95lt/pricegt    parser calls
  startElement, characters, and endElement   
• lt/coffeegt    parser calls endElement

12
SAX, contd.

• You need to write a subclass implementing the
  appropriate methods to get the functionality you
  want.
• To get the price per pound for Mocha Java, write
  a class extending DefaultHandler (the default
  implementation of ContentHandler) to implement
  the methods startElement and characters.
• Create a SAXParser object from a SAXParserFactory
  object. You would call the method parse on it,
  passing it the price list and an instance of your
  new handler class (with its new implementations
  of the methods startElement and characters). In
  this example, price list is a file, but parse can
  also take other input sources, an InputStream
  object, a URL, or an InputSource object.
• SAXParserFactory factory SAXParserFactory.newIns
  tance()
• SAXParser saxParser factory.newSAXParser()
• saxParser.parse("priceList.xml", handler)

13
SAX, contd.

• The result of calling the method parse depends on
  how the methods in handler were implemented.
• The SAX parser will go through the file
  priceList.xml line by line, calling the
  appropriate methods.
• In addition to the methods already mentioned, the
  parser will call other methods such as
  startDocument, endDocument, ignorableWhiteSpace,
  and processingInstructions, but these methods
  have default implementations and do nothing.

14
SAX, contd.

• The following implements the methods characters
  and startElement so that they find the price for
  Mocha Java and print it out.
• These methods work together to look for the name
  element, the characters "Mocha Java", and the
  price element immediately following Mocha Java.
• These methods use three flags to keep track of
  which conditions have been met.

15
SAX Example, contd.

• public void startElement(..., String elementName,
  ...)
•   if(elementName.equals("name"))     inName
  true   
• else if(elementName.equals("price")
  inMochaJava )
•     inPrice true     inName false
    
• public void characters(char buf, int offset,
  int len)
•   String s new String(buf, offset, len)   
• if (inName s.equals("Mocha Java"))
•     inMochaJava true     inName false
    
• else if (inPrice)
•     System.out.println("The price of Mocha
  Java is " s)     
• inMochaJava false     
• inPrice false        

16
SAX, contd.

• Once the parser has come to the Mocha Java coffee
  element, here is the relevant state after the
  following method calls
• next invocation of startElement -- inName is true
  
• next invocation of characters -- inMochaJava is
  true
• next invocation of startElement -- inPrice is
  true
• next invocation of characters -- prints price

17
SAX, contd.

• SAX parser can perform validation while parsing,
  to check that the data follows the rules
  specified in the XML document's schema. A SAX
  parser will validate if it is created by a
  SAXParserFactory that has validation turned on.
  This is done for the SAXParserFactory object
  factory in the following line of code.
• factory.setValidating(true)
• The parser knows which schema to use for
  validation by an XML document. The schema for the
  price list is priceList.DTD, so the DOCTYPE
  declaration should be similar to this
• lt!DOCTYPE PriceList SYSTEM "priceList.DTD"gt

18
Object Model Parsing

• Document Object Model (DOM), defined by W3C, is a
  set of interfaces for building an object
  representation, in the form of a tree, of a
  parsed XML document.
• Once you build the DOM, you manipulate it with
  DOM methods such as insert and remove, as other
  tree data structures. Unlike SAX, a DOM parser
  allows random access to pieces of data in an XML
  document.
• With a SAX parser, you can only read an XML
  document, but with a DOM parser, you can build an
  object representation and manipulate it in
  memory, adding a new element or deleting one.

19
DOM, contd.

• In the previous example, SAX looked for one piece
  of data in a document. Using a DOM parser would
  have required having the whole document object
  model in memory, which is generally less
  efficient for searches involving just a few
  items, if the document is large.
• The next example adds a new coffee to the price
  list using a DOM parser. We cannot use a SAX
  parser for modifying the price list because it
  only reads data.
• Add Kona coffee to the price list. Read the XML
  price list file into a DOM and tinsert the new
  coffee element, with its name and price. The
  following code fragment creates a
  DocumentBuilderFactory object, which is then used
  to create the DocumentBuilder object builder. The
  code then calls the parse method on builder,
  passing it the file priceList.xml.

20
DOM Example

• DocumentBuilderFactory factory
  DocumentBuilderFactory.newInstance()
• DocumentBuilder builder factory.newDocumentBuild
  er()
• Document document builder.parse("priceList.xml")
  

21
DOM Example, contd.

• document is DOM representation of the price list.
  
• The following code adds a new coffee (with the
  name "Kona" and a price of "13.50") to the price
  list.
• Because we want to add the new coffee right
  before the coffee whose name is "Mocha Java",
  first get a list of the coffee elements and
  iterate through the list to find "Mocha Java".
• Using the Node interface in org.w3c.dom, the code
  creates a Node object for the new coffee element
  and the name and price elements. The name and
  price elements contain character data, so the
  code creates a Text object for each of them and
  appends the text nodes to the nodes representing
  the name and price elements.

22
DOM Example, contd.

• Node rootNode document.getDocumentElement()
• NodeList list document.getElementsByTagName("cof
  fee")
• // Loop through the list.
• for (int i0 i lt list.getLength() i)
•   thisCoffeeNode list.item(i)   
• Node thisNameNode thisCoffeeNode.getFirstChild(
  )   
• if (thisNameNode null) continue   
• if (thisNameNode.getFirstChild() null)
  continue   
• if (! thisNameNode.getFirstChild() instanceof
  org.w3c.dom.Text) continue   
• String data thisNameNode.getFirstChild().getNod
  eValue()   
• if (! data.equals("Mocha Java")) continue   

23
DOM Example, contd.

• //We're at the Mocha Java node. Create and insert
  the new element.   
• Node newCoffeeNode document.createElement("coff
  ee")   
• Node newNameNode document.createElement("name")
    
• Text tnNode document.createTextNode("Kona")   
• newNameNode.appendChild(tnNode)   
• Node newPriceNode document.createElement("price
  ")   
• Text tpNode document.createTextNode("13.50")
    
• newPriceNode.appendChild(tpNode)   
• newCoffeeNode.appendChild(newNameNode)   
• newCoffeeNode.appendChild(newPriceNode)   
• rootNode.insertBefore(newCoffeeNode,
  thisCoffeeNode)   
• break

24
DOM Output to XML

• To transform the DOM tree to an XML document, the
  following code first creates a Transformer object
  that will perform the transformation.
• TransformerFactory transFactory
          TransformerFactory.newInstance()
• Transformer transformer transFactory.newTransfor
  mer()
• Using the DOM tree root node, the following code
  constructs a DOMSource object as the source of
  the transformation.
• DOMSource source new DOMSource(document)

25
DOM Output, contd.

• The following code creates a StreamResult object
  to take the results of the transformation and
  transforms the tree into an XML file.
• File newXML new File("newXML.xml")
• FileOutputStream os new FileOutputStream(newXML)
  
• StreamResult result new StreamResult(os)
• transformer.transform(source, result)

26
JAXB

• JAXB compiles an XML schema into one or more
  classes. The generated classes handle all the
  details of XML parsing and formatting, they
  ensure that the constraints expressed in the
  schema are enforced, and in many cases they are
  much more efficient than using SAX or DOM.

27
JAXB Binding
28
JAXB, contd.

• JAXB generates Java classes from XML schemas.
  JAXB provides methods for unmarshalling an XML
  instance document into a content tree of Java
  objects, and then marshalling the content tree
  back into an XML document.
• JAXB hides the details and gets rid of the extra
  steps in SAX and DOM-- JAXB classes describe only
  the relationships defined in the schemas.

29
JAXB Architecture
30
JAXB Summary

• Generate and compile JAXB classes from a source
  schema, and build an application that implements
  these classes
• Run the application to unmarshal, process,
  validate, and marshal XML content through the
  JAXB binding framework

31
JAXB Steps

• Generate classes. An XML schema is used as input
  to the JAXB binding compiler to generate JAXB
  classes based on that schema.
• Compile classes. All of the generated classes,
  source files, and application code must be
  compiled.
• Unmarshal. XML documents written according to the
  constraints in the source schema are
  unmarshalled.
• Generate content tree. The unmarshalling process
  generates a content tree of data objects
  instantiated from the generated JAXB classes
  this content tree represents the structure and
  content of the source XML documents.
• Validate (optional). Validation of the source
  before generating the content tree.
• Process content. The client application can
  modify the XML data represented by the Java
  content tree by means of interfaces generated by
  the binding compiler.
• Marshal. The processed content tree is marshalled
  out to one or more XML output documents. The
  content may be validated before marshalling.

32
JAXB Details

• javax.xml.bind defines abstract classes and
  interfaces used directly with content classes.
• javax.xml.bind defines the Unmarshaller,
  Validator, and Marshaller classes.
• JAXBContext is the entry point to JAXB. A
  JAXBContext instance manages the binding
  relationship between XML element names to Java
  content interfaces for a JAXB implementation to
  be used by the unmarshal, marshal and validation
  operations.
• javax.xml.bind also defines validation event and
  exception classes.
• javax.xml.bind.util contains utility classes to
  manage marshalling, unmarshalling, and validation
  events.
• javax.xml.bind.helper provides partial default
  implementations for some of the javax.xml.bind
  interfaces. Implementations of JAXB can extend
  these classes and implement the abstract methods.
  These APIs are not intended to be directly used
  by applications using JAXB architecture.

33
JAXB Details

• The JAXBContext class provides an abstraction for
  managing the information necessary for unmarshal,
  marshal and validate.
• JAXBContext jc JAXBContext.newInstance(
  "com.acme.foocom.acme.bar" )
• The contextPath parameter contains a list of
  packages that contain schema-derived interfaces--
  the interfaces generated by the JAXB binding
  compiler. This parameter initializes the
  JAXBContext object to enable management of the
  schema-derived interfaces.
• The JAXB provider implementation must supply an
  implementation class containing a method with the
  following signature
• public static JAXBContext createContext( String
  contextPath, ClassLoader classLoader ) throws
  JAXBException

34
Unmarshalling

• The Unmarshaller class in the javax.xml.bind
  package converts XML data into a tree of Java
  objects. The unmarshal method for a schema allows
  for any global XML element declared in the schema
  to be unmarshalled as the root of an instance
  document.
• The JAXBContext object allows the merging of
  global elements across a set of schemas (listed
  in the contextPath). Since each schema can belong
  to distinct namespaces, the unification of
  schemas to an unmarshalling context should be
  namespace-independent. A client application can
  unmarshal XML documents that are instances of any
  of the schemas listed in the contextPath

35
Unmarshalling, contd.

• JAXBContext jc JAXBContext.newInstance(
    "com.acme.foocom.acme.bar" )
• Unmarshaller u jc.createUnmarshaller()
• FooObject fooObj   (FooObject)u.unmarshal( new
  File( "foo.xml" ) ) // ok
• BarObject barObj   (BarObject)u.unmarshal( new
  File( "bar.xml" ) ) // ok
• BazObject bazObj   (BazObject)u.unmarshal( new
  File( "baz.xml" ) )   // error, "com.acme.baz"
  not in contextPath

36
Marshalling

• The Marshaller class converts a Java content tree
  back into XML data.
• A simple example that unmarshals an XML document
  and then marshals it back out is a follows

37
Marshalling, contd.

• JAXBContext jc JAXBContext.newInstance(
  "com.acme.foo" ) // unmarshal from foo.xml
• Unmarshaller u jc.createUnmarshaller()
• FooObject fooObj   (FooObject)u.unmarshal( new
  File( "foo.xml" ) ) // marshal to System.out
• Marshaller m jc.createMarshaller()
• m.marshal( fooObj, System.out )

38
JAXB Examples

• http//java.sun.com/webservices/docs/1.4/tutorial/
  doc/index.html

39
JAXB Customisation

• Reasons for modifying default bindings
• Create API documentation for the schema-derived
  JAXB classes, etc. add Javadoc annotations.
• Provide meaningful names
• To resolve name collisions.
• To provide names for typesafe enumeration
  constants.
• To provide better names for the Java
  representation of unnamed model groups when they
  are bound to a Java property or class.
• To provide more meaningful package names.
• Overriding default bindings for example
• Specify that a model group should be bound to a
  class rather than a list.
• Specify that a fixed attribute can be bound to a
  Java constant.
• Override the specified default binding of XML
  Schema built-in datatypes to Java datatypes.

40
JAX-RPC

• JAX-RPC builds Web services and clients that use
  remote procedure calls and XML.
• In JAX-RPC, a remote procedure call is
  represented by an XML-based protocol such as
  SOAP.
• Although SOAP messages are complex, the JAX-RPC
  API hides this complexity from the application
  developer.
• On the server side, the developer specifies the
  remote procedures by defining methods in a Java
  interface. The developer also codes one or more
  classes that implement those methods.
• A client creates a proxy, a local object
  representing the service, and then invokes
  methods on the proxy. With JAX-RPC, the developer
  does not generate or parse SOAP messages. It is
  the JAX-RPC runtime system that converts the API
  calls and responses to and from SOAP messages.

41
JAX-RPC

• In JAX-RPC, a remote procedure call is
  represented by an XML-based protocol such as
  SOAP. The SOAP specification defines the envelope
  structure, encoding rules, and conventions for
  representing remote procedure calls and
  responses.
• These calls and responses are transmitted as SOAP
  messages (XML files) over HTTP. JAX-RPC API
  hides SOAP complexityfrom the application
  developer.
• On the server side, the developer specifies the
  remote procedures by defining methods in an
  interface. The developer also codes one or more
  classes that implement the methods.
• A client creates a proxy (a local object
  representing the service) and then simply invokes
  methods on the proxy.
• With JAX-RPC, the developer does not generate or
  parse SOAP messages. JAX-RPC runtime converts
  the API calls and responses to and from SOAP
  messages.

42
JAX-RPC
43
Developing a JAX-RPC Web Service

• The starting point for developing a JAX-RPC Web
  service is the service endpoint interface. A
  service endpoint interface (SEI) is a Java
  interface that declares the methods that a client
  can invoke on the service.
• Use the SEI, the wscompile tool, and two
  configuration files to generate the WSDL
  specification of the Web service and the stubs
  that connect a Web service client to the JAX-RPC
  runtime. Together, wscompile, the deploytool
  utility, and the Application Server provide the
  Application Servers implementation of JAX-RPC.

44
Summary of Steps

• These are the basic steps for creating the Web
  service and client
• 1. Code the SEI and implementation class and
  interface configuration file.
• 2. Compile the SEI and implementation class.
• 3. Use wscompile to generate the files required
  to deploy the service.
• 4. Use deploytool to package the files into a WAR
  file.
• 5. Deploy the WAR file. The tie classes (which
  are used to communicate with clients) are
  generated by the Application Server during
  deployment.
• 6. Code the client class and WSDL configuration
  file.
• 7. Use wscompile to generate and compile the stub
  files.
• 8. Compile the client class.
• 9. Run the client.

45
JAX-RPC Overview
46
JAX-RPC Service Side Use Cases
47
JAX-RPC Service Side

• Service endpoint definition starts with a Java
  service endpoint interface.
• Service developer can map a WSDL document to a
  Java service endpoint interface.
• Once JAX-RPC service endpoint is defined and
  implemented, deployment requires server-side
  JAX-RPC runtime.
• Deployment includes generation of artifacts
  (skeleton or tie class) based on the service
  endpoint interface.
• During deployment, the tool configures one or
  more protocol bindings for this service endpoint.
  
• A binding ties an abstract service endpoint
  definition to a specific protocol and transport.
  An example of a binding is SOAP over HTTP.

48
JAX-RPC Service Side Runtime
49
JAX-RPC Client Side Use Cases
50
JAX-RPC Client Side

• Client uses the WSDL document to import the
  service.
• A WSDL-to-Java mapping tool generates client side
  artifacts (includes stub class, service endpoint
  interface and additional classes) for the service
  and its ports.
• Note that a service client may use dynamic
  invocation interface (DII) or a dynamic proxy
  mechanism instead of a generated stub class to
  invoke a remote method on a service endpoint.

51
JAX-RPC Client Side Runtime
52
Client invokes Service
53
Remote Method Call

• The processing of a remote method call includes
• Map remote method call to the SOAP message
  representation map parameters, return value and
  exceptions (for the remote method call) to the
  corresponding SOAP message serialization and
  deserialization based on the mapping between Java
  types and XML data types.
• Process SOAP message Process SOAP message
  based on the mapping of call to the SOAP
  representation.
• Process HTTP request Transmit SOAP request as
  part of HTTP request. SOAP response is
  transmitted as HTTP response.

54
Service Side Response
55
Create Service (Simplified)

• Service definition interface extends
  java.rmi.Remote and its methods throw a
  java.rmi.RemoteException object.
• package coffees
• import java.rmi.Remote
• import java.rmi.RemoteException
• public interface CoffeeOrderIF extends Remote
• public Coffee getPriceList() throws
  RemoteException   
• public String orderCoffee(String coffeeName, int
  quantity) throws RemoteException
• The method getPriceList returns an array of
  Coffee objects, each of which contains a name and
  a price.

56
Simple Service, contd.

• The method getPriceList will query the company's
  database to get the current information and
  return the result as an array of Coffee objects.
• The second method, orderCoffee, will also need to
  query the database to see if the particular
  coffee specified is available in the quantity
  ordered.
• The implementation will set the internal order
  process in motion and send a reply informing the
  customer that the order will be filled.

57
Simple Service, contd.

• package coffees
• public class CoffeeOrderImpl implements
  CoffeeOrderIF
• public Coffee getPriceList() throws
  RemoteException     . . .      
• public String orderCoffee(String coffeeName, int
  quantity) throws RemoteException     . . .   
  

58
Simple Service, contd.

• The mapping tool uses the interface and
  implementation to generate the stub and tie
  classes and to create the WSDL description for
  the service.
• Packaging a Web service definition is done via a
  Web application archive (WAR). A WAR file is a
  JAR file for Web applications,. For example, the
  CoffeeOrder service could be packaged in the file
  jaxrpc-coffees.war.
• An XML file called a deployment descriptor must
  be with the WAR with information for deploying a
  service definition.
• One of the files referenced in a web.xml file is
  a configuration file that is automatically
  generated by the mapping tool.
• Deploying CoffeeOrder example in a Tomcat
  container can be accomplished by copying the
  jaxrpc-coffees.war file to webapps directory.

59
Coding the Client

• This Web services client creates an instance of
  CoffeeOrderIF and uses it to call the method
  getPriceList. Then it accesses the price and name
  fields of each Coffee object in the array
  returned by the method getPriceList in order to
  print them out.
• The class CoffeeOrderServiceImpl is one of the
  classes generated by the mapping tool. It is a
  stub factory whose only method is
  getCoffeeOrderIF. It creates instances of
  CoffeeOrderIF. The instances of CoffeeOrderIF
  that are created by CoffeeOrderServiceImpl are
  client side stubs that can be used to invoke
  methods defined in the interface CoffeeOrderIF.
• The method getPriceList will block until it has a
  response and returned it.
• Because a WSDL document is being used, the
  JAX-RPC runtime will get the service endpoint
  from it.

60
The Client, contd.

• public class CoffeeClient
• public static void main(String args)
• try
• CoffeeOrderIF coffeeOrder new
• CoffeeOrderServiceImpl().getCoffeeOrderIF
  ()
• Coffee priceList
• coffeeOrder.getPriceList()
• for (int i 0 i lt priceList.length i)
  
• System.out.print(priceListi.getName()
  " ")
• System.out.println(priceListi.getPrice()
  )
• catch (Exception ex)
• ex.printStackTrace()

61
Client talks to Service !!!

• The JAX-RPC runtime determines the endpoint for
  the CoffeeOrder service (which is its URI) from
  its WSDL description. If a WSDL document had not
  been used, you would need to supply the service's
  URI as a command line argument.
• java coffees.CoffeeClient
• The RPC is a static method call. The RPC was
  determined at compile time. It is possible to
  call a remote method dynamically at run time with
  the Dynamic Invocation Interface (DII) or a
  dynamic proxy.

62
JAX-RPC Supported Types

• Primitive types boolean byte double float int
  long short
• java.lang.Boolean java.lang.Byte java.lang.Double
  java.lang.Float java.lang.Integer java.lang.Long
  java.lang.Short java.lang.String
  java.math.BigDecimal java.math.BigInteger
  java.net.URI java.util.Calendar java.util.Date
• java.util.Collection Classes List ArrayList
  LinkedList Stack Vector Map HashMap Hashtable
  Properties TreeMap Set HashSet TreeSet

63
JAX-RPC Value Types

• A value type is a class whose state may be passed
  between a client and remote service as a
  parameter or return value. For example, in an
  application for a university library, a client
  might call a remote procedure with a value type
  parameter named Book, a class that contains the
  fields Title, Author, and Publisher.
• A value type must have a public default
  constructor, not implement the java.rmi.Remote
  interface, and its fields must be supported
  JAX-RPC types.
• The value type may contain public, private, or
  protected fields
• A public field cannot be final or transient.
• A non-public field must have corresponding getter
  and setter methods.

64
JAX-RPC More Detail
65
Creating a Service

• These are the basic steps for creating a service
  
• Code the service endpoint interface and
  implementation class.
• Build, generate, and package the files required
  by the service.
• Deploy the WAR file that contains the service.

66
Coding the Service

• A service endpoint interface declares the methods
  that a remote client may invoke on the service.
  In this example, the interface declares a single
  method named sayHello.
• A service endpoint interface must conform to a
  few rules
• It extends the java.rmi.Remote interface.
• It must not have constant declarations, such as
  public final static.
• The methods must throw the java.rmi.RemoteExceptio
  n or one of its subclasses.
• Method parameters and return types must be
  supported JAX-RPC types.

67
Service Example

• In this example, the service endpoint interface
  is HelloIF.java
• package helloservice
• import java.rmi.Remote
• import java.rmi.RemoteException
• public interface HelloIF extends Remote public
  String sayHello(String s) throws RemoteException
  

68
Service Example, contd.

• package helloservice
• public class HelloImpl implements HelloIF
• public String message "Hello"
• public String sayHello(String s) return
  message s

69
Building the Service

• asant build
• The build task command executes these asant
  subtasks
• compile-service
• generate-wsdl
• The compile-service Task
• This asant task compiles HelloIF.java and
  HelloImpl.java, writing the class files to the
  build subdirectory.

70
Building the Service, contd.

• The generate-wsdl Task
• The generate-wsdl task runs wscompile, which
  creates the WSDL and mapping files. The WSDL file
  describes the Web service and is used to generate
  the client stubs. The mapping file contains
  information that correlates the mapping between
  the Java interfaces and the WSDL definition.
• The files created are MyHelloService.wsdl and
  mapping.xml. The generate-wsdl task runs
  wscompile with the following arguments
• wscompile -define -mapping build/mapping.xml -d
  build -nd build -classpath build
  config-interface.xml

71
Building, contd.

• The -classpath flag instructs wscompile to read
  the SEI in the build directory, and the -define
  flag instructs wscompile to create WSDL and
  mapping files. The -mapping flag specifies the
  mapping file name. The -d and -nd flags tell the
  tool to write class and WSDL files to the build
  subdirectory.
• The wscompile tool reads an interface
  configuration file that specifies information
  about the SEI. In this example, the configuration
  file is named config-interface.xml and contains
  the following
• lt?xml version"1.0" encoding"UTF-8"?gt
  ltconfiguration xmlns"http//java.sun.com/xml/ns/j
  ax-rpc/ri/config"gt ltservice name"MyHelloService"
  targetNamespace"urnFoo" typeNamespace"urnFoo"
  packageName"helloservice"gt ltinterface
  name"helloservice.HelloIF"/gt lt/servicegt
  lt/configurationgt

72
Building, contd.

• This configuration file tells wscompile to create
  a WSDL file named MyHelloService.wsdl with the
  following information
• The service name is MyHelloService.
• The WSDL target and type namespace is urnFoo.
  The choice for what to use for the namespaces is
  up to you. The role of the namespaces is similar
  to the use of Java package names--to distinguish
  names that might otherwise conflict. For example,
  a company can decide that all its Java code
  should be in the package com.wombat.. Similarly,
  it can also decide to use the namespace
  http//wombat.com.
• The SEI is helloservice.HelloIF.
• The packageName attribute instructs wscompile to
  put the service classes into the helloservice
  package.

73
Packaging and Deploying Service

• Package and deploy the service using either
  deploytool or asant.
• Packaging and Deploying the Service with
  deploytool
• Behind the scenes, a JAX-RPC Web service is
  implemented as a servlet. Because a servlet is a
  Web component, you run the New Web Component
  wizard of the deploytool utility to package the
  service. During this process the wizard performs
  the following tasks
• Creates the Web application deployment descriptor
• Creates a WAR file
• Adds the deployment descriptor and service files
  to the WAR file

74
Deploytool

• WAR File dialog box
• Select the button labeled Create New Stand-Alone
  WAR Module.
• In the WAR Location field, click Browse and
  navigate to ltINSTALLgt/j2eetutorial14/examples/jaxr
  pc/helloservice/.
• In the File Name field, enter MyHelloService.
• Click Create Module File.
• Click Edit Contents.
• In the tree under Available Files, locate the
  ltINSTALLgt/j2eetutorial14/examples/jaxrpc/helloserv
  ice/ directory.
• Select the build subdirectory.
• Click Add.
• Click OK.
• Click Next.

75
Deploytool, contd.

• Choose Component Type dialog box
• Select the Web Services Endpoint button.
• Click Next.
• Choose Service dialog box
• In the WSDL File combo box, select
  WEB-INF/wsdl/MyHelloService.wsdl.
• In the Mapping File combo box, select
  build/mapping.xml.
• Click Next.
• Component General Properties dialog box
• In the Service Endpoint Implementation combo box,
  select helloservice.HelloImpl.
• Click Next.
• Web Service Endpoint dialog box
• In the Service Endpoint Interface combo box,
  select helloservice.HelloIF.
• In the Namespace combo box, select urnFoo.
• In the Local Part combo box, select HelloIFPort.
• The deploytool utility will enter a default
  Endpoint Address URI HelloImpl in this dialog.
  This endpoint address must be updated in the next
  section.
• Click Next.
• Click Finish.

76
Deploytool, contd.

• Specifying the Endpoint Address
• To access MyHelloService, the tutorial clients
  will specify this service endpoint address URI
• http//localhost8080/hello-jaxrpc/hello
• The /hello-jaxrpc string is the context root of
  the servlet that implements MyHelloService. The
  /hello string is the servlet alias. To specify
  the endpoint address, you set the context root
  and alias as follows
• In deploytool, select MyHelloService in the tree.
• Select the General tab.
• In the Context Root field, enter /hello-jaxrpc.
• In the tree, select HelloImpl.
• Select the Aliases tab.
• In the Component Aliases table, add /hello.
• In the Endpoint tab, select hello for the
  Endpoint Address in the Sun-specific Settings
  frame.
• Select File Save.

77
Deploytool, contd.

• Deploying the Service
• In deploytool, perform these steps
• In the tree, select MyHelloService.
• Select Tools Deploy.
• You can view the WSDL file of the deployed
  service by requesting the URL http//localhost808
  0/hello-jaxrpc/hello?WSDL in a Web browser. Now
  you are ready to create a client that accesses
  this service.

78
Asant

• Packaging and Deploying the Service with asant
• To package and deploy the helloservice example,
  follow these steps
• In a terminal window, go to ltINSTALLgt/j2eetutorial
  14/examples/jaxrpc/helloservice/.
• Run asant create-war.
• Make sure the Application Server is started.
• Set your admin username and password in
  ltINSTALLgt/j2eetutorial14/examples/common/build.pro
  perties.
• Run asant deploy-war.
• You can view the WSDL file of the deployed
  service by requesting the URL http//localhost808
  0/hello-jaxrpc/hello?WSDL in a Web browser. Now
  you are ready to create a client that accesses
  this service.

79
Undeploying

• Undeploying the Service
• At this point in the tutorial, do not undeploy
  the service. When you are finished with this
  example, you can undeploy the service by typing
  this command
• asant undeploy

80
Coding the Client

• Before invoking the remote methods on the stub
  the client must
• Create a Stub object
• (Stub)(new MyHelloService_Impl().getHelloIFPort())
  
• The code in this method is implementation-specific
  because it relies on a MyHelloService_Impl
  object, which is not defined in the
  specifications. The MyHelloService_Impl class
  will be generated by wscompile in the following
  section.
• Set the endpoint address that the stub uses to
  access the service
• stub._setProperty(javax.xml.rpc.Stub.ENDPOINT_ADD
  RESS_PROPERTY, args0)
• At runtime, the endpoint address is passed to
  HelloClient in args0 as a command-line
  parameter, which ant gets from the
  endpoint.address property in the build.properties
  file.
• Cast stub to the service endpoint interface,
  HelloIF
• HelloIF hello (HelloIF)stub

81
Coding the Client, contd.

• package staticstub
• import javax.xml.rpc.Stub
• public class HelloClient
• private String endpointAddress
• public static void main(String args)
• System.out.println("Endpoint address "
  args0)
• try Stub stub createProxy()
• stub._setProperty
• (javax.xml.rpc.Stub.ENDPOINT_ADDRE
  SS_PROPERTY, args0)
• HelloIF hello (HelloIF)stub
• System.out.println(hello.sayHello("Duk
  e!"))
• catch (Exception ex)
• ex.printStackTrace()
  
• private static Stub createProxy()
• // Note MyHelloService_Impl is
  implementation-specific.
• return (Stub) (new MyHelloService_Impl().
  getHelloIFPort())

82
Building the Client

• asant build
• Steps required in build
• generate-stubs
• compile-client
• package-client
• The generate-stubs task runs the wscompile tool
  as follows
• wscompile -genclient -d build -classpath build
  config-wsdl.xml
• wscompile reads the WSDL file that was installed
  when the service was deployed. The wscompile
  command generates files based on the information
  in the WSDL file and on the command-line flags.
  The -genclient flag instructs wscompile to
  generate the stubs, serializers, and value types.
  
• The compile-client task compiles
  src/HelloClient.java and writes the class file to
  the build subdirectory.
• The package-client task packages the files
  created by the generate-stubs and compile-client
  tasks into the dist/client.jar file.

83
Full JAX-RPC Examples

• http//java.sun.com/j2ee/1.4/docs/tutorial/doc/ind
  ex.html
• JAX-RPC

84
XMS- Security

• XML and Web Services Security (XWS-Security) for
  message-level security. Security information is
  in the SOAP message security information travels
  with the message. For example, a portion of the
  message may be signed by a sender and encrypted
  for a particular receiver. When the message is
  sent from the initial sender, it may pass through
  intermediate nodes before reaching its intended
  receiver. In this scenario, the encrypted
  portions cant be read by any intermediate nodes
  and can only be decrypted by the intended
  receiver. message-level security is also
  sometimes referred to as end-to-end security.
• Features
• Support for securing JAX-RPC applications.
• A framework for a JAX-RPC application developer
  to secure applications by signing/verifying parts
  of SOAP messages and/or encrypting/decrypting
  parts of a SOAP message.
• The message sender can also associate security
  tokens with the message. A token may hold the
  identity of the sender, a user name and password.
  

85
SAAJ Java API for SOAP with Attachments
86
SAAJ Extends DOM

• SAAJ APIs extend their counterparts in
  org.w3c.dom
• The Node interface extends the org.w3c.dom.Node
  interface.
• The SOAPElement interface extends both the Node
  interface and the org.w3c.dom.Element interface.
• The SOAPPart class implements the
  org.w3c.dom.Document interface.
• The Text interface extends the org.w3c.dom.Text
  interface.
• The SOAPPart of a SOAPMessage is a DOM Level 2
  Document, and can be manipulated by applications,
  tools and libraries that use DOM.

87
SOAP Connections

• SOAP messages are sent and received over a
  connection.
• The connection is represented by a SOAPConnection
  object, which goes from the sender directly to
  its destination.
• Messages sent using the SAAJ API are
  request-response messages. They are sent over a
  SOAPConnection object with the method call, which
  sends a message (a request) and then blocks until
  it receives the reply (a response).

88
SOAP SAAJ Details and Examples

• http//java.sun.com/webservices/docs/1.2/tutorial/
  doc/SAAJ.html

89
JAXR

• JAXR enables Java software programmers to use a
  single API to access a variety of XML registries.
  A unified JAXR information model describes
  content and metadata within XML registries.
• Developers can write registry client programs
  that are portable across different target
  registries.
• The JAXR specification includes detailed bindings
  between the JAXR information model and both the
  ebXML Registry and the UDDI version 2
  specifications.

90
JAXR
91
JAXR Architecture

• A JAXR client accesses a business registry via a
  JAXR provider.
• A JAXR provider provides access to a specific
  registry provider or to a class of registry
  providers
• A JAXR provider implements two main packages
• javax.xml.registry, which consists of the API
  interfaces and classes that define the registry
  access interface.
• javax.xml.registry.infomodel , which consists of
  interfaces that define the information model for
  JAXR. These interfaces define the types of
  objects that reside in a registry and how they
  relate to each other. The basic interface in this
  package is the RegistryObject interface. Its
  subinterfaces include Organization, Service, and
  ServiceBinding.

92
JAXR Provider

• Interfaces in the javax.xml.registry package
• Connection. represents a client session with a
  registry provider. The client must create a
  connection with the JAXR provider.
• RegistryService. The client obtains a
  RegistryService object from its connection. The
  RegistryService object in turn enables the client
  to obtain the interfaces it uses to access the
  registry.
• \BusinessQueryManager, allows the client to
  search a registry for information by the
  javax.xml.registry.infomodel interfaces.
• BusinessLifeCycleManager, which allows the client
  to modify the information in a registry by either
  saving it (updating it) or deleting it.

93
JAXR Client

• Establishing a Connection
• Properties props new Properties()
  props.setProperty("javax.xml.registry.queryManager
  URL", "http//uddi.ibm.com/testregistry/inquiryapi
  ") props.setProperty("javax.xml.registry.lifeCycl
  eManagerURL", "https//uddi.ibm.com/testregistry/p
  ublishapi")
• The client then sets the properties for the
  connection factory and creates the connection
• connFactory.setProperties(props) Connection
  connection connFactory.createConnection()

94
JAXR Client

• Querying a Registry
• By name
• By classification

95
Finding Services and ServiceBindings

• Iterator orgIter orgs.iterator()
• while (orgIter.hasNext())
• Organization org (Organization)
  orgIter.next()
• Collection services org.getServices()
• Iterator svcIter services.iterator()
• while (svcIter.hasNext())
• Service svc (Service) svcIter.next()
• Collection serviceBindings
• svc.getServiceBindings()
• Iterator sbIter serviceBindings.iterator
  ()
• while (sbIter.hasNext())
• ServiceBinding sb
• (ServiceBinding) sbIter.next()
  

96
Full JAX-RPC, SAAJ and JAXR Example

• http//java.sun.com/webservices/docs/1.2/tutorial/
  doc/CB.html

97
Full Example, contd.
98
Full Example, contd.

• The Coffee Break server obtains coffee from
  distributors.
• Server uses SAAJ to communicate with one
  distributor. It uses JAXR to send a query
  searching for coffee distributors.
• The Coffee Break server requests price lists from
  each of the coffee distributors. The server makes
  RPCs and waits for response, a JavaBeans
  component representing a price list. The SAAJ
  distributor returns price lists as XML documents.
  
• Server processes the price lists from the
  JavaBeans components.
• Server creates a local database of distributors.
• When an order is placed, suborders are sent to
  one or more distributors.