Table of Contents SOA and Web Services with Java / JAX-WS

Transcription

1 Table of Contents SOA and Web Services with Java / JAX-WS SOA and Web Services with Java/JAX-WS 1 Workshop Overview 2 Workshop Objectives 3 Workshop Agenda 4 Typographic Conventions 5 Release Level 6 Labs 7 Session 1: Service Oriented Architecture (SOA) and Web Services 8 Lesson Objectives 9 SOA Overview 10 The Challenge of Enterprise Systems 11 The Challenge of Legacy Systems 12 Service Oriented Architecture (SOA) 13 The Evolution of Computing 14 SOA Concepts 15 Some Advantages of SOA 16 Some Issues with SOA 17 Web Services Overview 18 Web Services Defined 19 Value Proposition 20 Web Services Defined 21 WS-* Web Services Specifications 22 The Web Services Stack 23 Web Services Stacks 24 Architectural Perspective 25 Architectural Details 26 SOAP and WSDL Concepts 27 SOAP Concepts 28 Anatomy of a SOAP Message 29 A Typical SOAP Scenario 30 WSDL Concepts 31 Lab 1.1 Setting Up the Environment 32 Session 2: Introduction to Java Web Services 47 Session Objectives 48 Overview 49 Java Web Services (JWS) Standards 50 Java Web Services Standards 51 Java First Web Services 52 Java Web Services Platform 53 SOA Architecture with Java Web Services 54 A Simple Web Service 55 Defining a Simple Web Service 56 Annotating the Implementation Class 57 A Brief Note About Annotations 58 Declaring the Web Service in web.xml 59 Copyright LearningPatterns Inc. All rights reserved i

2 Deploying the Web Application 60 Deploying the Web Application 61 Recap 62 Lab 2.1 Creating a Simple Web Service 63 Session 3: WSDL 74 Lesson Objectives 75 Introduction to WSDL 76 Overview of WSDL 77 WSDL Elements 78 WSDL Bindings 79 WSDL in Practice 80 XML Namespaces and XML Schema 81 WSDL Documents are XML Documents 82 XML Namespaces 83 Namespaces Described 84 Namespace Terminology 85 Default Namespaces 86 Namespaces in a WSDL Document 87 XML Schema 89 Simple Schema / XML Document Examples 90 xsd:complextype 91 xsd:complextype Example 92 complextype in WSDL 93 xsd:complextype in WSDL 94 WSDL Structure and Elements 95 WSDL Anatomy 96 WSDL Anatomy 97 <definitions> Element 98 <documentation> Element 99 <types> Element 100 The Generated types 101 <message> Element 102 <porttype> and <operation> 103 <binding> Element 104 <port> and <service> Elements 105 Operation Types 106 Recap 107 Lab 3.1 Review WSDL 108 Session 4: SOAP 110 Lesson Objectives 111 SOAP in a Nutshell 112 What is SOAP 113 SOAP 1.1 vs. SOAP What is a SOAP Message 115 SOAP Message Structure 116 A SOAP Message 117 SOAP Detailed Structure 118 SOAPMessage 120 SOAP Faults 121 SOAP Messaging and HTTP Binding 122 SOAP Messaging 123 Copyright LearningPatterns Inc. All rights reserved ii

3 SOAP Intermediaries 124 SOAP Message Exchange Patterns 125 SOAP Binding 126 SOAP HTTP Binding 127 HTTP Request/Response Details 128 Request and Response Example 129 SOAP Message Example 130 SOAP Styles and Encoding 132 SOAP Styles 133 Literal Encoding 134 SOAP Encoding 135 Lab 4.1 Examining SOAP Messaging 136 Session 5: The Java Web Service Specifications 142 Lesson Objectives 143 JSR-181: WS-Metadata 144 JSR-181 Defines the Web Service Details 146 Affecting the Generated WSDL 147 Other Important JSR-181 Annotations 148 The Service Endpoint Interface (SEI) 149 An SEI and an Associated SIB Details 151 Lab 5.1 Defining a Service With an SEI Details Details 164 WRAPPED vs BARE 166 JAX-WS Capabilities 167 JAX-WS 168 WSDL / Java Mapping 169 WSDL / Java Mapping 170 XML Messaging Support 171 Handler Framework 172 SOAP and HTTP Binding 173 JAX-WS Client Side Programming 174 Creating JAX-WS Clients 175 Client Side Programming Model 176 Generated Classes for Service and Port 177 Details of the Generated JavaInstructor 178 Details of the JavaInstructorService Class 179 Writing a JAX-WS Client 180 Dynamic Proxies 181 The QName and Service Types 182 Lab 5.2 A JAX-WS Client 183 SAAJ 193 SAAJ Overview 194 SAAJ Message Structure 195 SOAPMessage 196 SOAPPart and AttachmentPart 197 SAAJ Classes (In Brief) - In javax.xml.soap 198 Creating SOAP Messages with SAAJ 201 Sending a Message With SAAJ 203 Copyright LearningPatterns Inc. All rights reserved iii

