Advertisment

Web Services

author-image
PCQ Bureau
New Update

Web services and technologies have seen a lot of changes in recent past. From

WDSLs and SOAP based architectures to newer standards such as the WS-BPEL (Web

Services-Business Process Execution Language) and solutions like WSIT (Web

Services Interoperability Technologies) a lot has been done to make them more

useful than the earlier 'Weather Quote' or 'Stock Quote' purposes that

they sufficed. There has been a lot of work put into making them more useful as

solutions for implementing BPM (Business Process Management) and enabling SOA

(Service Oriented Architectures). For example, the WS-Transaction specification

that defines transaction behavior and when a transaction is complete while being

run through Web services. With these additions, there has been an increased

concern on the security of the transactions, which would run on Web-services. We

will look into some of the technologies that will impact this domain in days to

come.

Advertisment

WS-BPEL



The WS-BPEL or simply BPEL enables Web services for B2B processes
communications. With BPEL, you can implement Web services for longer duration

transactional processes. This assists better in cross-enterprise integrated

solutions. It was jointly initiated by key players such as Microsoft, IBM and

has graduated to WS-BPEL 2.0 standardized by OASIS (Organization for the

Advancement of Structured Information Standards). BPEL is the resultant of

coalescing two early workflow languages; Web Services Flow Language (WSFL)

designed by IBM and XLANG designed by Microsoft.

WSFL is based on the concept of directed graphs while XLANG is a block-

structured language. BPEL combines both approaches and provides a rich

vocabulary for description of business processes. XML Web Services and

service-based architectures are quickly becoming the standard development model

for software applications. Thanks to the service-oriented model and SaaS

(Software-as-a-Service) methodologies gaining increasing importance amongst

those who implement enterprise solutions. A standard orchestration language like

BPEL will be one of the enabling technologies for these architectures. This

would also reduce the time and cost for implementation.

Advertisment

A BPEL process is an XML document generated with graphical design tools by

business analysts rather than programmers. That is, when a process is initially

designed using BPEL it is done with only the business goal as the primary focus.

These processes defined in BPEL are executed by an execution engine. The engine

can publish a BPEL process through a Web Services Interface or react to trigger

conditions set up inside the process itself. Thus your business process

addresses the business goals with BPEL, it also adapts quickly to changes in

environment — a trait you would have heavily missed in simple web services

based processes.

While the initial draft was still being standardized, BPEL incorporated many

crucial standards to provide a complete Web-services technology stack. This

package included stuff from 'traditional' SOAP, WSDL, UDDI to standards such

as WS-addressing, WS-Reliable Messaging, WS-Transaction and WS-Coordination.

Each of these specifications add to the existing advantages of BPEL reliability

in message transfer and transactional capabilities which cannot be achieved

using simple WSDL based Web services and much needed context within which

coordination is to take place. It also enables specific items of data that are

to be exchanged. This, in return, lets transactions to complete successfully as

part of an overall business process defined in a BPEL program.

Advertisment
UDDI: Lest we

forget
UDDI (Universal Description Discovery and

Integration) is a mechanism for Web services to dynamically discover and

invoke other Web services. Sounds like a protocol that would bring about

enterprises' applications to be integratable and interoprable on the

fly! But the truth is that it is not used primarily for this purpose. This

might be the reason why enterprise integration projects fail to deliver

the proposed or expected business value. While its siblings-SOAP and

WSDL-gained a lot of acceptance and importance, you don't find people

using UDDI much or at all in their SOA or Web-services based solutions.

With UDDI v3 been standardized quite some time back (February, 2005), it

is one specification that needs more attention and usage than what it is

being given off late.

Within the enterprise, BPEL is used to standardize enterprise application

integration as well as to extend the integration to previously isolated systems.

Between enterprises, BPEL enables easier and more effective integration with

business partners. BPEL stimulates enterprises to further define their business

processes, which in turn leads to business process optimization, reengineering,

and the selection of the most appropriate processes, thus further optimizing the

