service interface design rsvz / inasti 12 july · pdf filetake into account performance &...
TRANSCRIPT
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
> Federal Service Bus
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?
Agenda> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus
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
> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus
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.
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
Agenda> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus
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.
Agenda> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus
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
> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus
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
Agenda> Mandatory standards>Web Service Styles and Usages> Service interface design> Service versioning> Securing Web Services
> Lessons learned
> Federal Service Bus