Table of Contents : SOA and Web Services with Java / JAX-WS...20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved i Table of Contents : SOA and Web Services with

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved i

™

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

WSDL Anatomy _________________________________________________________________ 32

WSDL Anatomy _________________________________________________________________ 33

Lab 1.1 – Setting Up the Environment ____________________________________________ 34 Session 2: Introduction to Java Web Services _______________________________ 49

Session Objectives________________________________________________________________ 50

Overview _________________________________________________________________ 51

Java Web Services (JWS) Standards __________________________________________________ 52

Java Web Services Standards _______________________________________________________ 53

Java First Web Services____________________________________________________________ 54

Java Web Services Platform ________________________________________________________ 55

SOA Architecture with Java Web Services _____________________________________________ 56

A Simple Web Service ______________________________________________________ 57

Defining a Simple Web Service _____________________________________________________ 58

Annotating the Implementation Class _________________________________________________ 59

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved ii

™

A Brief Note About Annotations_____________________________________________________ 60

Declaring the Web Service in web.xml ________________________________________________ 61

Deploying the Web Application _____________________________________________________ 62

Deploying the Web Application _____________________________________________________ 63

Recap__________________________________________________________________________ 64

Lab 2.1 – Creating a Simple Web Service __________________________________________ 65 JSR-181: WS-Metadata _____________________________________________________ 76

JSR-181 Defines the Web Service____________________________________________________ 77

@WebService Details _____________________________________________________________ 78

Affecting the Generated WSDL _____________________________________________________ 79

Other Important JSR-181 Annotations ________________________________________________ 80

The Service Endpoint Interface (SEI) _________________________________________________ 81

An SEI and an Associated SIB ______________________________________________________ 82

@WebMethod Details _____________________________________________________________ 83

Lab 2.2 – Defining a Service With an SEI __________________________________________ 84 @Oneway Details ________________________________________________________________ 95

@SOAPBinding Details ___________________________________________________________ 96

WRAPPED vs BARE _____________________________________________________________ 97

@WebParam and @WebResult______________________________________________________ 98

JAX-WS Capabilities _______________________________________________________ 99

JAX-WS ______________________________________________________________________ 100

WSDL / Java Mapping ___________________________________________________________ 101

WSDL / Java Mapping ___________________________________________________________ 102

XML Messaging Support _________________________________________________________ 103

Handler Framework______________________________________________________________ 104

SOAP and HTTP Binding _________________________________________________________ 105

JAX-WS Client Side Programming__________________________________________________ 106

Creating JAX-WS Clients __________________________________________________ 107

Client Side Programming Model____________________________________________________ 108

Generated Classes for Service and Port_______________________________________________ 109

Details of the Generated JavaInstructor_______________________________________________ 110

Details of the JavaInstructorService Class_____________________________________________ 111

Writing a JAX-WS Client _________________________________________________________ 112

Dynamic Proxies ________________________________________________________________ 113

The QName and Service Types _____________________________________________________ 114

Lab 2.3 – A JAX-WS Client ____________________________________________________ 115 Session 3: WSDL _____________________________________________________ 124

Lesson Objectives _______________________________________________________________ 125

Introduction to WSDL _____________________________________________________ 126

Overview of WSDL______________________________________________________________ 127

WSDL Elements ________________________________________________________________ 128

WSDL Bindings ________________________________________________________________ 129

WSDL in Practice _______________________________________________________________ 130

XML Namespaces and XML Schema _________________________________________ 131

WSDL Documents are XML Documents _____________________________________________ 132

XML Namespaces _______________________________________________________________ 133

Namespaces Described ___________________________________________________________ 134

Namespace Terminology__________________________________________________________ 135

Default Namespaces _____________________________________________________________ 136

Namespaces in a WSDL Document _________________________________________________ 137

Namespaces in a WSDL Document _________________________________________________ 138

XML Schema __________________________________________________________________ 139

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved iii

™

Simple Schema / XML Document Examples __________________________________________ 140

xsd:complexType _______________________________________________________________ 141

xsd:complexType Example ________________________________________________________ 142

complexType in WSDL___________________________________________________________ 143

xsd:complexType in WSDL _______________________________________________________ 144

WSDL Structure and Elements ______________________________________________ 145

WSDL Anatomy ________________________________________________________________ 146

WSDL Anatomy ________________________________________________________________ 147

<definitions> Element ____________________________________________________________ 148

<documentation> Element_________________________________________________________ 149

<types> Element ________________________________________________________________ 150

The Generated types _____________________________________________________________ 151

<message> Element______________________________________________________________ 152

<portType> and <operation>_______________________________________________________ 153

<binding> Element ______________________________________________________________ 154

<port> and <service> Elements_____________________________________________________ 155

Operation Types ________________________________________________________________ 156

Recap_________________________________________________________________________ 157

Lab 3.1 – Review WSDL _______________________________________________________ 158 Session 4: SOAP______________________________________________________ 161


SOAP in a Nutshell ________________________________________________________ 163

What is SOAP __________________________________________________________________ 164

SOAP 1.1 vs. SOAP 1.2 __________________________________________________________ 165

What is a SOAP Message _________________________________________________________ 166

SOAP Message Structure _________________________________________________________ 167

A SOAP Message _______________________________________________________________ 168

SOAP Detailed Structure__________________________________________________________ 169

SOAP Detailed Structure__________________________________________________________ 170

SOAPMessage__________________________________________________________________ 171

SOAP Faults ___________________________________________________________________ 172

SOAP Messaging and HTTP Binding_________________________________________ 173

SOAP Messaging________________________________________________________________ 174

SOAP Intermediaries_____________________________________________________________ 175

SOAP Message Exchange Patterns __________________________________________________ 176

SOAP Binding__________________________________________________________________ 177

SOAP HTTP Binding ____________________________________________________________ 178

HTTP Request/Response Details____________________________________________________ 179

Request and Response Example ____________________________________________________ 180

SOAP Message Example__________________________________________________________ 181

SOAP Message Example__________________________________________________________ 182

SOAP Styles and Encoding _________________________________________________ 183

SOAP Styles ___________________________________________________________________ 184

Literal Encoding ________________________________________________________________ 185

SOAP Encoding_________________________________________________________________ 186

Lab 4.1 – Examining SOAP Messaging ___________________________________________ 187 Session 5: SAAJ, DOM, and SOAP Handlers ______________________________ 193


SAAJ ___________________________________________________________________ 195

SAAJ Overview_________________________________________________________________ 196

SAAJ Message Structure__________________________________________________________ 197

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved iv

™

SOAPMessage__________________________________________________________________ 198

SOAPPart and AttachmentPart _____________________________________________________ 199

SAAJ Classes (In Brief) - In javax.xml.soap___________________________________________ 200

SAAJ Classes (In Brief) - In javax.xml.soap___________________________________________ 201

SAAJ Classes (In Brief) __________________________________________________________ 202

Creating SOAP Messages with SAAJ ________________________________________________ 203

Creating SOAP Messages with SAAJ ________________________________________________ 204

Sending a Message With SAAJ_____________________________________________________ 205

SOAP Attachments ______________________________________________________________ 206

Examples of SOAP Attachments____________________________________________________ 207

DOM____________________________________________________________________ 208

SAAJ and DOM ________________________________________________________________ 209

DOM Overview_________________________________________________________________ 210

JavaTunes Order XML Document___________________________________________________ 211

JavaTunes Order XML Document___________________________________________________ 212

JavaTunes Order as a DOM Tree ___________________________________________________ 213

The DOM Tree _________________________________________________________________ 214

The DOM Interfaces _____________________________________________________________ 215

The Node Interface ______________________________________________________________ 216

Navigating the DOM Tree_________________________________________________________ 217

