| Article found | Fact |
|---|
|
Secure, Reliable, Transacted Web Services [FS03]
|
- A Service-Oriented Architecture differs from OO and procedural systems in one key aspect: binding. Services interact based on what functions they provide and how they deliver them. OO and procedural systems link elements together based on type or name.
- When using Web services to build an SOA, the solutions consist of collections of autonomous services,
identified by URLs, with interfaces documented using WSDL, and processing well-defined XML messages
- SOA is a natural complement to the object-oriented (OO), procedural and data centric approaches to solution implementation.
- service-oriented model assumes a fully distributed environment where it is difficult, if not impossible, to propagate
changes in schema and/or contract to all parties that have encountered a service
- Service-orientation implies that contracts
and schema should remain backward compatible and may contain information that is incompletely understood by particular
processing systems.
- the contract and schema technologies designed for use in service-oriented designs enable more flexibility than traditional object-oriented interfaces. In particular, services use features such as XML element wildcards (e.g., xsd:any),
schema extensions and optional SOAP header blocks to evolve services in ways that do not break deployed applications.
These characteristics are the key to the composability of Web services.
- Procedural and Object-oriented designs typically equate type compatibility with semantic compatibility. Service-orientation provides a richer model for determining compatibility. Structural compatibility is based on contract (WSDL and optionally
BPEL4WS) and schema (XSD) and can be validated. Moreover, the advent of WS-Policy provides for additional automated analysis of the service assurance compatibility between services. This is done based on explicit assertions of capabilities and requirements in the form of WS-Policy statements.
- an SOA explicitly assumes that communication, availability, and type errors are common.
- To maintain system integrity, service-oriented designs explicitly rely on a variety of technologies to deal with asynchrony and partial failure modes. Techniques such as asynchronous messaging, transactions, reliable messaging, and redundant
deployment are the norm in a service-oriented systems.
- unlike the in-memory model, service-orientation assumes that not only that an incoming message may be
malformed, but also that it may have been transmitted for malicious or completely unexpected purposes
- service-oriented systems protect themselves by placing the burden of proof on all message senders by requiring applications to prove that the required rights have been granted to the sender
- serviceoriented architectures typically rely on administratively managed trust relationships to avoid per-service authentication mechanisms common in classic web applications.
- One of the core concepts of service-oriented architecture (SOA) is flexible binding of services. More traditional procedural, component and object models bind components together through references (pointers) or names. An SOA supports more
dynamic discovery of service instances that provides the interface, semantics and service assurances that the requestor
expects.
- In procedural or object-oriented systems, a caller typically finds a server based on the types it exports or a shared name space. In an SOA system, callers can search registries such as UDDI for a service.
- That is message compatible with the caller's requirements. Compatibility can occur through WSDL or matching messages from well-known XML Schemas.
- That documents support for service assurances that the caller requires. For example, the caller may desire certain approaches to security or transactions.
- The loose binding with respect to the implementation of the service that enables alternative implementations of behavior can be used to address a range of business requirements. For example, the alternative implementations might correspond to
alternative vendors in a supply chain enabling more rapid response to changing market conditions. Similarly the alternative implementation might be geographically distributed data centers enabling disaster tolerance.
|
