WS-BPEL basics

WS-BPEL basics

PRE-REQUISITE DISCUSSION:

One can describe Web-service interactions in two ways: as executable business processes and as abstract business processes.

A executable business process: models an actual behavior of a participant in a business interaction.

An abstract business process: is a partially specified process that is not intended to be executed. Contrary to Executable Processes, an Abstract Process may hide some of the required concrete operational details. Abstract Processes serve a descriptive role, with more than one possible use case, including observable behavior and/or process template.

WS-BPEL aims to model the behavior of processes, via a language for the specification of both Executable and Abstract Business Processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. It also defines an interoperable integration model that should facilitate the expansion of automated process integration both within and between businesses. Its development came out of the notion that programming in the large and programming in the small required different types of languages.

WS-Coordination overview:

WS-Coordination is a Web Services specification developed by BEA Systems, IBM, and Microsoft and accepted by OASIS Web Services Transaction TC in its 1.2 version. It describes an extensible framework for providing protocols that coordinate the actions of distributed applications. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome of distributed transactions.

The framework defined in this specification enables an application service to create a context needed to propagate an activity to other services and to register for coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment.

Additionally WS-Coordination describes a definition of the structure of context and the requirements for propagating context between cooperating services.

However, this specification isn't enough to coordinate transactions among web services. It only provides a coordination framework, and other specifications like WS-Atomic Transaction or WS-BusinessActivity are needed for this purpose.

WS-Choreography:

Service choreography is a form of service composition[clarification needed] in which the interaction protocol between several partner services[clarification needed] is defined from a global perspective. The intuition underlying the notion of service choreography can be summarised as follows:

―Dancers dance following a global scenario without a single point of control"

That is, at run-time each participant in a service choreography executes its part of it (i.e. its role) according to the behavior of the other participants.[2] A choreography's role specifies the expected messaging behavior of the participants that will play it in terms of the sequencing and timing of the messages that they can consume and produce

Service choreography is better understood through the comparison with another paradigm of service composition: service orchestration.

On one hand, in service choreographies the logic of the message-based interactions among the participants are specified from a global perspective. In service orchestration, on the other hand, the logic is specified from the local point of view of one single participant, called the orchestrator.

In the service orchestration language BPEL, for example, the specification of the service orchestration (e.g. the BPEL process file) can be deployed on the service infrastructure (for example a BPEL execution engine like Apache ODE).

The deployment of the service orchestration specification creates the composed service.

In a sense, service choreography and orchestrations are two flips of the same coin.

On one hand, the roles of a service choreography can be extracted as service orchestrations through a process called projection.

Through projection it is possible to realize skeletons, i.e. incomplete service orchestrations that can be used as baselines to realize the web services that participate to the service choreography.

On the other hand, already existing service orchestrations may be composed in service choreographies.

WS-Policy,:

Web Service Choreography (WS-Choreography) is a specification by the W3C defining an XML-based business process modeling language that describes collaboration protocols of cooperating Web Service participants, in which services act as peers, and interactions may be long-lived and stateful. (Orchestration is another term with a very similar, but still different meaning.)

The main effort to get a choreography, The W3C Web Services Choreography Working Group, leaving WS-CDL as a Candidate Recommendation.

"Many presentations at the W3C Workshop on Web services of pointed to the need for a common interface and composition language to help address choreography. The Web Services Architecture Requirements Working Draft created by the Web Services Architecture Working Group also lists the idea of Web service choreography capabilities as a Critical Success Factor, in support of several different top-level goals for the nascent Web services architecture"

The problem of choreography was of great interest to the industry during that time efforts such as WSCL (Web Service Conversation Language) and WSCI (Web Service Choreography Interface) were submitted to W3C and were published as Technical Notes. Moreover complementary efforts were launched

WS-Policy is a specification that allows web services to use XML to advertise their policies (on security, quality of service, etc.) and for web service consumers to specify their policy requirements.

WS-Policy is a W3C recommendation as of September 2007.