The Document and Other Interfaces _________________________________________________ 218

Extracting Content with SAAJ/DOM ________________________________________________ 219

Lab 5.1 – Using SAAJ _________________________________________________________ 220 SOAP Handlers___________________________________________________________ 227

SOAP Handlers _________________________________________________________________ 228

Handler Processing ______________________________________________________________ 229

Logical and Protocol Handlers _____________________________________________________ 230

A Sample Handler _______________________________________________________________ 231

The SOAPHandler interface _______________________________________________________ 232

MessageContext ________________________________________________________________ 233

SOAPMessageContext ___________________________________________________________ 234

A Sample SOAP Protocol Handler __________________________________________________ 235

Handler Invocation ______________________________________________________________ 236

MessageContext Properties ________________________________________________________ 237

Configuring Handler Chains _______________________________________________________ 238

Returning a Fault ________________________________________________________________ 239

Logical Handlers ________________________________________________________________ 240

Lab 5.2 – Creating a Handler ___________________________________________________ 241 Session 6: JAXB______________________________________________________ 247


JAXB Overview __________________________________________________________ 249

JAXB Overview ________________________________________________________________ 250

JAXB Architecture ______________________________________________________________ 251

How it Works – XML-Java-XML - Illustrated _________________________________________ 252

General Binding Process __________________________________________________________ 253

Generating Classes From a Schema __________________________________________ 254

How it Works - Generating the Classes_______________________________________________ 255

Example - XML Document ________________________________________________________ 256

Example - XML Schema order.xsd __________________________________________________ 257

The Generated Classes____________________________________________________________ 258

Example - The Generated Classes - ItemType _________________________________________ 259

Example - The Generated Classes - OrderType ________________________________________ 260

Example - The Content Tree - Illustrated _____________________________________________ 261

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved v

™

Lab 6.1 – Binding a Simple Schema______________________________________________ 262 Customization of Generated Java ____________________________________________ 266

Customization Overview __________________________________________________________ 267

Binding Declarations and Binding Language __________________________________________ 268

Binding Declarations and Scope ____________________________________________________ 269

Example – Inline Definition Binding ________________________________________________ 270

Example – Inline Global Binding ___________________________________________________ 271

Example – Inline Schema Binding __________________________________________________ 272

Binding Customizations Capabilities ________________________________________________ 273

<nameXmlTransform> ___________________________________________________________ 274

Other Binding Customizations _____________________________________________________ 275

External Binding Declarations______________________________________________________ 276

Example - External Binding Declaration______________________________________________ 277

Using External Binding Files ______________________________________________________ 278

Generating Schema from Java ______________________________________________ 279

Generating Schema from Java______________________________________________________ 280

Example – Generating Schema from Java_____________________________________________ 281

Example – Generating Schema from Java_____________________________________________ 282

Example – Resulting Schema File___________________________________________________ 283

Customizing - @XmlRootElement __________________________________________________ 284

@XmlType ____________________________________________________________________ 285

@XmlType.propOrder ___________________________________________________________ 286

@XmlAccessorType _____________________________________________________________ 287

Mapping an ID__________________________________________________________________ 288

@XmlElement__________________________________________________________________ 289

Example – Order Class with JAXB__________________________________________________ 290

Example – ItemType Class with JAXB_______________________________________________ 291

Java Web Services and JAXB _______________________________________________ 292

Java Web Services and JAXB ______________________________________________________ 293

JAXB and WSDL Mapping________________________________________________________ 294

The JAXB Annotations ___________________________________________________________ 295

Using JAXB with Java Web Services ________________________________________________ 296

Using JAXB ___________________________________________________________________ 297

Lab 6.2 – Customizing WSDL with JAXB ________________________________________ 298 Session 7: Starting From WSDL or WSDL & Java __________________________ 302

Starting From WSDL ____________________________________________________________ 303

JAX-WS Binding Customizations___________________________________________________ 304

JAX-WS Binding Customizations Example ___________________________________________ 305

Other JAX-WS Binding Customizations______________________________________________ 306

JAXB Binding Customizations _____________________________________________________ 307

JAXB Binding Example __________________________________________________________ 308

Starting from WSDL and Java______________________________________________________ 309

Starting from WSDL and Java______________________________________________________ 310

Lab 7.1 – Starting From WSDL _________________________________________________ 311 Session 8: XML Based Web Services _____________________________________ 320


XML Services - JAX-WS Providers __________________________________________ 322

XML Messaging ________________________________________________________________ 323

JAX-WS Providers ______________________________________________________________ 324

A SOAP Provider _______________________________________________________________ 325

How Providers Work_____________________________________________________________ 326

A SOAP Provider - invoke() Example _______________________________________________ 327

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved vi

™

Example - Source Provider using Payload ____________________________________________ 328

Source Provider - invoke() Example _________________________________________________ 329

Working with the Request _________________________________________________________ 330

WebServiceContext______________________________________________________________ 331

MessageContext ________________________________________________________________ 332

MessageContext ________________________________________________________________ 333

XML Clients - The Dispatch Interface ________________________________________ 334

XML Clients ___________________________________________________________________ 335

Service and Dispatch _____________________________________________________________ 336

Dispatch<SOAPMessage> Example _________________________________________________ 337

Dispatch<Source> Example _______________________________________________________ 338

Lab 8.1 – XML Messaging _____________________________________________________ 339 XML/HTTP Based Messaging _____________________________________________________ 347

Example XML/HTTP Messaging ___________________________________________________ 348

A Provider Implementation ________________________________________________________ 349

WSDL for the HTTP Binding ______________________________________________________ 350

A Very Simple XML/HTTP Request ________________________________________________ 351

A Very Simple XML/HTTP Response _______________________________________________ 352

Provider Based Endpoints _________________________________________________________ 353

REST Overview __________________________________________________________ 354

Overview of REST ______________________________________________________________ 355

REST Details___________________________________________________________________ 356

Example of REST _______________________________________________________________ 357

REST Characteristics_____________________________________________________________ 358

Comparison of REST and SOAP____________________________________________________ 359

JAX-WS and REST______________________________________________________________ 360

JAX-RS _______________________________________________________________________ 361

Session 9: Handling Binary Data ________________________________________ 362


Overview ________________________________________________________________ 364

Binary Data ____________________________________________________________________ 365

Example – Image Data and WSDL __________________________________________________ 366

Image Data on the Wire___________________________________________________________ 367

Issues with Base64Binary Handling _________________________________________________ 368

MTOM __________________________________________________________________ 369

MTOM Overview _______________________________________________________________ 370

Example – Image Data ___________________________________________________________ 371

WSDL with Image Data __________________________________________________________ 372

MTOM Data on the Wire _________________________________________________________ 373

Details of MTOM Usage __________________________________________________________ 374

Specifying MTOM on the Server ___________________________________________________ 375

Using MTOM on the Client________________________________________________________ 376

Lab 9.1 – Using MTOM _______________________________________________________ 377 DataHandler _____________________________________________________________ 390

Binary Data Overview____________________________________________________________ 391

Using DataHandler ______________________________________________________________ 392

More About DataHandler _________________________________________________________ 393

DataHandler and Web Services_____________________________________________________ 394

Lab 9.2 – Using DataHandler ___________________________________________________ 395 Session 10: Security ___________________________________________________ 400


20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved vii

™

Java EE Security and Web Services __________________________________________ 402

Web Service Security Requirements _________________________________________________ 403

Security in Java EE ______________________________________________________________ 404

Transport Level Security with HTTPS/SSL ___________________________________________ 405

Java EE Security Overview ________________________________________________________ 406

Java EE Security ________________________________________________________________ 407

Java EE Declarative Security ______________________________________________________ 408

