Service Interface Design RSVZ / INASTI 12 July · PDF fileTake into account performance &...

Architectural Guidelines

Service Interface Design

RSVZ / INASTI 12 July 2006

Agenda

> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services

> Lessons learned

> Federal Service Bus

Agenda> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services

> Lessons learned


Mandatory Standards

✔ WSDL✔ SOAP

✔ UDDI

✔ WS-Security

✔ WS-Addressing

Mandatory Standards : WSDL

Mandatory Standards : SOAP

Mandatory Standards : UDDI

WS-Security

Status: OASIS Technical Committee

Support:

Rating: Positive

Strengths: Many supporting vendors Underlies most WS-x

specifications

Opportunities: Complete ubiquity

Introduced: 1.0, March 2004

Current Version: 1.1, February 2006

Weaknesses: Security token formats

not all supported

Threats: None

WS-Addressing: Providing the 'Return Address' for Web Services Transactions

Allows for responses to be distributed across time (asynchronous transfer mode) Allows messages to be sent over different transports Allows dynamic composition of multiple interactions (process)

Source: Sonic Software

During a call, you have a built-in"backchannel" for replies (like HTTP)

<request>

<response>

Or even "e-mail-back"…[email protected]

<replyTo> = 555-2321

555-2321

Endpoint References allow you to give a "call-back" location in a standard way

RING!

If you lose the connection, what then?


> Lessons learned


Web Service Styles

> Choice between RPC or Document centric design

Modeled using XML Document Exchange

Modeled as remote procedure calls

Promotes Asynchronous programming model

Promotes synchronous programming model

Coarse grained operationsFine grained operations

Payload (XML) is defined by and XML Schema

Payload is defined by an external schema (external encoding rules)

Exchange documentsExecute function calls

DocumentRPC

Design with validation in mind

> Using Document style web services, you can describe and validate a high-level business document using XML.> RPC style web services only have the

method name and parameters in their payload, so no high level business rules can be enforced

Ensure Interface Compatibility

> RPC calls are considered static (changes in the method signature breaks the contract with the client)> XML schemas are more flexible (they can

change more often by adding elements without breaking the contract with it clients)

Take into account the invocation Model

> Document style web services are better suited when it comes to asynchronous processing. > The ability to do asynchronous

processing within the Service Oriented Architecture helps us to create added value when it comes to:

ReliabilityScalabilityPerformanceFault tolerance

Service Implementation Considerations

> Implementing a Document style web service :

Design an XML schemaSupport an existing XML schemaInterpret the response message , and filter out the data required

> Implementing an RPC style web serviceExecute a methodInterpret the result

Statefullness of services

> Document style web service are far better suited then RPC style. > Very difficult to implement this using RPC > Documents on the other had can carry

the state around far more easily

Interoperability

> In order to guarantee interoperability between the various components in the architecture, web service design should take into account the WSI Basic Profile > The WSI Basic Profile allows for both

RPC and Document style web service to be used within the architecture.

Web Service Usage

2 types of web service usages :

> Encoded usage : a contract is defined up front, using an encoding scheme. (encoding rules can be found in the SOAP specification)> Literal usage : an XML Schema is

provided to define the data types.

Design with interoperability in mind

> In order to achieve interoperability, and compliance with the WSI Basic Profile specification, one should abandon the use of SOAP encoding. > The WSI Basic Profile formally forbids the

use of SOAP Encoding.

Take into account performance & scalability

> Several benchmarks have concluded that there is a performance & scalability penalty involved when working with SOAP RPC encoding> Especially when the payload of the

message increases.

Try to look ahead

> SOAP 1.2 has made SOAP encoding optional, meaning that SOAP Toolkit vendors can get certified without providing support for SOAP encoding.>WSDL 1.2 has chosen to drop support for

SOAP encoding

Choosing the right binding model

> The following WSDL binding models are available

RPC/encoded RPC/literal (*)Document/encoded Document/literal (*)

> (*) Note that the WSI-Basic Profile only allows for Document/Literal and RPC/Literal usages.

Binding model effects the service Interface

> RPC based service interfaces should be fairly static in nature, as any change in the service interface will effectively break the contract between the consumer and producer.>When using a document/literal style, the

impact of changing the service interface can be minimized.

Binding model effects validation

>When using a document centric approach, XML validation can be used to enforce certain high level business rules. > These high level business rules are

defined in XML Schema. The generated XML can be validated before invoking an operation on the service producer. > If the service depends on complex xml

structures, a document centric approach is the better choice.

Binding model effects performance

>When working with XML, we know that at some point we’ll need to perform some kind of XML parsing. This is typically considered to be an expensive operation, especially when the DOM tree reaches a certain limit.> Document style web services can take

advantage of other XML parsing techniques such as SAX to have a smaller memory footprint, and better overall performance.

Agenda


> Lessons learned


Interfaces should be strong typed

> The method below is part of a strong typed interface.

It will always return a person, It will need a Social Security Number as a parameter. Due to the fact that the social security number is strong typed, additional validation can occur on this level. Even before the request is issued, we have a level of validation (only valid social security numbers can be used as input)

public Employee getPerson(SocSecurityNumber socSecurityNumber)

Interfaces need meaningful parameters

> As the service interface is part of the public contract, it’s important that the parameters that are a part of that interface have meaningful values.> Consider the method below. By looking at

the interface, it’s clear that we can retrieve an Employee based on its social security number.