4 SOAP Attachments 204 Examples of SOAP Attachments 205 DOM 206 SAAJ and DOM 207 DOM Overview 208 JavaTunes Order XML Document 209 JavaTunes Order as a DOM Tree 211 The DOM Tree 212 The DOM Interfaces 213 The Node Interface 214 Navigating the DOM Tree 215 The Document and Other Interfaces 216 Extracting Content with SAAJ/DOM 217 Lab 5.3 Using SAAJ 218 SOAP Handlers 225 SOAP Handlers 226 Handler Processing 227 Logical and Protocol Handlers 228 A Sample Handler 229 The SOAPHandler interface 230 MessageContext 231 SOAPMessageContext 232 A Sample SOAP Protocol Handler 233 Handler Invocation 234 MessageContext Properties 235 Configuring Handler Chains 236 Returning a Fault 237 Logical Handlers 238 Lab 5.4 Creating a Handler 239 JAXB 245 JAXB Overview 246 JAXB Architecture 247 Java Web Services and JAXB 248 JAXB and WSDL Mapping 249 The JAXB Annotations 250 Using JAXB with Java Web Services 251 Using JAXB 252 Starting From WSDL or WSDL & Java 253 Starting From WSDL 254 JAX-WS Binding Customizations 255 JAX-WS Binding Customizations Example 256 Other JAX-WS Binding Customizations 257 JAXB Binding Customizations 258 JAXB Binding Example 259 Starting from WSDL and Java 260 Lab 5.5 Starting From WSDL 262 Session 6: XML Based Web Services 271 Lesson Objectives 272 XML Services - JAX-WS Providers 273 XML Messaging 274 JAX-WS Providers 275 A SOAP Provider 276 Copyright LearningPatterns Inc. All rights reserved iv

5 How Providers Work 277 A SOAP Provider - invoke() Example 278 Example - Source Provider using Payload 279 Source Provider - invoke() Example 280 Working with the Request 281 WebServiceContext 282 MessageContext 283 XML Clients - The Dispatch Interface 285 XML Clients 286 Service and Dispatch 287 Dispatch<SOAPMessage> Example 288 Dispatch<Source> Example 289 Lab 6.1 XML Messaging 290 XML/HTTP Messaging 297 XML/HTTP Based Messaging 298 Example XML/HTTP Messaging 299 A Provider Implementation 300 WSDL for the HTTP Binding 301 A Very Simple XML/HTTP Request 302 Provider Based Endpoints 304 REST Overview 305 Overview of REST 306 REST Details 307 Example of REST 308 REST Characteristics 309 Comparison of REST and SOAP 310 JAX-WS and REST 311 JAX-RS 312 Session 7: Security 313 Lesson Objectives 314 Java EE Security and Web Services 315 Web Service Security Requirements 316 Security in Java EE 317 Transport Level Security with HTTPS/SSL 318 Java EE Security Overview 319 Java EE Security 320 Java EE Declarative Security 321 Example: Security Role Declaration 322 Specifying Security Constraints 323 Security Constraints - Deployment Descriptor 324 Mapping Users to Roles 325 HTTP Basic Authentication 326 JAX-WS Clients and Basic Authentication 327 Lab 7.1 Using Basic Authentication 328 HTTPS 333 HTTPS / SSL - Transport Level Security 334 HTTPS / SSL Meets Some Security Needs 335 SSL Pros / Cons 336 SSL Requires Server Setup 337 Requiring HTTPS on a POJO Web Service 338 Invoking a Web Service with HTTPS 339 [Optional] Lab 7.2 Using HTTPS 340 Copyright LearningPatterns Inc. All rights reserved v

6 WS-Security (WSS) 352 Message Level Security 353 XML Signature 354 XML Signature Structure 355 XML Signature Mechanisms 356 XML Signature Sample 357 XML Encryption 359 XML Encryption Structure 360 XML Encryption Mechanisms 361 XML Encryption Example 362 Web Services Security Overview 363 Web Services Security Stack 365 Using the Security Mechanisms 366 Session 8: EJB Based Web Services 367 Lesson Objectives 368 EJB Overview 369 What is EJB 370 EJB Goals 371 Types of Enterprise JavaBeans 372 EJB Transaction Support 373 EJB 3.0 Overview 374 Session Bean Capabilities 375 Benefits of using EJB 376 SOA Architecture with EJB 377 Issues with EJB 378 Programming EJB 379 What are Session Beans 380 Stateless Session Beans (SLSB) 381 Defining a Session Bean 382 Stateless Session Bean Definition 383 Remote Business Interface 384 EJB Packaging - ejb-jar File 385 The EJB Container 386 Server Deployment 387 Creating EJB Based Web Services 388 EJB Based Web Services 389 Why Use EJB for Web Services 390 Specifying the Context and Service URLs 391 Security in EJB Based Web Services 392 Example - Security in EJB Web Services 393 [Optional] Lab 8.1 Defining a Service With an EJB 394 Session 9: WS-* Overview 400 The WS-* Specifications 401 WS-I Interoperability 402 WS-I Profiles 403 WS-I Basic Profile 404 WS-Addressing 405 Recap 406 Recap of What We've Done 407 What Else is There 408 Resources 409 Copyright LearningPatterns Inc. All rights reserved vi

7 SOA and Web Services with Java/JAX-WS The Java Developer Education Series Copyright LearningPatterns Inc. All rights reserved. 1

8 Preface Workshop Overview This is an in-depth hands on course covering the use of Web Services and JAX-WS to implement Service Oriented Architectures (SOA) It covers all the core concepts of Web services, and includes hands-on labs using JAX-WS that implement Web services The course, at a high level, covers the following areas: Service Oriented Architecture (SOA) / Web Service Overview Using Java Specifications to Build Web Services SOAP and WSDL (Web Services Description Language) Data Binding with JAXB (Java Architecture for XML Binding) SAAJ (SOAP with Attachments API for Java) Web Services Security Copyright LearningPatterns Inc. All rights reserved. 2

