Thy web services architecture is an interoperability architecture defined as a software system designed to support interoperable machine-to-machine interactions over a network. Its interface is described in a machine-processable format (WSDL). When interacting with web services, other systems utilize SOAP, typically through HTTP with XML structured messages. It consists of loosely coupled, reusable components and separates a capability from its user interface.
Web services are intended to be accesses by other applications or web services in other autonomous systems. The service may consist of everything from simple operations like checking bank account balances online to complex business processes running enterprise resource planning systems. Because of the fact that web services are based on open standards like HTTP, XML, SOAP and WSDL they are implicitly hardware, platform and programming language independent.
Simple Object Access Protocol (SOAP)
SOAP is a standard packaging structure for XML-documents over a variety of protocols (e.g. SMTP, HTTP, FTP). It may be used for RPC in client-server applications, but is also suitable for messaging systems that follow one-to-many models. Must attach it to a transport mechanism (like HTTP). Contains a header with system info and a body with the actual XML-document.
Web Service Description Language (WSDL)
WSDL is an XML technology describing the interface of web services in a standard way. It defines what your service does and how it is invoked.
Universal Description, Discover, and Integration (UDDI)
UDDI is a worldwide registry for managing information about web services. There are three components of business registering:
- · White pages: information about the business providing the service: name, description, contact info etc.
- · Yellow pages: Classification of the service or business based on standard taxonomies.
- · Green pages: Technical information about services exposed by the business. Describes how to access the web service.
Programmers perform service type registration.
- · The technical description of the web services represented by the business service structure.
- · A way of describing the various business, service and template structure stored within the UDDI registry.
Business Process Execution Language (BPEL)
Describes a workflow that represents interaction between Web Services. It also describes the logic of a web service, like how it is implemented and how it communicates with others.
Provides transactional characteristics for web services.
WS-AtomicTransaction is a coordination type that implements transactional atomicity using two-phase commit. It is intended for tightly-coupled (systems need to have specific details about other systems, or about the middleware itself), short-lived activities within a single organizational structure.
WS-BuisnessActivity is a coordination type that is intedened for loosely-coupled (don't need explicit knowledge of details behind particular nodes), long-lived activities that span autonomous Web-services.
WS-Coordination defines a generic framework for applications to identify related operations across web services. In other words, it provides transactional characteristics for web services. The current goal of coordination is to support termination.
Elements of the coordination architectureEdit
- Activation (Part of WS-Coordination): Creates a new activity with a particular coordination type (Atomic Transaction or Business Activity) and returns a context containing an identifier that uniquely distinguishes a particular work scope.
- Context: The context that is returned at activation is passed along with the web services operations and used to identify the operations contained within the currrent active scope
- Registration (part of WS-Coordination): Allow each participant to register for a protocol within the type (different participants of the same activity might use different protocols)
- Protocol: Supports the execution of the protocol as specified in WS-AtomicTransaction or WS-BusinessActivity to provide the logic to complete a specific transaction model.
Context is a container for sharing processing information between web services. It consists of the following:
- An identifier, which is a uniform resource identifier (URI) that identifies the related groups of messages
- An Expires-value, which is the timeout value for the activity
- The Coordination type
- Registration service: The address of the registration service.
Protocols for Atomic Transactions (WS-AtomicTransaction)Edit
The protocols for atomic transactions typically handle activities that are short lived. Atomic transactions are provided through a two-phase commitment protocol. The transaction scope states that all work is either successfully completed in its entirety, or not at all. This means that if an activity is successful, all changes are made permanent. Alternatively, if the activity fails to complete successfully, none of the changes are made permanent.
Protocols for Business Transactions (WS-BusinessActivity)Edit
The protocols for business transactions handle long-lived activities. These differ from atomic transactions in that they take much longer to complete. Also, to minimize latency of access by other users to the resources, the result of interim operations need to become visible to others before the overall activity is completed. Because of this, mechanisms for fault and compensation handling are introduced (such as compensation and reconciliation) to reverse the effects of tasks previously completed within a business activity.
The protocols can be used in combination. For example short-running atomic transactions can be part of a long-running business activity. The actions of the embedded atomic transactions might be committed and made visible before the long-running business activity completes.