|
Web Services
Wednesday, December 06, 2006
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.
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.
 |
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.
| 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.
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. |
Page(s) 1
|