9 Preface Workshop Objectives At completion you should: Understand the principles of Service Oriented Architecture (SOA) Understand how Web Services can be used to build SOA based systems Understand the core Web Service technologies, including SOAP and WSDL Use Java specifications, including JAX-WS, JSR-181, JAXB, and JSR-109/921 to implement Web Services Copyright LearningPatterns Inc. All rights reserved. 3

10 Preface Workshop Agenda Session 1: Introduction to Service Oriented Architecture (SOA) and Web Services Session 2: Introduction to Java Web Services Session 3: WSDL Session 4: SOAP Session 5: The Java Web Service Specifications Session 6: XML Based Web Services Session 7: Security Session 8: EJB Based Web Services Session 9: WS-* Overview Copyright LearningPatterns Inc. All rights reserved. 4

11 Preface Typographic Conventions Code that is inline in the text will appear in a fixed-width code font, such at this: JavaTeacher teacher = new JavaTeacher() Any class names, such as JavaTeacher, method names, or other code fragments will also appear in the same font If we want to emphasize a particular piece of code, we'll also bold it (and in the slide, change it's color) such as BeanFactory Filenames will be in italics, such as JavaInstructor.java We sometimes denote more info in the notes with a star * Lastly, longer code examples will appear in a separate code box as shown below package com.javatunes.teach; public class JavaInstructor implements Teacher { public void teach() { System.out.println("Web Services are way cool"); } } Copyright LearningPatterns Inc. All rights reserved. 5

12 Preface Release Level Lab This course contains instructions for running the labs using the following platforms: Java 5 or Java 6 JBoss 5.x Eclipse Java EE Edition (Should work with all recent versions Ganymede/3.4, Galileo/3.5, and Helio/3.6 should all be fine) All labs have been tested on JBoss 5.0.1GA and JBoss GA Running under Windows XP Java is a registered trademarks of Oracle Corporation and/or its affiliates No association with or endorsement by Oracle Corporation is implied by the use of these terms in this document. JBoss is a registered trademarks of Red Hat, Inc in the U.S. and other countries. LearningPatterns is not in any way associated with Red Hat or its JBoss Division. Windows XP is a registered trademark of Microsoft Corporation in the United States and other countries Copyright LearningPatterns Inc. All rights reserved. 6

13 Preface Labs Lab The workshop consists of approximately 50% discussion, 50% hands-on lab exercises, including a series of brief labs Many of the labs follow a common fictional case study - JavaTunes, an online music store The labs are contained directly in the course book, and have detailed instructions on what needs to be done The course includes setup zip files that contain skeleton code for the labs Students just need to add code for the particular capabilities that they are working with There is also a solution zip file that contains completed lab code Lab slides contain an icon like the one in the upper right corner of this slide The end of each lab is clearly marked with a stop like this one to the right STOP Copyright LearningPatterns Inc. All rights reserved. 7

14 Session 1: SOA and Web Services Session 1: Service Oriented Architecture (SOA) and Web Services SOA Overview Web Services Overview SOAP and WSDL Concepts Copyright LearningPatterns Inc. All rights reserved. 8

15 Session 1: SOA and Web Services Lesson Objectives Understand what SOA is, and the role it plays in architecting enterprise systems Understand the benefits and issues with SOA Understand the role Web Services play in implementing SOA solutions Become familiar with SOAP and WSDL - two key Web Service technologies Copyright LearningPatterns Inc. All rights reserved. 9

16 Session 1: SOA and Web Services SOA Overview SOA Overview Web Services Overview SOAP and WSDL Concepts Copyright LearningPatterns Inc. All rights reserved. 10

17 Session 1: SOA and Web Services The Challenge of Enterprise Systems Enterprise systems are large and complex Support a great deal of functionality May be written using multiple platforms and technologies, including so called "legacy" platforms like COBOL May involve many different divisions in an enterprise Traditional (monolithic) approaches to building enterprise systems have a number of shortcomings Components are closely coupled to each other, making them difficult to maintain and modify It is difficult to share functionality across organizational units within an enterprise It is difficult for different systems to work with each other Large systems become increasingly hard to maintain as they grow There really is no formal definition of an enterprise application Typically though, some of the characteristics they have are: Used in a business environment, often in business-critical domains Have some form of persistent storage Have some form of remote access (Web/HTTP, Web service, Distributed Objects, etc) Require some measure of scalability and fault tolerance The definition of enterprise application is not important Many Java applications share some of the requirements that we are outlining here Copyright LearningPatterns Inc. All rights reserved. 11

18 Session 1: SOA and Web Services The Challenge of Legacy Systems It is estimated that over 5 billion lines of COBOL code are added annually 1 on a base of over 200 billion lines of code 2 These systems contain an enormous amount of business logic They generally work well, and have been refined and tuned over many years However, they are often difficult to maintain, and very difficult to expand to serve new business requirements Using existing legacy functionality to serve new business requirements is challenging You can modify/expand the legacy system, but this option is limited because of the rigidity/size of the system You can rewrite the legacy systems, but this is very resource intensive, with no guarantees that the new systems will work as well as or contain all the functionality of the legacy system Other approaches are needed 1 From the Dustbin, COBOL Rises, Stephanie Wilkinson, eweek, May 28, Micro Focus Moves Mainframe Apps to.net, Daryl K. Taft, eweek, November 4, Total replacement of legacy systems presents significant risks The new system may not be as good as the old system There is a deep knowledge of the business process embodied in the old system which may not be readily apparent or available to the builders of the replacement system Leveraging the existing legacy systems, if possible, if often a better solution than replacing them Copyright LearningPatterns Inc. All rights reserved. 12

