Building Web Services in Java

© Blue Skyline Ltd1 of 31

Building Web Services in Java

Andy LongshawBlue Skyline

[email protected]


Some important questions• Who am I?• Who are you?

– Developers and technical architects wanting to build Java-based Web Services

• Why are you here?– Creating Java-based Web Services– Mapping between WSDL and Java– Use of SOAP from Java– Deployment and use of a Java-based Web Service

– Demos using IBM WSTK, Apache SOAP and Apache Axis


Web Services in Java motivation• What do we mean by "Web Service"?• Why use Web Services?• Why use Java?


Developer view of Web Services• Extension of component model onto the Web

– Your applications rely on 3rd party "components"– Component functionality is hosted remotely– Solution code calls on functionality as necessary

• Service-oriented view– Locally installed components are more like libraries– Sliding scale of business<->infrastructure services

• Standards are defined/emerging– WSDL/SOAP/UDDI– ebXML


Benefits of Java Web Services• Why use Web Services?

– Language- and platform-neutral framework– Component drivers: faster development– Potential easing of application integration– The vendors are pushing you that way

• Why use Java?– One of the principal developer languages– Lots of activity around Java Web Services– Java-based Web Services are portable– You like Java!


Developing with Web Services• What steps do I need to follow?• What APIs are there?• Creating a Web Service• Deploying a Web Service• Using a Web Service• What tools are there to help me?


Web Service roles• What do I need to do?• Service providers

– Have a good idea for a service!– Implement the service being offered– Describe the service being offered– Publish the description– Wait for customers

• Service users– Discover an interesting service– Retrieve the description– Plug it into your application– Use the service

• Must have a framework for all this to take place under otherwise it is chaos


Where are you starting from?• Steps and tools required depends on your

situation• The functionality already exists

– EJB, servlet or Java class– Need to wrap the existing component as a Web Service

• The functionality is new– Create a new Web Service from scratch…– … or write it as an EJB/servlet/class and wrap it


ArchitectureWeb Service

Client

servlets

CandidateWeb Services

servlet

SOAP Request

SOAPRouter &

Dispatcher

SOAP ResponseEJBs

Invoketarget method

Javaclasses

WebServiceProxy

WebServiceProxy

Javamethods

WSDLWSDL


Describing a Web Service• Create a Web Service Description Language

(WSDL) document• WSDL describes possible operations…

– messages, parameters, return values, complex types• …and how to access them

– binding information, ports, portTypes


Creating a WSDL document• Create the document by hand…• Automatic generation from an existing class

– Example: IBM WSTK WSDL Generator Tool (wsdlgen)• wraps EJBs, classes or COM dispinterfaces• Uses SOAP 2.2 functionality under the covers

• Define your business operations and generate WSDL from them– Completely Java-independent


Creating the Web Service• If WSDL was generated from an existing class,

skip this step• If WSDL is new, need to generate Java "skeleton"

– Example: IBM WSTK Service Implementation Template Generator Tool (servicegen)

• Creates Java interface from WSDL• WSDL message names are mapped to Java

methods• Service class implements interface

– Example: Axis Wsdl2java


Deploying the Web Service• Service must be deployed to endpoint(s) defined

in WSDL• Server-side proxy must

– listen on endpoint– process SOAP message and unmarshal parameters– route messages to correct Java method– capture return value(s) and marshal them back– Example: IBM WSTK servicegen and wsdlgen

• Both create deployment descriptor for target environment, e.g. Apache SOAP

– Example: Apache ServiceManagerClient to deploy


Complex datatypes• Need to marshal between WSDL/SOAP datatypes

and Java types– Mapping of Java types corresponding to XML Schema

data types is simple– Complex and custom types need specific marshaling

• Again, tool generation of Java classes is preferable– Example: IBM WSTK wsdlgen and servicegen

• Generates Java serializer classes for use with target client and server, in this case Apache

– Example: Use of bean serializer in Axis


Creating a Java client proxy• Use a client-side proxy to hide SOAP complexity

– Proxy implements same methods as server• Best option is for tool to generate proxy

– Example: IBM WSTK Service Proxy Generator Tool (proxygen)

• Generates proxy and serializers– Example: Axis Wsdl2java


Using the Java Proxy• Instantiate and call client-side proxy• Relatively little Web Service-specific code needed

– Address and location– Complex type conversion

• Caveats– Network latency– Error handling– Style of calls


Alternative clients• You may have other clients

– Direct SOAP clients in Java– Calls from non-Java clients