WS-Policy represents a set of specifications that describe the capabilities and constraints of the security (and other business) policies on intermediaries and end points (for example, required security tokens, supported encryption algorithms, and privacy rules) and how to associate policies with services and end points.

If both provider and consumer specify a policy, an effective policy will be computed which usually consists of the intersection of both policies.

The new policy contains those assertions made by both sides which do not contradict each other. However, synonymous assertions are considered incompatible by a policy intersection.

This can easily be explained by the fact that policy intersection is a syntactic approach, which does not incorporate the semantics of the assertions. Furthermore it ignores the assertion parameters.

Opposed to what the name might suggest, a policy intersection is (although quite similar) not a set-intersection.

WSSecurity:

Web Services Security (WS-Security, WSS) is an extension to SOAP to apply security to Web services. It is a member of the Web service specifications and was published by OASIS.

The protocol specifies how integrity and confidentiality can be enforced on messages and allows the communication of various security token formats, such as Security Assertion Markup Language (SAML), Kerberos, and X.509. Its main focus is the use of XML Signature and XML Encryption to provide end-to-end security.

1 Features

2 Use cases

2.1    End-to-end security

2.2    Non-repudiation

2.3    Alternative transport bindings

2.4    Reverse proxy/common security token WS-Security describes three main mechanisms:

How to sign SOAP messages to assure integrity. Signed messages also provide non-repudiation.

How to encrypt SOAP messages to assure confidentiality. How to attach security tokens to ascertain the sender's identity.

The specification allows a variety of signature formats, encryption algorithms and multiple trust domains, and is open to various security token models, such as:

X.509 certificates, Kerberos tickets,

User ID/Password credentials,

SAML Assertions, and custom-defined tokens.

The token formats and semantics are defined in the associated profile documents.

WS-Security incorporates security features in the header of a SOAP message, working in the application layer.

These mechanisms by themselves do not provide a complete security solution for Web services. Instead, this specification is a building block that can be used in conjunction with other

Web service extensions and higher-level application-specific protocols to accommodate a wide variety of security models and security technologies. In general, WSS by itself does not provide any guarantee of security. When implementing and using the framework and syntax, it is up to the implementor to ensure that the result is not vulnerable.

Key management, trust bootstrapping, federation and agreement on the technical details (ciphers, formats, algorithms) is outside the scope of WS-Security.

End-to-end security

If a SOAP intermediary is required, and the intermediary is not or is less trusted, messages need to be signed and optionally encrypted. This might be the case of an application-level proxy at a network perimeter that will terminate TCP connections.

Non-repudiation

The standard method for non-repudiation is to write transactions to an audit trail that is subject to specific security safeguards. However, if the audit trail is not sufficient, digital signatures may provide a better method to enforce non-repudiation. WS-Security can provide this.

Alternative transport bindings

Although almost all SOAP services implement HTTP bindings, in theory other bindings such as JMS or SMTP could be used; in this case end-to-end security would be required. Reverse proxy/common security token

Even if the web service relies upon transport layer security, it might be required for the service to know about the end user, if the service is relayed by a (HTTP-) reverse proxy. A WSS header could be used to convey the end user's token, vouched for by the reverse proxy.

SIGNIFICANCE:

WS-Security adds significant overhead to SOAP processing due to the increased size of the message on the wire, XML and cryptographic processing, requiring faster CPUs and more memory and bandwidth.

An evaluation in measured 25 types of SOAP messages of different size and complexity processed by WSS4J with both WS-Security and WS-SecureConversation on a Pentium 4/2.8 GHz CPU. Some findings were:

Encryption was faster than signing.

APPLICATION AREA:

Encryption and signing together were 2–7 times slower than signing alone and produced significantly bigger documents.

Depending on the type of message, WS-SecureConversation either made no difference or reduced processing time by half in the best case.

It took less than 10 milliseconds to sign or encrypt up to an array of 100 kilobytes, but it took about 100~200 to perform the security operations for SOAP.