19 Session 1: SOA and Web Services Service Oriented Architecture (SOA) SOA is an architectural approach to building systems that addresses the needs of both building complex systems, and integrating legacy systems to serve new requirements SOA decomposes system functionality into relatively small distinct units called services The services represent a small business process, or segment of a business process Services can be distributed over a network, and made available for general use Several services may be reused and combined to create a larger business process Services communicate over the network, and may pass data to each other and/or coordinate with each other to complete a task Driven by the rise of the internet, SOA is becoming increasingly important When we say that services are "relatively small" we mean that they are smaller than traditional monolithic applications For instance, they are still likely to be quite a bit larger (e.g. 100 times larger) than a typical class in an OO system The internet revolution has accelerated the pace of change in business requirements It has also made networking more pervasive Networked systems are the norm now, rather than being a specialized capability Taken together, these have both enabled SOA architectures, and increased the need for providing flexible building blocks for filling new business requirements Copyright LearningPatterns Inc. All rights reserved. 13

20 Session 1: SOA and Web Services The Evolution of Computing Client/Server Computing Centralized Mainframes SOA Server-centric Web Simple SOA Definition: Using (relatively small) interacting business services to fulfill a larger business requirement The network has become more and more important to computing As Sun says "The network is the computer" This is becoming more true over time, and SOA is an architecture that takes advantage of that fact The goal of SOA is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not be granular enough to be easily reused. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA is that the marginal cost of creating the n-th application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application. [Wikipedia on Service-oriented_architecture] The SOA chunks are loosely coupled, and not directly dependent on each other, except via the service interfaces (or service contracts) that the services expose Copyright LearningPatterns Inc. All rights reserved. 14

21 Session 1: SOA and Web Services SOA Concepts SOA creates loosely coupled and interoperable services Loosely coupled services interact only through (relatively) stable interfaces or contracts They do not need to be concerned with any internals or platform dependencies of a service Services should be interoperable across different implementations and platforms to enable the widest use Finer-grained services may be combined or orchestrated into coarser-grained services to create applications Services may be combined with normal coding techniques, or using high-level technologies such as BPEL, WS-CDL, or WS- Coordination With low coupling, a change in one module will not require a change in the implementation of another module Furthermore, different modules (or services) can be implemented in completely different ways Business Process Execution Language (or BPEL), is a business process modeling language that is executable WS Choreography Definition Language (WS-CDL) is an XML-based language that describes peer-to-peer collaborations of Web Services participants WS-Coordination is a Web Services specification that describes an extensible framework for providing protocols that coordinate the actions of distributed applications Copyright LearningPatterns Inc. All rights reserved. 15

22 Session 1: SOA and Web Services Some Advantages of SOA Allows creation of small, decoupled services that can be used as building blocks to create larger business processes Enables greater reuse of services, and greater flexibility in creating applications Enables faster response time to business needs, and easier (lower cost) development of new applications Facilitates the reuse of legacy systems in new applications Allows services to be flexibly exposed to external users Supports greater uniformity among applications For example, multiple applications can use the same service to support user logon End result is a manageable, flexible architecture that allows you to quickly adapt to changing business requirements Allowing you to better meet customer needs Legacy systems can be exposed using an SOA layer on top of the legacy system This preserves the investment in the legacy system, yet exposes the core business service it provides an a manner that's easy to use in new applications that are written with different technologies Copyright LearningPatterns Inc. All rights reserved. 16

23 Session 1: SOA and Web Services Some Issues with SOA Introduces another layer around the service Adds overhead and complexity, which can be substantial depending on the technology used to expose the service Still immature understanding around SOA needs and the technologies used (for example Web Services technology) How are service contracts and service level agreements defined? Interoperability, for example has been an issue with Web Services (addressed by WS-I) It is also easy to confuse SOA with the technology you use to implement it - for modeling, use a technology agnostic approach Management (governance) of SOA systems is complex Security of SOA systems is complex Security built into the application may not be adequate if you are exposing them as a service in new ways It's important to model the services in business terms, rather than based on technical aspects of a specific technology This allows you to be technology agnostic, and implement your model in different technologies It also allows you to more easily communicate the model to business users SOA governance can be a major issue If a business process is implemented by orchestrating several underlying services, governing the process depends on governing the underlying services These underlying services may be distributed over several servers, on multiple platforms Copyright LearningPatterns Inc. All rights reserved. 17

24 Session 1: SOA and Web Services Web Services Overview SOA Overview Web Services Overview SOAP and WSDL Concepts Copyright LearningPatterns Inc. All rights reserved. 18

25 Session 1: SOA and Web Services Web Services Defined Web Services are a very common way to implement SOA Web Services are networked application components that can interoperate using standard Web protocols They are characterized by high interoperability and usability via programmatic interfaces They can be combined in a loosely coupled way There is no clear definition of Web Services - it is a general term that may be applied to many technologies It may mean a lot of different things to different people: Many people think that Web services = web applications Some think that Web services necessarily involves an e- commerce transaction Others equate Simple Object Access Protocol (SOAP) with web services (they are related, but not equivalent) Web services mean a lot of different things to different people: Many people think that Web services = web applications Some think that Web services necessarily involves an e-commerce transaction Others equate Simple Object Access Protocol (SOAP) with web services (they are related, but not equivalent) Copyright LearningPatterns Inc. All rights reserved. 19