• Direct SOAP clients– Read and understand the WSDL :-(

• Clients in other languages– Use the WSDL to generate a proxy (e.g. C#)– This is the whole point of it!


Dynamic lookup• Fully dynamic Web Services model has service

information retrieved from UDDI registry

• Now things get a bit trickier…

• There is no standard Java API to access UDDI– Currently some vendor-specific solutions, e.g. UDDI4J– See JAXR later

• There is no standard Java API to access WSDL– Currently some vendor-specific solutions, e.g. WSDL4J– See JSR110 later


Registering the service• WSDL information in two parts

– Interface definition: reusable general description– Implementation definition: specific endpoints

• tModel represents interface definition– tModel structure points to WSDL document– tModel registered separately from implementation info– tModel has unique key

• Service creator builds UDDI businessService– Contains bindingTemplates which reference tModels– Stored under businessEntity– save_service, save_binding, save_tmodel


Retrieving the service information• Search UDDI registry for information…

– find_business, find_service, find_binding, find_tmodel– Returns relevant XML structure(s)

• … or retrieve specific binding– Obtain bindingTemplate details via get_bindingDetail– Provide unique key to identify entry required

• Parse and use XML returned

• A good case for using vendor-specific APIs!– Or waiting until JAXR appears


IBM WSTK• Version 2.4 features and functionality

– Tools and utilities– Java WSTK API to simplify things a bit– SOAP– UDDI4J– WSDL4J– Binds to servlet container, e.g. Tomcat or WebSphere

• See also IBM's XML and Web Services Development Environment


Apache SOAP• Version 2.2 features and functionality

– Supports SOAP 1.1 and SOAP Messages with attachments

– Java API for invoking SOAP RPC services– Java API for sending and receiving SOAP messages– Expose Java classes as SOAP RPC servers– Create SOAP message servers in Java– Supports HTTP and SMTP transports– Plug it into a servlet container, e.g. Tomcat


Apache Axis• Next generation Apache SOAP

– Alpha 2 release Sept 2001• Improved performance• Improved deployment

– JWS files– Heading to Web Service Deployment Descriptor

(WSDD)• WSDL support

– Wsdl2java tool creates stubs and skeletons– ?wsdl suffix on service URL presents WSDL to caller


Other Tools• Web Service capabilities in IDEs and Tools

– Forte for Java 3.0– Together Control Center 5.5– Visual Age– WebGain– Jbuilder– CapeClear (Studio and Connect)

• Web Service capabilities in App Servers– WebLogic 6.1– WebSphere 4.0– iPlanet– Oracle 9i


The JAX Pack: JAX-RPC• Essentially a Java binding for RPC over SOAP• Feed WSDL description into compiler

– Produces stubs and skeletons– Java mappings for complex types– APIs for invocation, marshaling etc.– Forwards and reverse mappings

• Looks very similar to existing support from IBM WSTK and seems to be tracked by Apache Axis

• JCP JSR101 still in progress (Sept 2001)– Public spec 10th October 2001 (0.5 release)– No EA release as yet


The JAX Pack: JAXM• Document-centric SOAP-based messaging

– Synchronous– Asynchronous

• Profiles for specific messaging systems– ebXML is the notable one– JAXM began life as a mapping for ebXML

• JCP JSR067 close to completion (Sept 2001)– Spec. publicly available

• Early access release available (EA2)– Raw SOAP messaging capability– Sample profile for ebXML


The JAX Pack: JAXR• Generic XML-based registry access

– UDDI– ebXML Registry– Others, including eCo Framework, ISO 11179

• Multiple levels of registry– Business and generic– Specific mappings for UDDI and ebXML Registry

• JCP JSR093 still in progress (Sept 2001)– Spec. publicly available– No EA release


What's next: Java• JAX Pack delivery in J2EE 1.4 (JSR151)• JSR110: WSDL API• JSR109: Programming model for Web Services• JSR156 XML Transactioning API for Java

(JAXTX)• JSR155 Web Services Security Assertions• JSR105: XML Dsig• JSR106: XML Encryption• JSR157: ebXML CPP/A APIs for Java


What's next: Web Services• Current state of standards

– Many still in formative stages– XML Protocol (XMLP) to upgrade SOAP

• Higher-level metadata– Business process integration and business objects– Web Service Flow Language (WSFL)– Automatic code generation

• End-to-end security– XML Digital Signature

• Context propagation


Summary• Web Services extends component model onto the

Internet• Java is a good language for building Web

Services– Lots of activity around the combination– Portable implementations

• We are only just coming out of the "banging rocks together" stage


Further information• Java Community Process

– http://www.jcp.org• Sun

– http://java.sun.com/j2ee/webservices/index.html• IBM

– http://www-106.ibm.com/developerworks/webservices/• Apache XML

– http://xml.apache.org/soap/index.html• Web Services Architect

– http://www.webservicesarchitect.com/• Web Services Portal

– http://www.webservices.org• ebXML home and resources

– http://www.ebxml.org


An alternative approach• OASIS and UN/CEFACT joint venture

– http://www.ebxml.org• Creating the framework

– Initial 18 month project to create standards– Use existing technology where possible


Components identified

TechnicalArchitecture

BusinessProcess

Modelling

CoreComponents

RegistryAnd

Repository

Collaboration

Protocol Messaging


How it works Company A

Company B

ebXMLregistry

Request Business Details1

ImplementSystem

2

Register ImplementationDetails and Co. A profile

3

Do businesstransactions

6

Query forCo. A profile

4

Downloadscenarios

and profiles

5Agree businessarrangement

<XML>

Business scenariosBusiness profiles

Business components


ebXML and Web Services• How does ebXML fit with the world of Web Services?

• UDDI can be used to locate appropriate CPP– Will all CPP info really be stored in global UDDI registry?– If not, need a second tier

• SOAP provides some wire-level compatibility– However, you lose security and reliability extensions defined in

ebXML message

• Other parts largely overlap– WSDL and CPP/CPA– UDDI and Registry & Repository

Building Web Services in Java

Documents

Transcript of Building Web Services in Java