Service Interface Design RSVZ / INASTI 12 July PDF Free Download

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

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 <request> <response> During a call, you have a built-in "backchannel" for replies (like HTTP) If you lose the connection, what then? <replyto> = 555-2321! RING Endpoint References allow you to give a "call-back" location in a standard way 555-2321 fred@email.com Or even "e-mail-back" 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

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 RPC Document Execute function calls Exchange documents Payload is defined by an external schema (external encoding rules) Payload (XML) is defined by and XML Schema Fine grained operations Coarse grained operations Promotes synchronous programming model Promotes Asynchronous programming model Modeled as remote procedure calls Modeled using XML Document Exchange

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: Reliability Scalability Performance Fault tolerance

Service Implementation Considerations > Implementing a Document style web service : Design an XML schema Support an existing XML schema Interpret the response message, and filter out the data required > Implementing an RPC style web service Execute a method Interpret 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 usecase. > 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 typed Has meaningful parameters Is document centric (as opposed to method centric) Conforms to WS-I Basic Profile Should 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/typ es/pcconfig/v1/1 > Date stamps Embedded in the namespace : <xsd:schema targetnamespace=http://www.acme.com/200 4/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 service Deploy the new version of the service (using WSDL/UDDI) Notify consumers of the arrival of this new version Optionally, 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

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 provides Party identification Party authentication Message integrity Message confidentiality > HTTPS doesn t provide Authorization Auditing

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 Signatures XML Encryption Security Assertion Markup Language (SAML)

Securing Web Services > Combination of Transport Level Security HTTPS Message 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 peerto-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

Federal Service Bus (FSB)