Planning_and_Impleme.. - didier beck weblog

www.butlergroup.com
Planning and Implementing SOA
The most important consideration currently is the existence of the Web Services Interoperability Basic
Profile. This defines a mechanism for interoperability for the core standards used in Web services
implementations, and covers SOAP, WSDL, and UDDI as well as some lower-level standards and protocols.
The Basic Profile version 1.0 is not fully compatible with version 1.1 – guidance here is that usage of the
standard should be at the same level to ensure interoperability.
The Web services security (WS-Security) specification that has been developed and ratified by OASIS
provides security for SOAP messages in transit, and can be regarded as an extension to SOAP. Originally
developed by IBM, Microsoft, and Verisign, where messages need to pass across an untrusted intermediary
structure, standards such as WS-Security provide a degree of trust, covering authenticity, integrity, and
confidentiality of messages. Security can be applied at transport level (for example Secure Sockets Layer
(SSL) secures the HTTP layer on which various requests and responses are transmitted). However, where
a message is sent via an intermediary, the transport layer no longer has control over the message when it
is at the intermediary, and therefore it may also be necessary to implement message-level security – like
keeping a message within a sealed, tamper-evident envelope.
The WS-Security standard is already reasonably mature – version 1.0 was approved by OASIS in April
2004, and version 1.1 was approved in February 2006.
The WS-Security family specifications cover the use of various different tokens, such as Kerberos, X.509,
and SAML. An example of a signed security token is an X.509 certificate; this asserts a binding between
the requester’s identity and a public key. Security tokens like this can be carried in a message, or expressed
by a reference so that the receiving service can ‘pull’ the claim from the relevant authority. To ensure
interoperability, adapters and common algorithms for signatures and encryption will need to be agreed
upon.
The WS-Security model is extensible, and allows a service to specify the type and degree of security
required. The WS-Interoperability Basic Profile includes Security.
Web services gateways, message brokers, and ESBs may provide the trust required themselves, and
services that interrelate only within an ESB may not need to consider security. However, if they are to be
exposed beyond this, then security will be needed.
RUN-TIME OPTIONS FOR SOA
CATALYST
When most people think of SOA they automatically assume that Web services will be the way that services
interact, and have concerns about the efficiency of such deployments. However, a SOA can have a number
of deployment alternatives which can help get around some, but not all, of the performance issues.
SUMMARY
There is a trade-off possible between performance and long-term agility, and this
needs consideration before committing to a course of action.
Network appliance alternatives to traditional server/software implementation can
offer cost/performance benefits.
Run-time deployment of SOA-based applications does not always mean using Web
services.
High-performance SOA need not be an oxymoron, but good understanding of issues
is needed.
December 2006 Section 1: SOA Deployment 23