26 Session 1: SOA and Web Services Value Proposition Since the early 90s, we have seen increasing value over time as our networks become more intelligent and standards evolve Value Connect Browse/ Present Web Sites We Are Here Integrate/ Transact Automate/ Collaborate SOA SOA / Web Web Services Services TCP/IP HTML XML, SOAP WSDL, UDDI ebxml, WSFL Time Copyright LearningPatterns Inc. All rights reserved. 20

27 Session 1: SOA and Web Services Web Services Defined Any application that accepts XML-formatted requests from other systems across a network (Internet or Intranet) via lightweight, vendor-neutral communications protocols. The general definition above encompasses most of the technologies falling under the Web Services umbrella The W3C recommendations have become a standard Web Services platform, and they include the following: XML/XML Schema for defining Web Services messages SOAP as the protocol of carrying Web Services messages HTTP support as a transport protocol WSDL (Web Services Description Language) as the language to define service interfaces XML XML Schema XML Namespaces SOAP WSDL UDDI XML-Binary Higher Level Specs Web Services can be defined as: Standards-based, Vendor-neutral, Language-agnostic, Service-centric (asynchronous nature of the Internet), Utilizing XML to provide extensible forward thinking data exchanges, Easy to use A common question is why weren't existing distributed, middleware solutions like EJB/RMI, CORBA, or DCOM used? The answer is simply that Web Services based on the standards above have become popular, with a lot of support from vendors and a large following among users We'll compare them to some of the other alternatives DCOM: Is viewed as proprietary (Microsoft), negating goal of standards-based interoperability Ported to Unix/Java; not popular or used often Java EE EJB/RMI : Java-based, does not play well with others Improvements to RMI by embracing IIOP (joined forces with CORBA) CORBA: Comes closer: standards-based, vendor-neutral, and language-agnostic Early interoperability issues caused bad reputation It was limited by inability to utilize the Internet Copyright LearningPatterns Inc. All rights reserved. 21

28 Session 1: SOA and Web Services WS-* Web Services Specifications WS-* Web services are comprised of a host of standards that build on top of the core technologies They are maintained by a number of organizations, including: W3C: World Wide Web Consortium OASIS - Organization for the Advancement of Structured Information Standards WS-I: Web Services Interoperability Organization The WS-* technologies include: WS-Addressing WS-Interoperability WS-Policy WS-Security Many, many more REST (Representational State Transfer) is another way of architecting Web services Copyright LearningPatterns Inc. All rights reserved. 22

29 Session 1: SOA and Web Services The Web Services Stack The Web services stack is a collection of protocols and specifications used to define Web services They are defined in layers that build upon each other In general, you can conceptualize them in three stacks, as follows: Wire Stack: The concepts and technologies dealing with the actual physical exchange of information Includes network transport, and message definition & packaging Description Stack: How the service provider communicates how to invoke the Web service to the service requestor Actually a stack of XML description documents Includes how to invoke the web service, messages/encoding the service expects and returns and where to send them to Discovery Stack: How to publish and discover services Including simple mechanisms like retrieving a WSDL doc from a file, as well as complex ones like publication/discovery using UDDI The stacks aren't really formally defined Nor are all the technologies involved in each stack specified anywhere They are simply a convenient way of categorizing web services technologies Copyright LearningPatterns Inc. All rights reserved. 23

30 Session 1: SOA and Web Services Web Services Stacks Registry (UDDI) Inspection Discovery Stack Business Orchestration, Policy, Service/Business Level Agreements Service Description - (WSDL) XML Schema Description Stack APIs: JAX-WS, QOS Security Management The stacks are layered on top of one another The layers may not be entirely independent of each other Overriding concerns like Quality of Service (QOS), Security and Management extend across all the layers in the stack Extensions: Routing, Policy XML/SOAP Protocol TCP/IP - HTTP (FTP, SMTP, JMS ) Wire Stack Copyright LearningPatterns Inc. All rights reserved. 24

31 Session 1: SOA and Web Services Architectural Perspective A web service is essentially a standards-based façade, or wrapper for accessing existing business functionality in a standard, platform and language neutral way The business service are often implemented by other middleware components Web Services technology primarily exposes functionality implemented with other technology Web Server XML Request XML Response Listener Web Service middleware Business Service The various pieces perform the following tasks: Listener: intercepts the client request and routes web service requests to the appropriate service Web Service: unmarshalls the XML sent by the client, parses the parameters and method call, and invokes the client request via the underlying middleware. Then the web service retrieves the result from the middleware layer, encodes it in XML, marshalls the XML document, and sends the response back to the client. Middleware: (this layer is optional) the middleware layer acts as an intermediary between the web service and the business service that the client is ultimately interested in accessing Business Service: the resource the client is ultimately trying to access Copyright LearningPatterns Inc. All rights reserved. 25

32 Session 1: SOA and Web Services Architectural Details Application Server SOAP HTTP SOAP HTTP Listener Web Service EJB,.NET, CORBA components Vendor-specific API, etc. middleware SOAP has become the accepted standard for XML-based messaging. -- the wire format HTTP is the de-facto protocol for the Internet. -- the protocol The Web Service will parse the request and either fulfill the request directly, or invoke one or more business services via some middleware API Copyright LearningPatterns Inc. All rights reserved. 26

33 Session 1: SOA and Web Services SOAP and WSDL Concepts SOA Overview Web Services Overview SOAP and WSDL Concepts Copyright LearningPatterns Inc. All rights reserved. 27