Example: Security Role Declaration _________________________________________________ 409

Specifying Security Constraints ____________________________________________________ 410

Security Constraints - Deployment Descriptor _________________________________________ 411

Mapping Users to Roles __________________________________________________________ 412

HTTP Basic Authentication________________________________________________________ 413

JAX-WS Clients and Basic Authentication____________________________________________ 414

Lab 10.1 – Using Basic Authentication ___________________________________________ 415 HTTPS __________________________________________________________________ 420

HTTPS / SSL - Transport Level Security _____________________________________________ 421

HTTPS / SSL Meets Some Security Needs____________________________________________ 422

SSL Pros / Cons_________________________________________________________________ 423

SSL Requires Server Setup ________________________________________________________ 424

Requiring HTTPS on a POJO Web Service ___________________________________________ 425

Invoking a Web Service with HTTPS ________________________________________________ 426

[Optional] Lab 10.2 – Using HTTPS _____________________________________________ 427 WS-Security (WSS)________________________________________________________ 439

Message Level Security___________________________________________________________ 440

XML Signature _________________________________________________________________ 441

XML Signature Structure _________________________________________________________ 442

XML Signature Mechanisms_______________________________________________________ 443

XML Signature Sample___________________________________________________________ 444

XML Signature Sample___________________________________________________________ 445

XML Encryption ________________________________________________________________ 446

XML Encryption Structure ________________________________________________________ 447

XML Encryption Mechanisms _____________________________________________________ 448

XML Encryption Example ________________________________________________________ 449

Web Services Security Overview ___________________________________________________ 450

Web Services Security Overview ___________________________________________________ 451

Web Services Security Stack_______________________________________________________ 452

Using the Security Mechanisms ____________________________________________________ 453

Session 11: EJB Based Web Services _____________________________________ 454


EJB Overview ____________________________________________________________ 456

What is EJB____________________________________________________________________ 457

EJB Goals _____________________________________________________________________ 458

Types of Enterprise JavaBeans _____________________________________________________ 459

EJB Transaction Support__________________________________________________________ 460

EJB 3.0 Overview _______________________________________________________________ 461

Session Bean Capabilities _________________________________________________________ 462

Benefits of using EJB ____________________________________________________________ 463

SOA Architecture with EJB _______________________________________________________ 464

Issues with EJB _________________________________________________________________ 465

Programming EJB ________________________________________________________ 466

What are Session Beans___________________________________________________________ 467

Stateless Session Beans (SLSB) ____________________________________________________ 468

Defining a Session Bean __________________________________________________________ 469

20111110 Copyright © 2007-10, LearningPatterns Inc. All rights reserved viii

™

Stateless Session Bean Definition ___________________________________________________ 470

Remote Business Interface ________________________________________________________ 471

EJB Packaging - ejb-jar File _______________________________________________________ 472

The EJB Container ______________________________________________________________ 473

Server Deployment ______________________________________________________________ 474

Creating EJB Based Web Services ___________________________________________ 475

EJB Based Web Services__________________________________________________________ 476

Why Use EJB for Web Services ____________________________________________________ 477

Specifying the Context and Service URLs ____________________________________________ 478

Security in EJB Based Web Services ________________________________________________ 479

Example - Security in EJB Web Services _____________________________________________ 480

[Optional] Lab 11.1 – Defining a Service With an EJB __________________________________ 481

Lab 11.1 – Defining an EJB Web Service _________________________________________ 482 Session 12: WS-* Overview _____________________________________________ 487

The WS-* Specifications__________________________________________________________ 488

WS-I Interoperability_____________________________________________________________ 489

WS-I Profiles___________________________________________________________________ 490

WS-I Basic Profile_______________________________________________________________ 491

WS-Addressing _________________________________________________________________ 492

Session 13: Best Practices ______________________________________________ 493

- Build Coarse Grained Web Services -_______________________________________________ 494

Use a Façade if Necessary_________________________________________________________ 495

- Optimize the Client for Web Services - _____________________________________________ 496

- Cache Web Service Results - _____________________________________________________ 497

- Handle XML Efficiently - ________________________________________________________ 498

- Conform to Interoperability Guidelines - ____________________________________________ 499

- Consider the Rest of Your System - ________________________________________________ 500

– Top Down and Bottom Up Design -________________________________________________ 501

Bottom Up _____________________________________________________________________ 502

Which Way to Go – Top Down / Bottom Up __________________________________________ 503

- Web Services as JEE Components - ________________________________________________ 504

Recap ______________________________________________________________ 505

Recap of What We've Done________________________________________________________ 506

What Else is There_______________________________________________________________ 507

Resources______________________________________________________________________ 508

Notes:

Copyright © 2008-11 LearningPatterns Inc. All rights reserved. 120111110

SOA and Web Services with Java

SOA and Web Services with Java/JAX-WS

The Java Developer Education Series

Notes:



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

Preface

Notes:



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 SOAPand WSDL

– Use Java specifications, including JAX-WS, JSR-181, JAXB, and JSR-109/921 to implement Web Services

Preface

Notes:



Workshop Agenda

Session 1: Introduction SOA and Web ServicesSession 2: Introduction to Java Web ServicesSession 3: WSDLSession 4: SOAPSession 5: SAAJ / DOM and SOAP HandlersSession 6: JAXBSession 7: Starting from WSDLSession 8: XML Based Web ServicesSession 9: Handling Binary DataSession 10: SecuritySession 11: EJB Based Web ServicesSession 12: WS-* OverviewSession 13: Best Practices

Preface

Notes:



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 belowpackage com.javatunes.teach;public class JavaInstructor implements Teacher {

public void teach() {System.out.println("Web Services are way cool");

}}

Preface

Notes:



Release Level

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)

All labs have been tested on JBoss 5.0.1GA (Java 5) and JBoss 5.1.0.GA (Java 5 and Java 6) – Running under Windows XP

Lab

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

Preface

Notes:



Labs

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 doneThe 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

Lab

STOP

Preface

Notes:



Session 1: Service Oriented Architecture (SOA) and Web Services

SOA OverviewWeb Services Overview

SOAP and WSDL Concepts

Session 1: SOA and Web Services

Notes:



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


Notes:



SOA Overview




Notes:



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


Notes:



The Challenge of Legacy Systems

It is estimated that over 5 billion lines of COBOL code are added annually1 on a base of over 200 billion lines of code2

– 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 requirementsUsing 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, 2001.

2 Micro Focus Moves Mainframe Apps to .Net, Daryl K. Taft, eWeek, November 4, 2003.

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


Notes:



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 requirementsSOA 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 taskDriven 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


Notes:



The Evolution of Computing

SOASOA

Client/Server Client/Server ComputingComputing

Centralized MainframesCentralized Mainframes

ServerServer--centriccentricWebWeb

Simple SOA Definition:Simple SOA Definition:Using (relatively small) interacting business Using (relatively small) interacting business

services to fulfill a larger business requirementservices 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


Notes:



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


Notes:



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 applicationsFacilitates the reuse of legacy systems in new applicationsAllows services to be flexibly exposed to external usersSupports greater uniformity among applications– For example, multiple applications can use the same service to

support user logonEnd 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


Notes:



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 serviceStill 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 complexSecurity 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


Notes:



Web Services Overview




Notes:



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)


Notes:



Value Proposition

Since the early 90s, we have seen increasing value over time as our networks become more intelligent and standards evolve

TimeTime

Valu

eVa

lue ConnectConnect

Browse/Browse/PresentPresent

TCP/IP HTML

SOA /SOA /

Web Services

Web ServicesWe AreWe AreHereHere

Integrate/Integrate/TransactTransact

Automate/Automate/CollaborateCollaborate

XML, SOAPWSDL, UDDI

