Core mechanisms for Web Services extensions

Core mechanisms for Web Services extensions

Miguel [email protected]

Seoul, October 30th, 2007

2007

Next Generation

Web Services Practices

Lisbon,

Portugal

2007-10-30 Core mechanisms for Web Services extensions 2

Outline

• Service-oriented Enterprise Applications• Web Service Extensions

– Core mechanisms• Conclusions


Outline




“The whole world is made of change” ~ Luís Vaz de Camões

16th CenturyPortuguese Poet

Fortran

C

Dot Net

Java

Cobol

CORBA

DCOM

DCE

Web Services


Service-oriented approach to Enterprise Applications

• Customers’ needs change– Enterprises must adapt– And so do their applications

• Services– Focus on flexibility, reuse and interoperability– Web Services (WS) technology– Service-Oriented Architecture (SOA)


Web Services in action

librariesWS

Client

#3 Generate

#4 Configure

#5 Invoke

#6 Execute

#1 Publish

#2 Discover

stubsWS

DataXML Schema

PolicyWS-Policy

FunctionsWSDL

Service


Web Services libraries

• WS-Policy specifies additional requirements– Like security, distributed transactions, reliable

messaging, etc.– But libraries are necessary to actually

implement the requirements

librariesWS

#4 Configure PolicyWS-Policy


Requirements

• Functional– What the service does

• Input, output, faults

• Non-functional– What properties hold when the service executes– Depend on circumstances and must be balanced

• E.g. Security– Low value messages can use a weaker but faster cipher

algorithm; high value messages use stronger security– Intranet requests use local security credentials; Internet

requests use cross-domain credentials


Outline




WS standards for every requirement“Are we there yet?”

Short answer:

No, but we’re moving forward

Long answer:

Visit WS-Map ☺(or another overview site…)

http://web.ist.utl.pt/miguel.pardal/ws-map


Why go beyond the standards?

• “One size does not fit all”

• Vendor WS implementations– From Microsoft, IBM, Sun, Oracle, …– Good library implementations of complex WS standards– Solve 90% of the problem but are difficult to customize to

specific needs

• WS Extensions– Simpler library development– Appeal to a much broader developer community– Handle the remaining 10%...


Analogy:Mozilla Firefox extensions

• Firefox implements 90% of requirements– Extensions add value to users, meeting specific needs

and improving the browsing experience


Example extension:Security report

• Some applications prefer not to know about security, they just want it– But others need to know, for instance, to store audit information

in a database

• Security report extension– A report is produced during WS-Security processing

• All actions and all parameters described• In a simple, easy-to-use object model

– Leverage WS-Security standard implementation– Enables context sharing through meaningful abstractions,

delegating security decisions in a simple and effective way


Problem statement

• What are the core mechanisms required for developing Web Services extensions ?– Like “security report”


Proposed core mechanisms

Packages and dependencies

• Policy

• Configuration

• Contexts management

• Message flow interception

• Operation implementation interception


Policy

• Requirements declaration– e.g. Declare that a WS can be invoked with transport

security or with message security• Policy negotiation between client and server


Configuration

• Parameters– Which extensions to engage?– What are the parameter values?

• e.g. Which digital certificate to use?


Contextsmanagement

• Scoped state variables– Application– Session– Operation– Thread

• Enable data sharing between extensions and service implementation


Message flowinterception

• Message handling at service endpoint– Incoming or outgoing– Read/write header and body of SOAP messages

• e.g. Do digital signature of body and place it in header


Operationimplementationinterception

• Execute additional code before or after the service implementation– e.g. Implement authorization and access logging

• Object factories can return different implementations according to the desired behavior


Proof-of-concept

• All mechanisms implemented on Java Web Services– Apache Commons Policy 1.0

• Policy– JAX-WS Handlers

• Message interception– Custom coding

• Configuration, Contexts and Operation Execution

• Field-tested on a prototype and several course projects:– Security and distributed transactions extensions– Multiple development teams– Significant improvements in ease of development and learning


Outline




Conclusions• Web Services development

– Functional requirements are satisfied with components– Non-functional requirements are satisfied with aspects that

can differ according to invocation circumstances

• Web Services extensions– Simplify custom library development– Broaden developer community

• Future work:– Enterprise application framework

• Local and remote services• Integrated extensions engine

– Platform-independent extensions: Java and Dot Net


ObrigadoThank you

[email protected]

With extensions, more developers can try new ideas.

This encourages competition and best-of-breed selections, that can further advance the state-of-the-art of Web Services technology

Questions &Answers

Looking ahead…

Core mechanisms for Web Services extensions

Technology

web services libraries

web services extensions8

web services extensions10

web services extensions15

core mechanisms requiredfor

requirements extensions

applications services

wssecurity processing