34 Session 1: SOA and Web Services SOAP Concepts SOAP defines the basic protocol for communication between two parties It is an XML based messaging protocol using standard protocols (e.g. HTTP) for transport Provides for platform independence, independence from programming language, operating system, platform, or vendor Defined by W3C A SOAP message is an XML document sent via a transport protocol such as HTTP (in the body of an HTTP POST) SOAP relies upon two other XML specifications: XML Namespaces: Identify and qualify XML elements XML Schema: Defines standard data types as well as defining structure of custom types SOAP Is the heart of Web Services 1.1 spec published by Microsoft, IBM, Lotus, and others on April 26, 2000 First widely used version Now maintained by the W3C 1.2 is current SOAP release Links to the SOAP specifications can be found at SOAP used to be an acronym for Simple Object Access Protocol As the specification evolved, and it became clear that SOAP was concerned with services, not objects, other meanings were considered For example, Services-Oriented Architecture Protocol Eventually it was decided that SOAP wasn't an acronym, but simply the protocol name XML Schemas are crucial to SOAP s language independence and interoperability Schema-aware applications can be written in any programming language Client and server simply map SOAP elements to specific implementation elements based upon schema definition Copyright LearningPatterns Inc. All rights reserved. 28

35 Session 1: SOA and Web Services Anatomy of a SOAP Message A SOAP message consists of three essential parts: Envelope the outer wrapper of a SOAP message - defines the namespaces used within the message Header (optional) carries auxiliary information for authentication, transactional information, etc. Body the heart of the message containing the XML data of the message When sent as a part of an HTTP POST, two HTTP headers are required: contenttype set to "text/xml" SOAPAction set to either an empty String or the name of the SOAP method (more on this later) Copyright LearningPatterns Inc. All rights reserved. 29

36 Session 1: SOA and Web Services A Typical SOAP Scenario SOAP messaging process Client sends an HTTP POST request to the server with a SOAP message in the request body The server has designated a web application to handle SOAP requests and forwards the client request to it The web application ensures the proper HTTP headers have been set and forwards the request to the SOAP engine The SOAP engine parses the document, processes the request and returns a SOAP message containing an error, or containing a response to the request Client application SOAP request SOAP response App server SOAP processor Copyright LearningPatterns Inc. All rights reserved. 30