public Employee getPerson(SocSecurityNumber socSecurityNumber)

Interfaces should be document centric

> A document-centric interfaces allows a client developer to execute a single method invocation on the interface in order to return a set of data that the client requests to perform his business functions

employee = EmployeeService.getEmployee(socSecurityNumber);salary = employee.getSalary();firstName = employee.getFirstName();

Interfaces should have the right granularity

> Service interfaces should be coarse grained > Business objects typically expose very

fine grained methods> These require a lot of interaction with

the client in order to fulfil a certain use-case. > This requires us to do a lot of network

roundtrips, marshalling data back & forth, and increases the coupling between the consumer and the producer.

Fine Grained Service Interface

Coarse Grained Service Interface

Conclusion

> A good interface :Is strong typedHas meaningful parametersIs document centric (as opposed to method centric)Conforms to WS-I Basic ProfileShould have the right granularity


> Lessons learned


Service Versioning

> Service versioning is something that isn’t covered by any web service standard. > No official standard has been published

to setup a service versioning scheme> Conclusion : we have to rely on a set of

best practices in order to introduce the concept of versioning into the architecture

XML Schema Versioning options

> XML Schema Namespace element> Using XML Schema version attribute > Introducing a custom version attribute> Introduce naming conventions

XML Schema namespace

> Major version releases should be propagated in the XML Schema Namespace that is associated with the service:

targetNamespace=http://www.myfod.be/service1/reg/1.1

XML Schema namespace

> Changes made to XML Schema namespaces will break existing clients> They will be unable to marshall &

unmarshall the service messages.> This mechanism should only be

introduced in order to communicate major service releases that will break the contract between the consumer and producer.

targetNamespace=http://www.myfod.be/service1/reg/1.1

XML Schema version attribute

> The version attribute (in conjunction with the targetNameSpace attribute), can act as a version control mechanism for small, incremental changes> These changes shouldn’t break the

compatibility with the clients (adding a new operation to the WSDL for example).

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified"attributeFormDefault="unqualified"version="1.0">

Adding a custom version attribute

<xs:schema xmlns="http://www.exampleSchema" http://www.myfod.be/service1/reg/1.1 xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"><xs:element name="RootElem"><xs:complexType><xs:attribute name="Version" type="xs:decimal" use="required" fixed="1.0"/></xs:complexType></xs:element>

Introducing Naming Conventions

> Major – Minor version:embedded in the service name (getUser_v1_1)embedded in the namespace:<xsd:schema targetNamespace=http://www.acme.com/types/pcconfig/v1/1

> Date stampsEmbedded in the namespace :<xsd:schema targetNamespace=http://www.acme.com/2004/03/01/pcconfig,

Using UDDI for versioning

> The UDDI registry can also be used as a way to handle the versioning of webservices. > UDDI V3 has a Subscriber feature that

allows for the notification of clients when a new version of a particular service gets published. > Clients interested in the evolution of a

particular webservice can subscribe to this UDDI feature to get notifications.

Service Release Management

> Steps to introduce a new version of a particular service

Develop and test the new version of the serviceDeploy the new version of the service (using WSDL/UDDI)Notify consumers of the arrival of this new versionOptionally, create a pilot project with one consumer.As depicted in the release management plan, one should keep both the old and new version of the service running simultaneously for a predefined time.Allow for the consumers to upgrade their version.Gracefully remove the older version from the architecture (consumers still using the old version should get an error message indicating that the specific service version is no longer supported.


> Lessons learned


Securing Web Services

> 2 levels of security

> Transport Level Security> Message Level Security

Transport Level Security

> Web Services are dependant on an underlying transport protocol (HTTP, SMTP…). > In order to achieve some basic level of security,

it’s imperative that the transport protocol also offers some level of security.> HTTPS, or HTTP via Secure Socket Layer

(SSL) allows client side and server side authentication through the use of certificates. > It’s generally assumed that HTTPS provides an

adequate level of security on the transport level.

Transport Level Security

> HTTPS providesParty identificationParty authenticationMessage integrityMessage confidentiality

> HTTPS doesn’t provideAuthorizationAuditing

Message Level Security

> This type of security is located at the actual message level. (by embedding security information inside the XML document) > The current web services landscape

allows for the following possibilities when it comes to securing XML messages

XML Digital SignaturesXML EncryptionSecurity Assertion Markup Language (SAML)

Securing Web Services

> Combination ofTransport Level Security

HTTPSMessage Level Security

WS-Security with Binary Security Token (X509) and/or SAML token

Different policies for internal services and exposed services

Agenda


> Lessons learned


Living Happily 'Ever After SOA': The Problems You Will Discover Later

The "Find or Duplicate" Problem – Your SOA is as good as your metadata

The Version Control Problem– Without version control, prepare for "legacy SOA systems"

The Governance Problem– Who owns a transaction that spans the world?

The Integrity Problem– The best-kept secret: data matters

The low hanging fruit problem– The wrappers are not good service interfaces; the object classes are not good

services The Services as "IT Citizens" Problem

– Coexist with other software architectures (events, monolithic, batch and peer-to-peer)

The People Problem– Integration competency center is essential

Source : GARTNER


> Lessons learned


Federal Service Bus (FSB)

Service Interface Design RSVZ / INASTI 12 July · PDF fileTake into account performance &...

Documents

Transcript of Service Interface Design RSVZ / INASTI 12 July · PDF fileTake into account performance &...