ebXML, WSFL…

Web SitesWeb Sites


Notes:



Web Services Defined

The general definition above encompasses most of the technologies falling under the Web Services umbrellaThe 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

Any application that accepts XML-formatted requests from other systems across a network (Internet or Intranet) via lightweight,

vendor-neutral communications protocols.

Higher Level Specs

XML-BinaryUDDIWSDLSOAPXML NamespacesXML SchemaXML

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


Notes:



WS-* Web Services Specifications

WS-* Web services are comprised of a host of standards that build on top of the core technologiesThey 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


Notes:



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 toDiscovery 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


Notes:



Web Services Stacks

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

Managem

entSecurity

QO

SXML Schema

Service Description - (WSDL)

Business Orchestration, Policy, Service/Business Level

Agreements

Description Stack

Registry (UDDI)

Inspection

Discovery Stack

XML/SOAP Protocol

APIs: JAX-WS, …

Extensions: Routing, Policy …

Wire Stack

TCP/IP - HTTP (FTP, SMTP, JMS …)


Notes:



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

Lis

ten

erXML Request

XML Response

Web Server

mid

dle

ware

BusinessService

WebService

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


Notes:



Architectural Details

SOAP has become the accepted standard for XML-based messaging. -- the wire format HTTP is the de-facto protocol for the Internet. -- the protocolThe Web Service will parse the request and either fulfill the request directly, or invoke one or more business services via some middleware API

List

ener

SOAP

SOAP

Application Server

WebService

HTTP

HTTP

mid

dle

war

e

EJB, .NET, CORBA components

Vendor-specific API, etc.


Notes:







Notes:



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 http://www.w3.org/2002/ws/

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


Notes:



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)


Notes:



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

Clientapplication

Appserver

SOAPprocessor

SOAP request

SOAP response


Notes:



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


Notes:



WSDL Anatomy

A WSDL document is simply a set of definitions– There is a definitions element at the root, and definitions inside– Below is a listing of the main elements

Composed of port elements that associate an endpoint with a specific binding

<service>

Maps operations in a portType to a specific protocol<binding>

Group of operations<portType>

Group of messages (1-way or 2-way)<operation>

Represents a one-way transmission of data (a request or a response)

<message>

The data types that will be used in the messages<types>

Can be used to insert comments<documentation>

Top level element for declaring namespaces<definitions>

PurposeWSDL Element


Notes:



WSDL Anatomy

We show the elements for a Web Service we will create in a lab– We will go into more detail in the WSDL session later

In the slide, we've collapsed the different elements to only show the top level

– We'll look at the details of each element next


Notes:



Lab 1.1 – Setting Up the Environment

Lab 1.1: Setting up the Environment

Notes:



Lab 1.1 – Set up the Server

Overview: In this lab you will become familiar with and set up your application server and development environment– The server you'll be using is the JBoss Application Server – You'll also set up the lab directory– In the next lab, you'll set up the development environment that's

used to write your code and deploy your application

Objectives: Set up the JBoss application server– Set up the development environment– Become familiar with starting and stopping JBoss– Review some of the JBoss monitoring tools

Builds on previous labs: None

Approximate Time: 20-30 minutes

Lab


Notes:



Information Content and Task Content

Within a lab, information only content is presented in the normal way – the same as in the student manual pages– Like these bullets at the top of the page

Tasks that the student needs to perform are in a box with a slightly different look – to help you identify themAn example appears below

Tasks to PerformLook at these instructions, and notice the different look of thebox as compared to that above– Make a note of how it looks, as future labs will use this format

OK – Now get out your setup CD; we're ready to start working

Lab


Notes:



Extract the Lab Setup Zip File

To set up the labs, you'll need the setup zip file for the course– This will either be on a CD for the course, or given by the instructor,

with a file name of: LabSetup_JWS_Eclipse-JBoss_20101005.zipOur base working directory for this course will be C:\StudentWork\JWS

– This directory will be created when we extract the Setup zip– It includes a directory structure and files (e.g., Java files, XML

files, other files) that will be needed in the labs– All instructions assume that this zip file is extracted to C:\. If

you choose a different directory, please adjust accordingly

Lab

Tasks to PerformUnzip the lab setup file to C:\– This will create the directory structure, described in the next slide,

containing files that you will need for doing the labs

The students files may be distributed to you in different ways

– It may be a CD in a book, or files given to you by the

instructor

– If a CD is used, it may also contain the following folders

– Resources: Documentation, specifications, etc.


Notes:



Lab Directory Structure

StudentWork\JWS contains– Resources : Extra files (e.g. docs)– LabSetup: Files needed for lab work– workspace: Lab working directories– tcpmon: A simple TCP monitor to view

SOAP traffic

StudentWork\JWS\workspacecontains the following folders:– common: shared files– LabNN : Lab directories

• LabNN/build/ : compiled code *LabNN/src/ : Java source

• LabNN/WebContent/ : jsp, HTML• LabNN/WebContentWEB-INF/:

web.xml

Lab

We use the folder build for compiled Java output to be consistent

with what Eclipse uses by default

Some of the labs are Web applications

– These labs will include the Web related directories

– Labs that are not Web applications will not include the Web

related directories


Notes:



The JBoss Application Server

We will be using JBoss as our application server– It is an open source, J2EE Application server– It is full featured, and used very widely by developers– Fast growing market share for production– We will use it for our labs

Very easy to use– Highly scalable– Advanced features– Open Source !– Supported by JBoss Group Inc. (a division or Red Hat)

• For profit corporation created to support users of JBoss with Production and Development support

Lab


Notes:



Setup Environment

Tasks to PerformMake sure that you have Java 5/6 installed– Likely installed in a directory like C:\Program Files\Java\jdk1.n.x *

Set the JAVA_HOME environment variable for Java 5 or 6, e.g.: JAVA_HOME=C:\Program Files\Java\jdk1.5.0_22 *

Add entries to the PATH environment variable– PATH should include %JAVA_HOME%\bin (for the JDK)

Make sure JBoss is installed – in a directory like C:\jboss-5.1.0.GA(JBoss 5.1)– If it isn't installed, download it from www.jboss.org and install

Make sure that Eclipse is installed - usually in C:\eclipse– If it isn't installed, download it from www.eclipse.org and install *

If any software was installed in a different directory, you'll need to modify the instructions in the lab to refer to your install directory

Lab

Set the environment variable permanently via the Control Panel by going to:

– System | Advanced tab | Environment Variables

The value for JAVA_HOME is based on your installation of Java

– For Java 6 the directory will be something like jdk1.6.0_18, for Java 5 jdk1.5.0_22

– If you've installed it in a different location, then adjust the value accordingly

For Eclipse, use the IDE for Java EE Developers (3.5/Galileo, 3.4/Ganymede or 3.6/Helios)

The JBoss and Eclipse installs are zip files - just unzip them

– A common location is to C:\ but you can unzip the anywhere, as long as you know where,

and you modify the lab instructions to refer to your correct locations


Notes:



The Eclipse Development Environment

Eclipse is an open source platform for building integrated development environments (IDEs)– Used mainly for Java development– Can be extended via plugins to create applications useful in