37 Session 1: SOA and Web Services WSDL Concepts Web Services Description Language (WSDL) An XML-based language for describing Web Services At a high level, WSDL has capabilities to: Define the service interface (what services are offered and what is the format of the request/response messages) Describe the binding of a service to a protocol (e.g. HTTP or SOAP) Specify the location of a service (e.g. with a URL) WSDL enables the creation of platform neutral descriptions of services It is essentially the IDL of web services Specified in the W3C WDSL 2.0 recommendation WSDL 2.0 is fairly new, and support is still growing WSDL 1.1, the previous specification is widely supported WSDL 1.1 is defined by a draft specification released March 15, 2001 by Ariba, IBM, and Microsoft It was never formally adopted by standards organizations, but became a de-facto standard WSDL 2.0 is a formal standard of the W3C (which calls it's standards W3C recommendations) IDL stands for Interface Definition Language It is a platform and language neutral description language that was developed for CORBA (Common Object Request Broker Architecture) - an early technology for creating distributed objects Copyright LearningPatterns Inc. All rights reserved. 31

38 Session 7: Security Session 7: Security Java EE Security and Web Services HTTPS WS-Security (WSS) Copyright LearningPatterns Inc. All rights reserved. 313

39 Session 7: Security Lesson Objectives Understand the Java EE Security Architecture, and how it relates to Web Services Apply Basic Authentication to Web Services Use Web Services over HTTPS Understand WS-Security (WSS) Copyright LearningPatterns Inc. All rights reserved. 314

40 Session 7: Security Java EE Security and Web Services Java EE Security Overview and Web Services HTTPS WS-Security (WSS) Copyright LearningPatterns Inc. All rights reserved. 315

41 Session 7: Security Web Service Security Requirements There are a number of key aspects that are important when dealing with the security of Java EE applications We'll review them, then show how Web services utilize them Authentication: Identifying a user There must be a way of reliably identifying a user For example with a name and password Authorization: Granting of access rights Different users need to have differing levels of access to resources Data Integrity: Information must be protected from tampering Generally done by encryption of some sort, e.g. SSL Data Privacy: Information must be protected from unauthorized access Also generally done using encryption Copyright LearningPatterns Inc. All rights reserved. 316

42 Session 7: Security Security in Java EE Authentication: Support for various mechanisms to authenticate the identity of a user Web: HTTP Basic Authentication, Form Based Authentication, Digest Authentication, Client Certificate Authentication Java Client: JAAS Authorization: Role-based access model to resources Users mapped to roles Access to resources configured in deployment descriptor (DD) in terms of roles Data Integrity and Confidentiality: Supports the use of SSL to protect data Configured in DD for Web resources JAX-WS Services can use the Java EE security mechanisms Copyright LearningPatterns Inc. All rights reserved. 317

43 Session 7: Security Transport Level Security with HTTPS/SSL Provides data encryption, server authentication, message integrity using Secure Sockets Layer (SSL) for TCP/IP Uses Public Key Encryption (PKE) Uses two keys to encrypt data; a public key known by everyone, and a private key known to the recipient Sender encrypts data with the public key, and receiver decrypts with the private key Very difficult to decrypt without knowing the private key Public keys are shared via certificates that are verified (signed) by some trusted authority (e.g. VeriSign) Usually using an X.509 based certificate HTTPS also can optionally require a client certificate Copyright LearningPatterns Inc. All rights reserved. 318

44 Session 7: Security Java EE Security Overview Integrates application security into Java EE Allows security policies to be set in deployment descriptors rather than being hard-coded at development time Works with existing security systems When clients use a resource, they authenticate to the server By one of the methods described earlier May be assigned a default identity, e.g. "guest" The container keeps track of the client identity Identity stored "container-wide" so that once you are logged in, your identity is known to all apps in the container Security identity propagated to other resources (e.g. Web to EJB) Re-authentication required only when security policy boundary crossed Copyright LearningPatterns Inc. All rights reserved. 319

45 Session 7: Security Java EE Security In a typical Java EE application, a Web application from an unauthenticated user will request a protected resource (1) Web container prompts user for security credentials (e.g. name/password) through one of the standard methods (2) User supplies credentials (3), is authenticated in the Web tier, and a security context is associated with the user Web container may make requests of other resources, and propagates the security context if it does Web tier responds (4) and returns a token (e.g. session cookie), which the browser includes on subsequent requests (5) Browser application server 1. Get protected resource 2. Request credentials 3. Supply credentials 4. Response + token Web Security context EJB 5. Request + token Web tier security provides a number of ways for the client to authenticate Basic, form-based, digest, etc. Copyright LearningPatterns Inc. All rights reserved. 320

46 Session 7: Security Java EE Declarative Security Java EE security is declarative and role based Specified in the deployment descriptor using roles, access control and integrity/confidentaility constraints Defines a logical security structure - i.e., roles are logical names mapped to physical users and groups A security role is a grouping of users for the purpose of enforcing a common security policy For example, the manager role vs the customer role A user may serve in more than one role Role names (e.g., Customer ) are specified and used within the standard deployment descriptors to set the basic security policy The logical structure in the deployment descriptor is mapped to an app servers specific security policy The security policy is enforced by the Java EE container at runtime Role-based security is not unique to Java EE. It is used in various security systems throughout the industry. Security is specified in terms of user roles, rather than programmed into your components It is enforced by the container The J2EE specifications note that it is important to keep in mind that the security roles in the deployment descriptor are used to define the logical security view of an application. Roles defined in the J2EE deployment descriptors should not be confused with the user groups, users, principals, and other concepts that exist in the target enterprise's operational environment. The deployment descriptor roles are application constructs with application domain-specific names. For example, a banking application might use role names such as BankManager, Teller, or Customer. [JBoss AS Server Configuration Guide 8.1.3] Copyright LearningPatterns Inc. All rights reserved. 321

47 SOA and Web Services with JAX-WS Session 7: Security Example: Security Role Declaration Fragment of role and method permission declarations in the web application deployment descriptor (web.xml) : This declares the Student role for use later in the DD <!-- XML headings and entries --> <web-app> <display-name>javainstructor</display-name> <security-role> <description> This role includes all students </description> <role-name>student</role-name> </security-role> <!-- --> </web-app> Roles must be declared before they can be used to define security constraints In the slide, we declare the Student role for use in other parts of the DD Copyright LearningPatterns Inc. All rights reserved. 322

48 SOA and Web Services with JAX-WS Session 7: Security Specifying Security Constraints The DD can specify the intended protection of web resources A constraint consists of the following: Web resource collection: A set of URL patterns and HTTP methods that describe a set of resources to be protected Authorization constraint: A set of security roles, at least one of which users must belong to for access to resources in the web resource collection Users not in any of the roles are denied access User data constraint: Describes requirements for the transport layer integrity - preventing data tampering while in transit confidentiality - preventing reading while in transit The container must use SSL (HTTPS) for resources marked integral or confidential Copyright LearningPatterns Inc. All rights reserved. 323

49 SOA and Web Services with JAX-WS Session 7: Security Security Constraints - Deployment Descriptor <web-app> <display-name>javatunes</display-name> <!-- --> <security-constraint> <!-- Protect all POST requests in the Web app using /* --> <!-- For Web services, only POST should be specified --> <web-resource-collection> <web-resource-name>study</web-resource-name> <url-pattern>/*</url-pattern> <http-method>post</http-method> </web-resource-collection> <!-- Only users in Student role can access javatunes --> <auth-constraint> <role-name>student</role-name> </auth-constraint> </security-constraint> </web-app> In the example above, we've used a wild card in the URL pattern of /* That means that this security constraint will apply to any URL underneath the context root of this web app We specify that only those users in the Student role will have access to the resources specified by the security constraint Which, in this case, is any resource in the web app requested via a POST since the url-pattern in the web resource collection matches any URL Copyright LearningPatterns Inc. All rights reserved. 324

50 SOA and Web Services with JAX-WS Session 7: Security Mapping Users to Roles How a server manages users is left entirely to the vendor Each server provides a way to define users and how they are grouped and mapped to roles Production servers also provide ways to hook into existing security systems For example, many servers can be configured to use a database or an LDAP server for security information In JBoss, it's done by specifying a security domain in the jboss-web.xml file The example below shows the use of a simple file-based security domain (jmx-console) that comes pre-configured in JBoss <jboss-web> <security-domain>java:/jaas/jmx-console</security-domain> <context-root>javatunes</context-root> </jboss-web> Copyright LearningPatterns Inc. All rights reserved. 325

51 SOA and Web Services with JAX-WS Session 7: Security HTTP Basic Authentication Support for HTTP Basic Authentication is required by JAX-WS Based on username and password. Defined in HTTP 1.0. Not very secure - uses a simple base64 encoding Usually used in conjunction with HTTPS Very simple to do Just requires a <login-config> element in the web.xml Specify the type of authentication (BASIC) Specify the name of the realm (which is just an identifier) <login-config> <auth-method>basic</auth-method> <realm-name>student Realm</realm-name> </login-config> HTTP Basic Authentication is defined in the HTTP/1.0 specification You can look at the Internet RFC 2617 for more info on Basic and Digest Authentication The realm is not really important when doing Web services When using a browser, the realm is used to work with the browser so it can easily send the authentication information after someone has logged into the realm Copyright LearningPatterns Inc. All rights reserved. 326

52 Session 7: Security JAX-WS Clients and Basic Authentication Basic authentication is easy on the client with JAX-WS Via the javax.xml.ws.bindingprovider interface, implemented by the Port object retrieved in the client BindingProvider gives access to a request context, which is used to initialize the message context for requests, via: Map<String,Object> getrequestcontext() It also defines standard properties, PASSWORD_PROPERTY and USERNAME_PROPERTY that can be used in the context to provide Basic authentication information, as shown below JavaInstructorService service = new JavaInstructorService(); JavaInstructor inst = service.getjavainstructorport(); // Get the request context. Map<String,Object> requestctx = ((BindingProvider)inst).getRequestContext(); requestctx.put(bindingprovider.username_property, "admin"); requestctx.put(bindingprovider.password_property, "admin"); When you initialize the username and password properties on the request context using BindingProvider, these properties are used to send Basic authentication information when the request is made This is done using standard HTTP headers, and is all taken care of by the JAX-WS runtime Copyright LearningPatterns Inc. All rights reserved. 327

53 SOA and Web Services with JAX-WS Lab 7.1 Basic Authentication Lab 7.1 Using Basic Authentication Copyright LearningPatterns Inc. All rights reserved. 328

54 SOA and Web Services with JAX-WS Lab 7.1 Basic Authentication Lab 7.1 Basic Authentication Lab Overview: In this lab, we will add authentication requirements to our catalog search service We will use the existing jmx-console domain in JBoss (which has one user (admin) in the JBossAdmin role We'll add authentication requirements to our service using this domain We'll modify the client to provide the authentication Objectives: Work with Basic authentication for a Web service Builds on previous labs: None This is a new lab, in a new project The root lab directory is: workspace\lab07.1 Approximate Time: minutes Copyright LearningPatterns Inc. All rights reserved. 329

55 SOA and Web Services with JAX-WS Lab 7.1 Basic Authentication Create a Project Lab The root lab directory where you will do all your work is: C:\StudentWork\JWS\workspace\Lab07.1 This is a new lab directory containing skeleton code for the lab Tasks to Perform Create a Dynamic Web Project* Right click in Project Explorer, and select New Dynamic Web Project Call the project Lab07.1, & click Next In the next dialog, set the Context Root to javacatalog and click Finish Go to the Servers view, by right clicking on the JBoss server, and select Add and Remove Projects Select the Lab06.1 project and Remove it from the server * Right click on the server and select Publish We are using the same root URL (/javacatalog) to be consistent with the previous service deployment, so we need to remove the old project We need to remove the old service implementation from the server because we are using the same URL (/javacatalog) You need to remove the old one and publish to the server before adding in the new one If you try to do remove the old one and add the old one at the same time, you might get an error that you have a naming conflict, and the new service won't deploy Copyright LearningPatterns Inc. All rights reserved. 330

56 SOA and Web Services with JAX-WS Lab 7.1 Basic Authentication Add Authentication Elements Lab Tasks to Perform Open WEB-INF/web.xml, for editing Go to the <login-config> element, and set the auth-method to BASIC Go to the <security-role> element, and declare the JBossAdmin security role Go to the <security-constraint> element, and finish its <web resource collection>, so that all POST requests are protected by the constraint Finish its <auth-constraint> so only users in the JBossAdmin role will be allowed access Open WEB-INF/jboss-web.xml, for editing Set the <security-domain> element to be: java:/jaas/jmx console We have to use the name as it appears in JNDI here, and JBoss always puts security domains into JNDI under the java:/jaas context Copyright LearningPatterns Inc. All rights reserved. 331

57 SOA and Web Services with JAX-WS Lab 7.1 Basic Authentication Invoke on the Service Lab Tasks to Perform Go to the Servers view, by right clicking on the JBoss server, and select Add and Remove Projects Select the Lab07.1 project and Add it to the server * Right click on the server and select Publish Go back to your Lab05.2 project, and open JavaTunesCatalogClient.java for editing We need to add authentication to our existing client First try running the client as it is - it should fail since you don't supply authentication In the main method, get the request context, and add in a username/password of admin/admin (see the sample code in the earlier manual slides) Run the client again - it should now work That's it, you've added authentication STOP Copyright LearningPatterns Inc. All rights reserved. 332

58 Session 7: Security HTTPS Java EE Security and Web Services HTTPS WS-Security (WSS) Copyright LearningPatterns Inc. All rights reserved. 333

59 Session 7: Security HTTPS / SSL - Transport Level Security SOAP supports the use of HTTPS Web standard for authenticated and encrypted communication between clients and servers Runs above TCP/IP and below higher-level protocols such as HTTP or IMAP Allows SSL-enabled server to authenticate itself to SSL-enabled client Allows the client to authenticate itself to the server Allows both machines to establish an encrypted connection Encrypts all data sent between client and server By convention uses https: URL instead of http: Copyright LearningPatterns Inc. All rights reserved. 334