Slide 1: Oct 13 2008 TPG Confidential 1 Technology Practices Group
Java Competency Framework "Incubate, Nurture and Deploy Technology Experts
Innovate, Build and Deliver Technology Solutions”
Document Details : Oct 13 2008 TPG Confidential 2 Document Details
Revision History : Oct 13 2008 TPG Confidential 3 Revision History
Objective : Oct 13 2008 TPG Confidential 4 Objective ** Please read the objective of this content clearly **
This presentation is essentially to set the context of learning on this topic. The content deals with the coverage( both depth and width applicable) for this particular topic in a concise format, providing an overview of the elements that makes up this Topic level.
While this content provides with a high level understanding of the topic to the level of depth that is expected at this particular level( Levels 1.1, 2.1 etc ) , it is highly recommended to have a detailed in depth learning using the resources mentioned in the Additional Resources section.
Table of Contents : Oct 13 2008 TPG Confidential 5 Table of Contents SOA Introduction and Architecture
Web Services Introduction & Architecture
Web Services Type
Introduction to SOAP
Introduction to WSDL
Introduction to UDDI
Introduction to Java WS
References
Summary
SOA Definition : Oct 13 2008 TPG Confidential 6 SOA Definition Service Oriented Architecture (SOA) is a business-centric IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services.
SOA can be defined as a group of services that communicate with each other. The process of communication involves either simple data-passing or two or more services coordinating some activity.
SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused.
SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems.
SOA Definition : Oct 13 2008 TPG Confidential 7 SOA Definition SOA uses the find-bind-execute paradigm. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.
SOA Definition : Oct 13 2008 TPG Confidential 8 SOA Definition SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Applications in SOA are built based on services.
SOA Defined.. : Oct 13 2008 TPG Confidential 9 SOA Defined.. … a service?
A repeatable business task – e.g., check customer credit; open new account … service orientation?
A way of integrating your business as linked servicesand the outcomes that they bring … service oriented architecture (SOA)?
An IT architectural style that supports service orientation … a composite application?
A set of related & integrated services that support a business process built on an SOA
SOA Definition : Oct 13 2008 TPG Confidential 10 SOA Definition Broadly SOA can be classified into two terms: Services and Connections.
What are Services?
Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
Services are self-contained (perform predetermined tasks) and loosely coupled (for independence).
Services can be dynamically discovered
Composite services can be built from aggregates of other services
What are Connections?
Link connecting these self-contained distributed services with each other, it enable client to Services communications. In case of Web services SOAP over HTTP is used to communicate the between services
Slide 11: Oct 13 2008 TPG Confidential 11 Characteristics of Services Services are loosely coupled – making a change to a Service provider does not mandate changing any Service consumers.
Business processes are composed of Services, and are in turn exposed as Services.
Services are policy-driven – business users can change how a Service behaves.
Systems are inherently integrated by virtue of composable Services – not through layers of middleware.
Services leverage legacy systems – SOA does not mandate replacement of runtime infrastructure, but enable migration when needed.
In SOA, metadata control how the system behaves instead of code – business logic trumps application logic.
In SOA, it’s the contracted interface that matters, not the underlying runtime environment.
Slide 12: Oct 13 2008 TPG Confidential 12 Principles of Service Orientation - Architecture First Order Concept: Services are an independent, first order concept
Loosely Coupled:
Abstracted: Services are independent of a specific software implementation
Platform Independent: Services are delivered in a platform independent technology
Designed and built for Agility: Services should incorporate agility into their design, not just use loosely coupled technology.
Articulating: Services should be designed as points of flexibility across functional boundaries and technology layers
Slide 13: Oct 13 2008 TPG Confidential 13 Principles of Service Orientation - Architecture Meaningful: Services should be delivered at a level of granularity and abstraction that is meaningful to the service consumer.
Contract-Based: Services should use a “design by contract” approach to ensure that all participants are aware of their precise obligations when providing or consuming the Service
Standards-Based: Services should comply with appropriate standards for both technology and business domains
Discoverable: Services should be published in a manner by which they can be discovered and consumed without intervention of the provider
Slide 14: Oct 13 2008 TPG Confidential 14 Principles of Service Orientation - Process Federation: The SOA is a collaboration of independent components, that provide services according to contractual obligations
Traceability: Service should be visible throughout life cycle, from business perspective to deployed software service
Alignment of Business and IT: The SOP should ensure clear alignment and mapping between the business service, and the software service
Evolutionary: SOP should be an agile process that facilitates continuous change
Managed: Services should be managed as an asset throughout the service life cycle
Application Neutral: The concept of SOP and SOA is applicable to all classes of interoperability
Architecture : Oct 13 2008 TPG Confidential 15 Architecture Software architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution
Some architecture is always required
Focus shifts to the interfaces as scope increases
How do the parts connect
Role of the architect depends on scope
Am I designing the building?
Only care about my building
External interfaces are a given - can’t change
Or the city plan?
What should the interfaces be?
Need wide agreement
Don’t design every single building
Slide 16: Oct 13 2008 TPG Confidential 16 Service Layer
How do you connect sales to customers? Technology Layer
Hardware, Network
How do you connect J2EE to .NET? Architecture Layers Application Layer
Applications, Components, Software
How do you connect SAP to Siebel? Business Process Layer
Cross Functional End-to-end Sales Order Process
Architecture : Oct 13 2008 TPG Confidential 17 Architecture Service-oriented architectures have the following key characteristics:
SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.
SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.
SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.
Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.
Architecture : Oct 13 2008 TPG Confidential 18 Architecture To implement SOA, enterprises need a service architecture.
Architecture : Oct 13 2008 TPG Confidential 19 Architecture Referring figure in previous slide:
Several service consumers can invoke services by sending messages.
These messages are typically transformed and routed by a service bus to an appropriate service implementation.
This service architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. The service architecture also provides a service management infrastructure that manages services and activities like auditing, billing, and logging.
In addition, the architecture offers enterprises the flexibility of having agile business processes, and changes individual services without affecting other services.
Slide 20: Oct 13 2008 TPG Confidential 20 Principle – Services are a First Order Concept Services are an independent, first order concept
A Service provides a view of a functional capability that is consistent across many use cases. The Service view is common to business requirements, design, deployment, assets and configured resources. A software Service might be related to a functional interface, but should not be taken as a synonym for interface. This applies to both the Business Service and Software Service. This enables:
Improved alignment of business to software Service in comparison to mapping to functional interfaces
A more abstract view to be taken of the service
Complex mappings of software service to functional interface (e.g. many to many)
Service treatment as an asset and resource
Slide 21: Oct 13 2008 TPG Confidential 21 Types of Service
Slide 22: Oct 13 2008 TPG Confidential 22 Types of Service - Example
Slide 23: Oct 13 2008 TPG Confidential 23 Service Management Service Providers
Who is allowed in?
Am I meeting Service Level Agreements?
Who will get the bill?
How do we route requests to different implementations
Service Consumers
Who used the service?
Are Service Level Agreements being met?
Which budget holder will pay?
How do we route requests to different Service Providers
The problem is the same and the solution should be symmetrical
Slide 24: Oct 13 2008 TPG Confidential 24 Service Management
SOA Infrastructure : Oct 13 2008 TPG Confidential 25 SOA Infrastructure To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like following figure:
What are Web Services? : Oct 13 2008 TPG Confidential 26 What are Web Services? 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.
Web services is an effort to build a distributed computing platform for the Web.
Web service applications are encapsulated, loosely coupled Web "components" that can bind dynamically to each other
Slide 27: Oct 13 2008 TPG Confidential 27 What are Web Services?
Web Services Architecture : Oct 13 2008 TPG Confidential 28 Web Services Architecture The Web architecture consists of three components
Service providers - publish available services and offer bindings for services
Service brokers - allow service providers to publish their services (register and categorize). They provide also mechanisms to locate services and their providers
Service requestor - uses the service broker to find a service and then invokes (or binds) the service offered by a service provider.
Web Services Design Principles : Oct 13 2008 TPG Confidential 29 Web Services Design Principles Web-based Protocols
Web-services based on HTTP
protocols can traverse firewalls, can work in a heterogeneous environment
Interoperability - SOAP defines a common standard that allows different systems to interoperate
XML-based (XML schema) - machine-readable documents
Modularity - Service Components are useful in themselves, reusable, composable
Availability
Services are available to systems that wish to use them
Services must be exposed outside of the particular system they are available in
Machine-readable description - used to identify the interface, the location and access information
Implementation-independence - service interface available independent of the ultimate implementation
Published -Searchable service repositories of service descriptions
Slide 30: Oct 13 2008 TPG Confidential 30 Web Services Stack Ubiquitous Communications: Internet Universal Data Format: XML Service Interactions / Messaging: SOAP Formal Service Descriptions: WSDL Publish, Find, Use Services: UDDI A set of standards for implementing web services
Slide 31: Oct 13 2008 TPG Confidential 31 Summary – Web Services SOA is more than Web Services
Service is the important concept, not Web Service
SOA is not just a wiring diagram
Services AND Components are required to fully deliver IT and Business Agility
Component Based Service Engineering (CBSE)
Service Orientation
A set of principles and policies
An approach
Consider Service across the whole lifecycle, not just deployment
Follow the Principles of Service Orientation
Comprehend Agility at all stages
Analysis, Design, Build, Deployment
Slide 32: Oct 13 2008 TPG Confidential 32 Introduction to SOAP SOAP stands for Simple Object Access Protocol
SOAP is a communication protocol
SOAP is for communication between applications
SOAP is a format for sending messages
SOAP is designed to communicate via Internet
SOAP is platform independent
SOAP is language independent
SOAP is based on XML
SOAP is simple and extensible
SOAP allows you to get around firewalls
SOAP will be developed as a W3C standard
Slide 33: Oct 13 2008 TPG Confidential 33 Introduction to SOAP Why SOAP ?
Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this
SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.
Slide 34: Oct 13 2008 TPG Confidential 34 XML Messaging Using SOAP A SOAP client formats a message in XML including a SOAP “envelope” element describing the message
The client sends the message to a SOAP server in the body of an HTTP request
The server determines whether the message is valid and supported
The server formats its response in XML and sends it to the client in the body of an HTTP response
Slide 35: Oct 13 2008 TPG Confidential 35 What is a soap message SOAP Message Anatomy A SOAP message is an ordinary XML document containing the following elements:
A required Envelope element that identifies the XML document as a SOAP message
An optional Header element that contains header information
A required Body element that contains call and response information
An optional Fault element that provides information about errors that occurred while processing the message
All the elements above are declared in the default namespace for the SOAP envelope:
Slide 36: Oct 13 2008 TPG Confidential 36 What is a soap message Message Representation
Slide 37: Oct 13 2008 TPG Confidential 37 Syntax Rules Here are some important syntax rules:
Slide 38: Oct 13 2008 TPG Confidential 38 SOAP Message Components Envelope (required)
Contains Header and Body
Defines namespaces (optional)
Declares encoding rules (optional)
Header (optional)
Contains metadata entries about message a la HTTP headers
Specifies which entries must be understood and by which target "actor" in chain of recipients
Body (required)
Contains application-specific message
May be encoded variously
Fault element (optional)
Contained in Body
Describes error class (version mismatch, headers not understood, client error, server error)
Extensible, hierarchical fault codes
Slide 39: Oct 13 2008 TPG Confidential 39 SOAP Message - Example header body
Slide 40: Oct 13 2008 TPG Confidential 40 SOAP Message Why Not Just Put Everything in the Header?
The Header is optional
SOAP specializations for RPC require using the body to pass parameters and results (we’ll get to that later)
Otherwise, no reason
The SOAP spec notes that a body entry is semantically-equivalent to an optional header entry (with "mustUnderstand" = 0)
Encoding Data in SOAP
SOAP permits arbitrary "encoding styles" and defines a default encoding style
Based on XML-Schema
Supports data types
All built-in XML-Schema types (e.g. string, float, integer, date, IDREF)
Derived types: enumerations, arrays, structs, generic compound types Slide 41: Oct 13 2008 TPG Confidential 41 Encoding Data in SOAP Accessors:
Typed elements are called "accessors"
Accessor types are specified in externally-referenced XML-Schema definitions
Or with the xsi:type attribute, (ex: <a:uid xsi:type="xsd:integer"> 4737 </a:uid> )
Structs:
Structs are simple compound types consisting of uniquely-named accessors, ex:
Slide 42: Oct 13 2008 TPG Confidential 42 Encoding Data in SOAP Arrays:
Arrays can be built of any type, e.g.
Array values can be of any subtype of the array’s declared type
Values can be used in multiple places using references
Including ref’s to external resources
Slide 43: Oct 13 2008 TPG Confidential 43 Using SOAP for RPC Methods are invoked by making a SOAP request to a URI representing the target object
Method calls are represented in the Body by a struct named after the method
Struct members represent in/out parameters to the method
The method result is encoded similarly and returned in a SOAP response
Errors are signaled with the Fault entry
Slide 44: Oct 13 2008 TPG Confidential 44 RPC Example – Digital Library Supports card catalog search and checkout
Target objects / methods
Catalog / search
Circulation / checkout, return
Security
Authentication: patron ID
Fault: unrecognized user
Catalog
Represented by a URI, ex: http://www.lib.com/catalog/
Supports one method: Search
Find items which match a particular query
Result: list of entries containing information about items
Fault condition: malformed query
Slide 45: Oct 13 2008 TPG Confidential 45 RPC Example Catalog Search:
Catalog Search Response:
Slide 46: Oct 13 2008 TPG Confidential 46 Introduction to WSDL What is WSDL?
Web Service Description Language
WSDL is a document written in XML
The document describes a Web service
Specifies the location of the service and the methods the service exposes
Why WSDL ?
Without WSDL, calling syntax must be determined from documentation that must be provided, or from examining wire messages
With WSDL, the generation of proxies for Web services is automated in a truly language- and platform-independent way
Where does this fit in ?
SOAP is the envelope containing the message
WSDL describes the service
UDDI is a listing of web services described by WSDL
Slide 47: Oct 13 2008 TPG Confidential 47 Structure of WSDL document
Slide 48: Oct 13 2008 TPG Confidential 48 Structure of WSDL document Written in XML
Two types of sections - Abstract and Concrete
Abstract sections define SOAP messages in a platform- and language-independent manner
Site-specific matters such as serialization are relegated to the Concrete sections
Abstract sections
Types: Machine- and language-independent type definitions.
Messages: Contains function parameters (inputs are separate from outputs) or document descriptions.
PortTypes: Refers to message definitions in Messages section that describe function signatures (operation name, input parameters, output parameters).
Concrete Descriptions
Bindings: Specifies binding (s) of each operation in the PortTypes section.
Services: Specifies port address (es) of each binding.
Operations
An operation is similar to a function in a high level programming language
A message exchange is also referred to as an operation
Operations are the focal point of interacting with the service
Slide 49: Oct 13 2008 TPG Confidential 49 Example – Document Structure
Example – Document Structure : Oct 13 2008 TPG Confidential 50 Example – Document Structure This is an overview of the syntactical representation of a service in WSDL. For each of the main parts (data, messages, portTypes, Service) a separate top element is used (outer boxes). Within this sub elements represent collections of specifications, such as the set of operations belonging to a portType. These are indicated by the inner boxes.
Slide 51: Oct 13 2008 TPG Confidential 51 Introduction to UDDI UDDI - Universal Description Discovery and Integration
Standard for describing, publishing and finding web services
Still evolving
Use XML-based description files for services
Access to UDDI Registry
Standard UDDI API (accessible via SOAP)
Web browser
Data Structures (XML)
Business entity: general information + business services
Business services: business level description + binding templates
Binding templates: access point + tModel (service types)
tModel: abstract definition of a web service
Slide 52: Oct 13 2008 TPG Confidential 52 UDDI and Web Services The UDDI protocol is another XML-based building block of the Web services stack along with SOAP (standard for invoking remote operations) and WSDL (standard for specifying what these operations look like)
UDDI supplies an infrastructure for systematically addressing needs such as discovery, manageability and security of Web services beyond what is the simple organization of their interactions
By addressing integration, coordination and flexibility issues of service-oriented systems, UDDI plays an important role within the service-oriented approach to enterprise software design
Slide 53: Oct 13 2008 TPG Confidential 53 Accessing Web Services with UDDI In some cases it may be that the information that are necessary to access Web services are known and thus directly stored within the applications that use them
Nonetheless it is possible that the definitions and descriptions of such services (WSDL) are published to be discovered on ad hoc on-line registries
UDDI defines how these registry should be designed and how to use them to describe, publish and discover services on a network
Rather than forcing applications to include information about an external service's application programming interfaces, UDDI registry provide this binding information dynamically, at run-time
UDDI guarantees flexibility with respect both to the dynamic run-time changes that occur during the life-cycle of web services and to the evolution of web application requirements
Slide 54: Oct 13 2008 TPG Confidential 54 UDDI’s Role in WS Software Development By adopting UDDI, it turns out that convenience for developers, requirements of enterprise architects, and underlying business policies are not in opposition
UDDI facilitates Web services software development by providing systematic, interoperable, standards-based:
Management of the development process of web services
Approach for documenting and publishing web services
Organizations and managing of web services across multiple systems and development teams
Documenting interface specification through teams and through time and for external applications above all in case of change
UDDI help drive better code reuse and developer productivity (can help developers - across groups - find a shared service and use that service within their own applications)
Slide 55: Oct 13 2008 TPG Confidential 55 UDDI’s Role in SO Infrastructure UDDI facilitates Service-Oriented Infrastructure:
Insulates critical applications from changes or failures in backend services:
Provides a formal layer of indirection (almost a firewall) necessary for service-oriented application development and management, useful for accommodating changes in the life cycle of specific components (updates, policy considerations, service termination)
Helps an organization share information about services in a controlled way that reflects its own business rules and policies:
Client authentication and publish/subscribe for peer registries satisfy operational governance needs as control of the publication and distribution of information about deployed services according to business policies
Solutions are not hard-coded but takes advantage of run-time binding
Slide 56: Oct 13 2008 TPG Confidential 56 UDDI from the Businesses’ Point of View (1/2) The UDDI Project enables businesses to:
Discover each other
Define how they interact over the internet and share information in a global registry architecture
Enact policy-based distribution and management of enterprise web services
The UDDI project is not industry specific
Any industry, of any size, worldwide, offering products and services can benefit from this open initiative because the specifications comprehensively addresses problems that limit the growth and synergies of B2B commerce and Web services.
Before the UDDI project, there was no industry-wide approach for business to reach their customers and partners with information about their products and Web services, nor there was a method of how to integrate into each other's systems and processes.
UDDI is the building block that enables businesses to quickly, easily and dynamically find and transact with one another via their preferred applications.
Slide 57: Oct 13 2008 TPG Confidential 57 UDDI from the Businesses’ Point of View (2/2) Problems solved:
Makes it possible for organizations to quickly discover the right business from millions currently on line
Defines how to enable commerce to be conducted once the preferred business is discovered
Immediate benefits for businesses:
Reaching new customers
Expanding offerings
Extending market reach
Increasing access to current customers
Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy
Describing their services and business processes programmatically in a single, open and secure environment
Using a set of protocols that enables businesses to invoke services over the internet to provide additional value to their preferred customers
Slide 58: Oct 13 2008 TPG Confidential 58 UDDI Features UDDI is similar to the concepts of DNS and yellow pages
In short, UDDI provides an approach to:
Locate a service
Invoke a service
Manage metadata about a service
UDDI specifies:
Protocols for accessing a registry for Web services
Methods for controlling access to the registry
Mechanism for distributing or delegating records to other registries
Slide 59: Oct 13 2008 TPG Confidential 59 UDDI Specifications UDDI defines:
SOAP APIs that applications use to query and to publish information to a UDDI registry
XML Schema schemata of the registry data model and the SOAP messages format
WSDL definitions of the SOAP APIs
UDDI registry definitions (technical model - tModels) of various identifier and category systems that may be used to identify and categorize UDDI registrations
The UDDI Specifications Technical Committee also develops Technical Notes and Best Practice documents that aid users in deploying and using UDDI registries effectively
Slide 60: Oct 13 2008 TPG Confidential 60 UDDI Registry Service The UDDI specifications define a registry service for Web services and for other electronic and non-electronic services
A UDDI registry service is a Web service that support the description and discovery of service providers, service implementations, and service metadata
UDDI is a meta service for locating web services by enabling robust queries against rich metadata.
Service providers can use UDDI to advertise the services they offer
Service consumer can use UDDI to discover services that suites their requirements and to obtain the service metadata needed to consume those services.
Slide 61: Oct 13 2008 TPG Confidential 61 UDDI Registry Functional purpose: representation of data and metadata about Web services
Either for use on a public network or within on organizational internal infrastructure
Offers standards-based mechanism to classify, catalog and manage Web services so that they can be discovered and consumed by other applications
Implements generalized strategy of indirection amongst services based applications
Offers benefits to IT managers both at design and run-time, including code reuse and improving infrastructure management
Slide 62: Oct 13 2008 TPG Confidential 62 UDDI Registry Types UDDI allows operational registries to be maintained for different purposes in different contexts
A business may deploy one or more:
Private registries:
Isolated from the public network, firewalled
Restricted access
No shared data
Public registries:
Unrestricted open and public access
Data is shared with other registries
Affiliated registries
Controlled environment
Access limited to authorized clients
Data shared in a controlled manner
Private registry supports intranet applications, while a public registry support extranet applications
Affiliated registries supports all other infrastructural topologies e.g., involving delegation, distribution, replication, subscription, that reflects the realities and the relationship of the underlying business processes
Slide 63: Oct 13 2008 TPG Confidential 63 UDDI Servers UDDI specifies hierarchical relationship between a single instance of a UDDI implementation and others to which it is related
UDDI Servers can be:
Nodes: supports a minimum set of functionalities of the specification (they are member of exactly one registry)
Registry: composed of one or more nodes; supports the complete set of functionalities of the specification
Affiliated registry: registry that implements a policy-based sharing of information together with other affiliated registry
Registry Affiliation is the main achievement of UDDI V3.0
Recognition that UDDI is to support the design and operations of myriads software applications within and among business organizations (not only private/public registries)
Slide 64: Oct 13 2008 TPG Confidential 64 UDDI API Features that supports core data management:
Publishing information about a service to a registry
Searching a UDDI registry for information about a service
Features that supports registry interaction:
Replicating and transferring custody of data about a service
Registration key generation and management
Registration subscription API set
Security and authorization
These are divided in Node API Sets (for UDDI Servers) and Client API Sets (for UDDI Clients)
Slide 65: Oct 13 2008 TPG Confidential 65 UDDI Solutions Several categories of product and components
UDDI Registry Server, UDDI-enabled IDEs and development tools, Java and .NET client toolkits and browsers, UDDI-integrated Web services platforms
Supplied by multiple vendors, consortia and also available as open source
Apache.org, BEA, IBM, Microsoft, Oracle, SAP, Sun, Systinet, UDDI4J.org
jUDDI is an open source Java based implementation of a UDDI v2 registry and a toolkit
UDDI4J is a Java class library that provides an API to interact with a UDDI registry
Java Web Service Developer Pack by Sun
Web Application Server by SAP
Webshpere UDDI Registry by IBM
Slide 66: Oct 13 2008 TPG Confidential 66 Introduction to Java Web Services Part of Java EE.
New in Java SE 6.
API stack for web services.
Replaces JAX-RPC.
New API’s:
JAX-WS, SAAJ, Web Service metadata
New packages:
javax.xml.ws, javax.xml.soap,javax.jws
Slide 67: Oct 13 2008 TPG Confidential 67 What is JAX-WS ? JAX-WS stands for Java API for XML Web Services.
JAX-WS is a technology for building web services and clients that communicate using XML.
JAX-WS allows developers to write message-oriented as well as RPC-oriented web services.
In JAX-WS, 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.
Slide 68: Oct 13 2008 TPG Confidential 68 Web Services Platform Architecture (WSPA) WSPA Identifies three components of JWS
Invocation
Proxies Represent Web Services in Java
Interface to Messaging System (HTTP)
QoS (Handlers)
Marshalling (Impedance Matcher)
Java/XML Binding
Deployment
Implement Web Service Endpoints (SOAP, REST) with Java
Slide 69: Oct 13 2008 TPG Confidential 69 Invocation
Slide 70: Oct 13 2008 TPG Confidential 70 Java Proxies Represent Web Services
Slide 71: Oct 13 2008 TPG Confidential 71 Deployment
Slide 72: Oct 13 2008 TPG Confidential 72 How to implement JAX-WS The starting point for developing a JAX-WS web service is a Java class annotated with the javax.jws.WebService annotation.
The Web Service annotation defines the class as a web service endpoint.
A service endpoint interface (SEI) is a Java interface that declares the methods that a client can invoke on the service.
An SEI is not required when building a JAX-WS endpoint. The web service implementation class implicitly defines a SEI.
Slide 73: Oct 13 2008 TPG Confidential 73 Steps in creating the web service and client These are the basic steps for creating the web service and client:
Code the implementation class.
Compile the implementation class.
Deploy the WAR file. The tie classes (which are used to communicate with clients) are generated by the Application Server during deployment.
Code the client class.
Use wsimport to generate and compile the stub files.
Compile the client class.
Run the client.
Slide 74: Oct 13 2008 TPG Confidential 74 Requirements of a JAX-WS Endpoint JAX-WS endpoints must follow these requirements:
The implementing class must be annotated with either the javax.jws.WebService or javax.jws.WebServiceProvider annotation.
The implementing class may explicitly reference an SEI through the endpointInterface element of the @WebService annotation, but is not required to do so. If no endpointInterface is not specified in @WebService, an SEI is implicitly defined for the implementing class.
The business methods of the implementing class must be public, and must not be declared static or final.
Business methods that are exposed to web service clients must be annotated with javax.jws.WebMethod.
Business methods that are exposed to web service clients must have JAX-B-compatible parameters and return types. See Default Data Type Bindings.
Slide 75: Oct 13 2008 TPG Confidential 75 Requirements of a JAX-WS Endpoint The implementing class must not be declared final and must not be abstract.
The implementing class must have a default public constructor.
The implementing class must not define the finalize method.
The implementing class may use the javax.annotation.PostConstruct or javax.annotation.PreDestroy annotations on its methods for lifecycle event callbacks.
The @PostConstruct method is called by the container before the implementing class begins responding to web service clients.
The @PreDestroy method is called by the container before the endpoint is removed from operation.
Slide 76: Oct 13 2008 TPG Confidential 76 Writing a Service Endpoint Implementation Class package helloservice.endpoint;
import javax.jws.WebService;
@WebService ()
public class Hello {
private String message = new String ("Hello, ");
public void Hello() {}
@WebMethod()
public String sayHello (String name) {
return message + name + "."; In this example, the implementation class, Hello, is annotated as a web service endpoint using the @WebService annotation. Hello declares a single method named sayHello, annotated with the @WebMethod annotation. @WebMethod exposes the annotated method to web service clients. sayHello returns a greeting to the client, using the name passed to sayHello to compose the greeting. The implementation class also must define a default, public, no-argument constructor
Additional Resources : Oct 13 2008 TPG Confidential 77 Additional Resources