many areas (e.g. C# programming)– http://www.eclipse.org is the main website

The remainder of this lab gives detailed instructions on using Eclipse to run the labs– Starting it, creating and configuring projects, using ant in Eclipse

Many labs in the course do not include specific detailsregarding Eclipse – they just say build/deploy as before– For these labs, you should use the same procedures to

build/deploy as in this lab– Refer back to these lab instructions as needed

Lab

The Eclipse source base was originally developed by IBM

– It was released by IBM into open source

– IBM's RAD (and previously its WSAD) environment is built on top of Eclipse


Notes:



Launch Eclipse

Tasks to PerformTo launch eclipse, go to c:\eclipse and run eclipse.exe– Dialog box should appear prompting for workbench location– Set the workbench location to C:\StudentWork\JWS\workspace– If a different default Workbench location is set, change it– Click OK– In the window that opens, close the Welcome window by clicking the X

on its tab (below right)

Lab

If Eclipse was installed elsewhere, adjust the paths to the Eclipse

executable accordingly - You can put a shortcut on your desktop


Notes:



The Java EE Perspectice

Eclipse starts up in the Java EE Perspective - shown below– Note the Servers view at bottom, which we'll use soon– For basic information on Eclipse, go to the end of this lab


Notes:



Create a Server Instance

Tasks to PerformWe'll configure a JBoss server in Eclipse to run our services1. Go to the Servers view, right click in it, and select New | Server2. In the next dialog, select JBoss 5.0 * and click Next3. In the next dialog, configure the server install directory, & click Next4. The defaults should be fine in the next dialog (ports and server config)5. Click Finish (See next slide for any problems with JBoss 5 server)

1 2 3

Lab

The standard JBoss 5.1.0 location is C:\jboss-5.1.0.GA

– If you have a different version, or have installed JBoss in a

different directory, then configure the server accordingly

Eclipse assumes the default ports for JBoss - which are shown

in the next to last dialog

– If your server is using different ports, configure these

accordingly

– Likewise, if you are not using the default server

configuration, then change this accordingly.

Note that you want to create the server before we do any other labs– Creating a server sets up a server runtime, which needs to be

associated with lab projects that we'll create later (this will be

done automatically by Eclipse if you have only one server

runtime in the workspace)


Notes:



Java 6 / JBoss 5 Server Setup

For JBoss 5 using Java 6 you need to do additional setup– You need to make sure the JAX-WS 2.0 api jars supported by JBoss

are used, as Java 6 contains its own JAX-WS jars

Lab

Tasks to Perform (Only if using JBoss 5 with Java 6)Manually copy the following libraries from the JBOSS_HOME/clientdirectory to JBOSS_HOME/lib/endorsed– jbossws-native-saaj.jar, jbossws-native-jaxrpc.jar,

jbossws-native-jaxws.jar, and jbossws-native-jaxws-ext.jar– If they are already there, then you don't need to do this

Modify the JBoss 5 server Run Configuration– Select menu item Run | Run Configurations– Select the JBoss 5.0 at localhost config (see notes)– In the Arguments tab, add the following JVM argument (see notes)-Djava.endorsed.dirs=C:/jboss-5.1.0.GA/lib/endorsed *

– Click Apply then Close

If you have installed JBoss in a different directory, then modify the instructions accordingly

Select the run configuration as shown below

Set the JVM argument as shown at bottom (note – there are no newlines in the VM arguments

tab – Eclipse displays these on multiple lines because they don't fit on one line


Notes:



Start the JBoss Server Lab

Tasks to PerformRight click on the server in the Servers view, and select Start– This will start up the server and produce copious debugging information

in the console view, as shown belowTo restart (stop/start) a server, right click and select RestartTo stop a server - right click and select StopSee notes for other useful information on controlling the server

Note - if you have problems timing out when starting, you can change the server configuration

– Double click on the server in the Servers view

– A window will open in the editor, that allows you to edit various configuration settings

– You can change the Timeout settings here -e.g. , if you have a slow machine, you may need

to increase the default timeout for starting the server from the default of 50 seconds

You can also change the Publishing settings, which determine how and when Eclipse pushes any

changes you make to the server - for example, you may not want to publish automatically, as this

can be annoying if a partially changed project gets published

Note - Check the JBoss console for exceptions - sometimes there are port conflicts starting JBoss

– If this happens, you can open a command prompt, and execute netstat -o to see the ports

in use, and the PID of the process using it

– You can then go to Task Manager to see what process is associated with the given PID, and

hopefully shut the process down so you can boot JBoss

If you get an error like "Wrong arguments. new for target java.lang.reflect.Constructor

expected=[java.net.URI] actual=[java.io.File]" when using Java 6, do the following

– Go to conf/bootstrap/profile.xml. Look for the definition of the AttachmentStore, and change

the constructor line so that it starts: <constructor><parameter class="java.io.File">


Notes:



JBoss Admin Console

You can see that JBoss is up and view some basic server information with the JBoss JMX-Based Admin Console

Lab

Tasks to PerformThe admin console is a Web app at the URL:

http://localhost:8080/jmx-console– Launch a browser, and go to the URL above to view the console

If you have configured your server or ports differently from the

standard installation, the URL for the consoles will need to

conform to your hostname and HTTP port


Notes:



Important Notes for Using Eclipse

Each lab that has a separate lab directory will require you to create a new Eclipse project– You'll create the project with the name of the directory specified

in the lab, as we might include a directory by that name which has files for the lab

– Sometimes several labs are done one directory, in which case you will use the same project for all of them

You should copy setup files directly into an Eclipse view(e.g. Navigator View) in which case a refresh is not needed

– If you COPY files into a project directory via the file system (e.g. using Windows Explorer) you need to Refresh the project

– Right click on the project, select Refresh

Lab

STOP

Any lab that has you copy files from the setup to your working directory will require you to

refresh the project as described above

– This is only required if you copy the files into the file system without going through

Eclipse��

– This allows Eclipse to become aware of the new files.

You can also paste files directly into an Eclipse view, in which case no refresh will be needed


Notes:



Session 10: Security

Java EE Security and Web ServicesHTTPS

WS-Security (WSS)


Notes:



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)


Notes:



Java EE Security and Web Services

Java EE Security Overview and Web ServicesHTTPS

WS-Security (WSS)


Notes:



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

resourcesData 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


Notes:



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 rolesData 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


Notes:



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


Notes:



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


Notes:



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)

application serverBrowser

Web EJB

Security context

1. Get protected resource2. Request credentials

3. Supply credentials4. Response + token

5. Request + token

Web tier security provides a number of ways for the client to authenticate

– Basic, form-based, digest, etc.


Notes:



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]


Notes:



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



<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


Notes:



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


Notes:



Security Constraints - Deployment Descriptor

<web-app><display-name>JavaTunes</display-name>

<security-constraint>





<web-resource-collection>

<web-resource-name>Study</web-resource-name>