organization. Definitions of business processes described in BPEL do not affect

existing systems, thereby stimulating upgrades. BPEL is the key technology in

environments where functionalities are already exposed or will be exposed via

Web services.



Over a year ago BPEL4WS had been standardized and was taking infant steps into
the world of integration and interoperability. With increases in the use of Web

services, and a framework that addresses all the issues associated with business

communications the importance of BPEL will increase as well.

WSIT



Interoperability between Web services based on Java EE and .NET has been a pain
area for solution architects and developers. WSIT (Web Services Interoperability

Technologies) is an initiative by Sun Microsystems is aimed at easing building,

deploying and maintaining solutions composed of Web-services built using Java

Web Services and Microsoft Windows Communication Foundation. It is built on JAX-WS

(Java API for XML Web Services). As it is based on open standards, it enhances

interoperability, and also addresses security, messaging and QoS issues. The

technology incorporates a huge number of specifications to achieve

interoperability. These specifications include WS-Reliable Messaging,

WS-Coordination, and WS-Atomic Transaction for facilitating QoS. For security,

the specifications implemented are WS-Security, WS-Trust, WS-Secure Conversation

and WS-Security Policy. Any such technology was missing or present in very basic

variants about a year ago. But in the days to come, this is one thing to watch

for. All in all, it is a comprehensive mix of all the ingredients it takes for a

promising technology that could ease out a lot of issues and catalyze

interoperability in the new world of Web services.

Advertisment

Security



The concern for security has started making a more strong presence with Web
services. Also it has graduated to become one of the most prevalent enablers for

many of the new developments in EAI, SOA and interoperability. As a result, a

lot of initiatives could be seen to develop an open standard for securing Web

services or making Web services based implementation more secure for business

communications. Many organizations such as OASIS and W3C have worked out quite a

few methods and specifications for securing Web services at various levels such

as SOAP messages, and various XML based specifications to secure communication

over the wire.

The specifications, no doubt, have provided a basis for entrusting more

confidence when it comes to using Web services for interoperable business

process. This is because you can now load your Web services with XML Signatures

and top it with WS-Security that provides security for SOAP messages. In short,

security in Web services has travelled a good distance as compared to where it

was last year. In the days to come, you can expect Web services taking over a

lot of transaction systems. But will they be the most potent source for

workflow, BPM and EAI alike? This will be more evident with time to come.

Security

Standards
Here are a fw standards and specifications

that are being worked upon, and are expected to be accepted once a

consensus is reached upon.

XML Signature: Developed jointly by the W3C and

IETF (Internet Engineering Task Force). An XML signature is equivalent to

a digital signature; it can be used to digitally sign portions of an XML

document. It is used with SOAP messages.

XML Encryption: Developed by the W3C proposes to

encrypt portions of XML documents. This specification can be used to

assure confidentiality in case of a security context ranging over several

SOAP intermediaries. To do that, portions of the SOAP message are kept

confidential from SOAP intermediaries while the message is in transit.

XML Key Management Specification (XKMS):

Developed by the W3C to allow clients to obtain cryptographic key

information (such as keys and certificates). It also describes protocols

for key management such as registration and revocation, suitable to be

used together with XML Signature and XML Encryption.

Security Assertions Markup Language (SAML):

Defined by OASIS, it outlines a framework for exchanging authentication

and authorization information. It is a vendor-neutral framework to

communication authentication, authorization, and attribute information of



a subject.

XML Access Control Markup Language (XACML): The

primary goal of this specification is to standardize access control

language in XML syntax. Such a language can be used to express access

control policies like who can do what and when. Web Services Policy

Language (WSPL), which is based on XACML, is a generic language for

expressing policy information.

Liberty Alliance: This consortium of commercial

and noncommercial organizations aims to enable a networked world where

individuals and businesses can conduct transactions while securely

protecting their ID. Specs created by this consortium support and include

other standards such as SAML, XML, and WS-Security.

Advertisment