<url-pattern>/*</url-pattern>

<http-method>POST</http-method>

</web-resource-collection>

<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

webresourcecollection matches any URL


Notes:



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>


Notes:



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

– http://www.faqs.org/rfcs/rfc2617.html

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


Notes:



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 clientBindingProvider 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


Notes:



Lab 10.1 – Using Basic Authentication

Lab 10.1 – Basic Authentication

Notes:




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\Lab10.1

Approximate Time: 30-45 minutes

Lab


Notes:



Create a Project

Tasks to PerformCreate a Dynamic Web Project*– Right click in Project Explorer, and select New | Dynamic Web Project– Call the project Lab10.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 Lab08.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

Lab

The root lab directory where you will do all your work is: C:\StudentWork\JWS\workspace\Lab10.1– This is a new lab directory containing skeleton code for the lab

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


Notes:



Add Authentication Elements

Tasks to PerformOpen 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 JBossAdminsecurity role

– Go to the <security-constraint> element, and finish its <webresourcecollection>, so that all POST requests are protected by the constraint• Finish its <auth-constraint> so only users in the JBossAdmin role will be

allowed accessOpen WEB-INF/jboss-web.xml, for editing– Set the <security-domain> element to be:java:/jaas/jmxconsole• 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

Lab


Notes:



Invoke on the Service

Tasks to PerformGo to the Servers view, by right clicking on the JBoss server, and select Add and Remove Projects …– Select the Lab10.1 project and Add it to the server *– Right click on the server and select Publish

Go back to your Lab02.3 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 authenticationIn 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

Lab

STOP


Notes:



HTTPS


WS-Security (WSS)


Notes:



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:


Notes:



HTTPS / SSL Meets Some Security Needs

Authentication – A peer's identity can be authenticated using asymmetric or public key cryptographyData Privacy – All data is encrypted after an initial handshake to define a secret keyData Integrity – Message transport includes a message integrity check Authorization – Still needs to be done programmaticallySSL is transport level security - It has limitations– All or nothing; you either see the whole message, or not– Only as secure as the weakest link

• What if the message needs to be processed by an intermediary that doesn't support the security mechanism

– Doesn't protect against some attacks


Notes:



SSL Pros / Cons

Pros:– Offers transport layer security– Widely available, Been around for a long time– Well supported - you can be confident all clients can implement it

• Relatively simple, and most people familiar with it• Already present in all major Web/Application servers

Cons:– Only effective for communication a single point to another

• Going from A to B is fine, what if you need to go from A to C via B?– Performance issues - There is overhead

• Java SSL implementation is relatively slow, Apache SSL is faster– All or nothing approach - Encrypts all communication

• Even if some of it is not sensitive– No security once message arrives at destination

• Once the message gets to its destination, it is all in clear text again– Risks during transport are not the only ones that exist


Notes:



SSL Requires Server Setup

The following are needed to support TLS/SSL on the server– A public/private key pair for encryption– A certificate which is a digitally signed statement stating that a

public has a certain value (may be signed by the public key owner, or verified by a third party - a Certificate Authority or CA)

– A keystore - which is a database holding public/private key entries and certificate entries• Key entries: Generally a private key accompanied by a certificate

chain for the corresponding public key• Trusted certificate entries: Contains a single public key certificate

belonging to another party

To support TLS/SSL/HTTPS on JBoss AS, you must set up a keystore with a public/private key pair– The setup is a bit obscure, but not really that difficult– We'll show it in the lab

A certificate is a digitally signed statement from one entity (person, company, etc.), saying that

the public key (and some other information) of some other entity has a particular value

– When data is digitally signed, the signature can be verified to check the data integrity and

authenticity

– Integrity means that the data has not been modified or tampered with, and authenticity

means the data indeed comes from whoever claims to have created and signed it

[Sun keytool reference page]

Trusted certificate entries are called "trusted" because the keystore owner trusts that the public

key in the certificate indeed belongs to the identity identified by the "subject" (owner) of the

certificate

– The issuer of the certificate vouches for this, by signing the certificate

– In general, organizations get certificates that are signed by trusted third parties (e.g.

Verisign) who verify the company information in various ways

– It is also possible to "self sign" a certificate - though then you need to convince someone

receiving the certificate to trust you (e.g. have them accept it when their browser asks)

Clients may also require setup; if the client is a browser, it generally has TLS/SSL support built

in, but if the client is a Java client, then setup is similar to the server side


Notes:



Requiring HTTPS on a POJO Web Service

Even though we've enabled HTTPS on the server, our Web service will be accessible by regular HTTP unless we configure them otherwise– You can do this in by requiring that the data be kept CONFIDENTIAL in a <transport-guarantee>, as shown below

– This will force the use of HTTPS - even if a client tries to browse the app via HTTP, they will be redirected to the HTTPS URL

– Servers that support WS-Policy, might set HTTPS by using a policy file

<security-constraint>





<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>


Notes:



Invoking a Web Service with HTTPS

To invoke on a Web service that uses HTTPS, you need to do some client setup also– You need to set up a keystore for the client– You need to export a certificate for the client from the server

keystore, and import it into the client keystore– You need to make sure that the client invokes the Web service

using https (see note)

The Java keytool program can handle all the setup for the keystores and certificates, on both the client and server side– We'll explain how to do all of it in the lab

When you set the transport guarantee, one would expect that the generated WSDL should use

https in the <soap:address> element in the <service>


Notes:



[Optional] Lab 10.2 – Using HTTPS

Lab 10.2 – Using HTTPS

Notes:



Lab 10.2 – Enabling HTTPS

Overview: In this lab, we'll set up JBoss AS to use HTTPS, require our Web service to use HTTPS, and set up the client– We'll use the keytool program to create the keystore– We'll configure an HTTPS connector that uses the keystore– We'll require HTTPS in the web.xml file– We'll set up a keystore for the client, and configure the client

NOTE: The server & client setup that takes a bit of time - you may want to skip this lab if you are short on timeObjectives: – Configure HTTPS in JBoss AS– Configure our Web service and client to use HTTP

Builds on previous labs: 10.1Approximate Time: 45-60 minutesNote: The next few slides just review keytool & JBoss HTTPS

Lab


Notes:



The keytool Program

The Java keytool program, bundled with the Java JDK provides facilities for creating and managing a keystore– It allows users to create and administer their own public/private

key pairs and certificates – As well as store the certificates of their communicating peers

keytool stores the keys and certificates in a keystore– The default keystore implementation is a file, with a default name

of .keystore in your home directory– Private keys are protected by password– All entries are identified by an alias– It supports X.509 certificates (only)

keytool has a lot of capability and configurability– We will only go into the details that are relevant to us here– See Sun's documentation on keytool for more information

Lab

keytool is a key and certificate management utility. It enables users to administer their own

public/private key pairs and associated certificates for use in self-authentication (where the user

authenticates himself/herself to other users/services) or data integrity and authentication

services, using digital signatures. It also allows users to cache the public keys (in the form of

certificates) of their communicating peers

Public keys are numbers associated with a particular entity, and are intended to be known to

everyone who needs to have trusted interactions with that entity. Public keys are used to verify

signatures

Private keys are numbers, each of which is supposed to be known only to the particular entity

whose private key it is (that is, it's supposed to be kept secret). Private and public keys exist in

pairs in all public key cryptography systems (also referred to as "public key crypto systems"). In

a typical public key crypto system, such as DSA, a private key corresponds to exactly one

public key. Private keys are used to compute signatures.

[Sun keytool reference page]


Notes:



Using the keytool Program

Some options and commands for the keytool program include:

– -keystore keystore_location: The keystore file location– storepass storepass: Password for the entire keystore– -genkey: Generate public/private key pair, & wrap in a X.509 self

signed cert stored as a single element cert chain. Options include:• -alias alias: Identity of the new key pair• -keyalg keyalg: Algorithm for generating key pair (DSA or RSA)• -keypass keypass: Password for the generated private key• -validity valDays: Number of days certificate is valid• Note - if the -genkey command is used, and the keystore file specified does

not exist, it will be created– -list {-alias alias}: List the contents of the given keystore entry,

or of the entire keystore if no alias provided– -export {-alias alias} {-file cert_file}: Export an entry,

store in a file

Lab

The -keystore and -storepass options can be used with most commands

Below are the defaults for various option values

– -alias "mykey"

– -keyalg "DSA"

– -keysize 1024

– -validity 90

– -keystore the file named .keystore in the user's home directoryThe RSA algorithm should be preferred as a secure algorithm, and this also ensures general

compatibility with other servers and components.

For more details on keytool, you can check out:

– http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/keytool.html


Notes:



keytool Examples

The command below creates a new key pair, and also creates the keystore file myconfig.keystore, if it doesn't exist *– Note: the command should be typed on one line– The screen shot at bottom shows how keytool prompts you for other

information to use in creating the key pairkeytool -genkey -alias ssl -keyalg RSA

-keystore myconfig.keystore -validity 3650

Lab

Note that we have given the ssl key the same password as the keystore file

– We are doing this because it is required by the way Tomcat configuration is structured


Notes:



Enabling Tomcat HTTPS

HTTPS is configured in the Web container server.xml file– There is an HTTPS connector configuration present that is

commented out - you just need to uncomment and finish it (note -it requires a server reboot to take affect)

Note the attributes in the example below (see notes)– SSLEnabled: Enables SSL for this connector– scheme: Value to be returned by request.Scheme()– secure: Value to be returned by request.isSecure()– keystoreFile: Location of keystore (note use of system prop)– keystorePass: The password for the keystore (and the key *)– sslProtocol: The encryption/decryption protocol to be used

<Connector protocol="HTTP/1.1" SSLEnabled="true"port="8443" address="${jboss.bind.address}" scheme="https" secure="true" clientAuth="false"keystoreFile="${jboss.server.home.dir}/conf/myconfig.keystore"keystorePass="password" sslProtocol="TLS" />

Lab

For more details on this configuration, you can check out:

– http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

– The attributes in this element may be slightly different for JBoss 4 – e.g.

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"

maxThreads="150" scheme="https" secure="true"

keystoreFile="${jboss.server.home.dir}/conf/myconfig.keystore"

keystorePass="password" clientAuth="false" sslProtocol="TLS" />

Note: This Connector element allows only one password (the password for the whole keystore)

– This means that the ssl key pair must have the same password as the keystore - otherwise the

initialization of this connector will fail

Note that you can also configure the normal connector attributes

– For example, for JBoss 4 attributes like minSpareThreads, maxSpareThreads, etc.

Tomcat currently operates only on JKS, PKCS11 or PKCS12 format keystores. The JKS format

is Java's standard "Java KeyStore" format, and is the format created by the keytool command-

line utility. This tool is included in the JDK. The PKCS12 format is an internet standard, and can

be manipulated via (among other things) OpenSSL and Microsoft's Key-Manager.


Notes:



Create a Keystore

Tasks to PerformOpen a command prompt in the JBoss server default\conf directory, and run the keytool program as follows: *keytool -genkey -alias ssl -keyalg RSA

-keystore myconfig.keystore -validity 3650

– In the prompt that follows, set the keystore password to password– Set the user/org info values to whatever you want at the prompts– For the key password for <ssl> enter RETURN so it is set to the same as

the keystore password (required for Tomcat)List the contents of the keystore using the command:keytool -list -keystore myconfig.keystore

Lab

The keytool commands should all be on one line

– We break it up in the slide due to space limitations


Notes:



Configure the HTTPS Connector

Tasks to PerformCopy the JBoss server.xml file to server.xml.ORIG

– For JBoss 5 in: default\delpoy\jbossweb.sar

Open server.xml for editing, and look for the connector element for SSL on port 8443

– Uncomment it, set the keystore file and password as shown below, and save the file

keystoreFile="${jboss.server.home.dir}/conf/myconfig.keystore" keystorePass="password"

Restart the server so changes take affect (Right click | Restart)

To test HTTPS, access the JMX-Console via HTTPS at:https://localhost:8443/jmx-console– When prompted by the browser, accept the certificate (see notes)– You should be able to view the page through HTTPS

Lab

You can't hot redeploy the Web container - it is too core to the operation of the server

– Theoretically, you could touch the jboss-service.xml file of the jboss-web.deployer, but this

leads to a whole series of exceptions in the server

– You need to reboot the whole server for these changes to take affect

You are prompted about the certificate because it is not verified by a recognized CA

– Different browsers do this differently – just agree to everything, say you understand all the

risks if prompted, etc.

You can have your certificate verified by a recognized authority, and then the user will not be

prompted

– How to do that is beyond the scope of the course - see the documentation previously

referenced for more information


Notes:



Configure Service to Require HTTPS Lab

Tasks to PerformIn your Lab10.1 project, open WEB-INF\web.xml– Look for the closing </security-constraint> tag, and add

the elements shown at bottom directly above it– This CONFIDENTIAL requirement will require that clients to the

Web service use HTTPSPublish the service to the serverRun your Lab02.3 client again– It should fail now, because the client is still using HTTP to access

the service - which now requires HTTPS



<user-data-constraint>

<transport-guarantee>CONFIDENTIAL</transport-guarantee>

</user-data-constraint>

</security-constraint>


Notes:



Create Client Keystore Lab

Tasks to PerformOpen a command prompt in the default\conf directory again, and run the keytool program as follows to export the certificate *:keytool -export -alias ssl -file ssl.cer

-keystore myconfig.keystore

– Use a keystore password of password– Move the cert file (ssl.cer) to the Lab02.3 directory

Open a command prompt in the Lab02.3 directory, and run keytool as follows to create the client keystorekeytool -import -alias ssl -file ssl.cer

-keystore client.keystore

– Set the keystore password to password– Answer yes if asked to trust the certificate– You've now created the keystore, but still need to set up the client to

use both the keystore and HTTPS

The keytool commands should all be on one line

By creating the client's keystore, and putting the cert from the server in

it, we can set the client up so it trusts the server

– All we need to do is tell the client to use the keystore

– When it tries to set up an SSL connection with the server, it will

find the server's certificate in its keystore, and be able to set up the

connection successfully


Notes:



Configure Client Lab

Tasks to PerformGo back to your Lab02.3 project, and open JavaTunesCatalogClient.java for editing– In the main method, add an additional property to the request context to

specify that the client should connect via HTTPS *requestCtx.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "https://localhost:8443/javacatalog/searchService");

You still need to configure the client to use the keystore– This is done with two system properties passed to the JVM– javax.net.ssl.trustStore: keystore file– javax.net.ssl.trustStorePassword: keystore password– Additionally we need a third JBoss specific property *– We'll add these in the Run Configuration for the client

The WSDL generated by JBoss still provides an endpoint address that uses http

– Even if you have specified that the service requires HTTPS

– It's not clear from the documentation how to change this

The JBoss specific system property for running the client is:

-Dorg.jboss.security.ignoreHttpsHost=true

– Setting it prevents an error that we've seen occur where JBoss checks the validity of the Web

service URL, and thinks that some kind of spoof attack is occurring, which ends up throwing

an exception in the client


Notes:



Configure the HTTPS Connector

Tasks to PerformFor JBoss 5, do the following– Open the Run configuration for JavaTunesCatalogClient in the Lab02.3

project (Run Icon Arrow | Run Configurations)– In the Arguments tab, add the following VM arguments (should all be on

one line – don't enter any newlines)-Djavax.net.ssl.trustStore=client.keystore

-Djavax.net.ssl.trustStorePassword=password -Dorg.jboss.security.ignoreHttpsHost=true

Run the client again as you did before– It should run now - your client is specifying the use of HTTPS, and it is

set up with a keystore that has the server's certificate– This should enable the client to make an invocation over SSL– It's a bit of work to set up, but once you've done it once,

it's much easier to do it again

Lab

STOP


Notes:



WS-Security (WSS)


WS-Security (WSS)


Notes:



Message Level Security

Provides security in the SOAP message itself– One of the core security mechanisms – we'll review this first,

then look at other capabilities at a very high level– Independent of protocol transport – HTTP, SMTP, etc– Flexible - can digitally sign or encrypt portions of a message– Not dependent on capability of intermediaries– XML Signature and XML Encryption define how this is done

XML Signature (XMLDSIG): Standard for attaching digital signatures to XML documents– Supports Data Integrity and Authentication

XML Encryption (XMLENC): Standard for convert plain text message into unintelligible binary data– Supports Data Confidentiality


Notes:



XML Signature

Goals: Ensure integrity of XML messages, identify message sender, ensure non-repudiation (can't refute a signature)– Defines how to compute, store and verify the digital signature of entire

XML documents or parts of documents– Can be applied to a portion of a document:

• Allows multiple parties that interface with a particular document to sign (and by doing so claim responsibility for) a portion of a larger document

– Doesn't verify that unauthorized parties haven't viewed a document

SSL provides some confidentiality during transport of message– SSL doesn't actually ensure integrity and privacy of a message from the

moment it is created to the moment it is processed• Doesn't provide for different levels of protection• Doesn't provide protection after message is received• For this, must combine digital signatures with physical encryption of data

The signature key itself has been issued by a trusted party (the service provider or a trusted third

party) that has most likely taken one or more measures to verify the identity prior to issuing a

signature key.

Non-repudiation is the concept of ensuring that a party in a dispute cannot repudiate, or refute the

validity of a statement or contract

– Although this concept can be applied to any transmission, including television and radio, by

far the most common application is in the verification and trust of signatures


Notes:

XML Signature Structure

Before a digital signature is created, XML documents are canonicalized using an XML

canonicalization transform

– This ensures that XML documents that are logically equivalent produce the same digital

signature

– Even if they have differences such as whitespace, or different line terminators

XML signatures are typically used to sign XML documents accessible via a URL

– An XML signature used to sign a resource outside its containing XML document is called a

detached signature– If it is used to sign some part of its containing document, it is called an enveloped signature– If it contains the signed data within itself it is called an enveloping signature


SOA and Web Services with Java Session 10: Security

Notes:

XML Signature Mechanisms

Reference Generation: Sender retrieves the resource, applies any transforms, and then the specified digest method– Store the result in the <DigestValue>– This is done for each Reference

Reference Validation: Receiver retrieves the resource, applies any transforms, and then the specified digest method– Compare the result to the <DigestValue>– If they do not match, validation fails – i.e. the content was altered

Signature Generation: Sender calculates the digest of <SignedInfo>, and enciphers it with their private key– The value is stored in <SignatureValue>

Signature Validation: Receiver calculates the digest of <SignedInfo>, and deciphers the <SignatureValue> with senders public key– If they match, you can be assured sender actually sent the document

Reference generation and validation makes use of a cryptographic hash function (e.g. SHA –

Secure Hash Algorithm)

– A cryptographic hash function takes an arbitrary block of data and returns a fixed-size bit

string which is variously named the (cryptographic) hash value, the message digest, or

simply digest– Any change in the data, whether accidental or intentional, will change the generated digest

– By comparing the digest generated before the message is transmitted (which is included in

the message) to that generated when it is received can show whether any changes have been

made to the message



Notes:



XML Signature Sample

<soapenv:Envelope><soapenv:Header>

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">

<wsse:BinarySecurityToken EncodingType="wsse:Base64Binary"> MIIDQTCCAqqgAwIBAgICAQQwDQYJKoZIhvcNAQEFBQAwTjELMAkGA1UEB... [remaining binary data has been truncated]

</wsse:BinarySecurityToken>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo> <CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/><Reference URI="#wssecurity_body_id_2601212934311668096_1040651106378">

<Transforms> <Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>AWQKpmksMpzzT4PxcizO980gVHw=</DigestValue>

</Reference> </SignedInfo>


Notes:



XML Signature Sample

<SignatureValue> bNhTM1+Dzu5bXsdFNN9PR1J6LhLSMh0JzPzuQpkO/MaOn3oN0gRMK1i7RaBGH61Zp0... [remaining binary data has been truncated]

</SignatureValue>

<KeyInfo> <wsse:SecurityTokenReference> < wsse:Reference URI="#wssecurity_binary_security_token_id_1603091_4272645"/>

</wsse:SecurityTokenReference> </KeyInfo>

</Signature>

</wsse:Security>

</soapenv:Header> <soapenv:Body xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/07/utility"> <rentDVD xmlns="http://lpc.dvdonline.secure.service"> <in0 xmlns="">Wallace and Grommit</in0>

</rentDVD> </soapenv:Body>

</soapenv:Envelope>


Notes:



XML Encryption

Goal: Ensure confidentiality of XML message– Ensures that even if someone gained access to the message

payload, they'd be unable to view the actual message/documentEncrypts elements in the XML message– Maintains proper XML syntax

Provides for:– End-to-end security– Full / partial encryption– Flexible: Can encrypt different elements differently

• Different users can then access only those parts they needComplimentary with XML Signature, which ensures integrity and identity– Encrypt data using XMLENC, then sign with XMLDSIG to prevent

tampering


Notes:

XML Encryption Structure

Many of the elements are optional– At its simplest, you can have just EncryptedData and

CipherData/CpherValue elements

<EncryptedData Id? Type? MimeType? Encoding?><CipherData>

<CipherValue>? <CipherReference URI?>? 

</CipherData><KeyInfo> 

<EncryptedKey><AgreementMethod><ds:*>

</KeyInfo><EncryptionMethod/> <EncryptionProperties> 

</EncryptedData>



Notes:

XML Encryption Mechanisms

Encryption: – Choose an algorithm– Choose a key and how it's represented– Encrypt the XML, and store the base-64 encoded result in

<CipherData>– Build <EncyptedData> with info needed to decrypt

Decryption:– Determine algorithm and key– Decode the base-64 encoded <CipherData> and decrypt– Substitute the original <EncryptedData> with the decrypted XML



Notes:

XML Encryption Example

In the example below, we show a simple XML document, and how a single element might look in encrypted form

<?xml version='1.0'?><PaymentInfo xmlns='http://example.org/paymentv2'><Name>John Smith</Name><CreditCard Limit='5,000' Currency='USD'><Number>4019 2445 0277 5567</Number><Expiration>04/02</Expiration>

</CreditCard></PaymentInfo>

<?xml version='1.0'?><PaymentInfo xmlns='http://example.org/paymentv2'><Name>John Smith</Name><EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'

xmlns='http://www.w3.org/2001/04/xmlenc#'><CipherData><CipherValue>A23B45C56</CipherValue>

</CipherData></EncryptedData>

</PaymentInfo>

If all the elements were encrypted, then the document might look like the below

<?xml version='1.0'?>

<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'

MimeType='text/xml'>

<CipherData>

<CipherValue>A23B45C56</CipherValue>

</CipherData>

</EncryptedData>



Notes:



Web Services Security Overview

Web services security was laid out originally by IBM and Microsoft

– Composed of a whole suite of specifications covering various facets of security - Messaging,

policies, trust, privacy, etc.

Specifications build upon one another

– All built on top of a single specification, WS-Security

– WS-Security defines a message security mode

There has been much evolution since then, such as the addition of technologies like SAML

The roadmap is a dynamic model for security currently consisting of seven specifications


Notes:



Web Services Security Overview

WS-Security: Secures SOAP message (via Security tokens (Certificates, Kerberos tickets), Signatures, Encryption, etc)WS-SecurityPolicy: Enables describing what security features are supported or needed by a Web ServiceWS-Trust and WS-Federation: Describes model for establishing trust relationships (direct and indirect) allowing federation of multiple security domainsSAML (Security Assertion Markup Language): Enables interoperable exchange of security data (authentication/authorization)XACML (eXtensible Access Control Markup Language): Access control markup language and processingXKMS (XML Key Management Specification): Distribution and registration of public keys


Notes:



Web Services Security Stack


Notes:

Using the Security Mechanisms

To use the security mechanisms, you need to do the following– Define a policy file which specifies the security policy (usually

done using an XML config file conforming to the WS-SecurityPolicy specification• Most vendors include basic policy files which defines common

policies – for example "All message body parts are encrypted."– Configure security for your services (done in a vendor-dependent

way – e.g. with proprietary annotations)– Configure the server to support the policies (done through the

servers admin tools)

The details of this are complex, time consuming, and beyond the scope of this course