Secure your SOA

Service-oriented architecture (SOA) is rapidly gaining adoption in enterprises world wide.

Data and applications that were once silos are now being exposed as services across
departments and organizations. This poses unique challenges of securing and governing data
exchange. While security has traditionally been an IT domain, SOA governance encompasses
the business domain by extending security to include organizational policies and practices.
How do you mature your SOA to account for security and governance? What are the
standards and specifications in XML security today, and how do they work with each other?
What are the important considerations for SOA governance? How do you implement these in
a scalable way without sacrificing performance and maintainability? This article attempts to
answer these questions.
Featured Resource

Presented by Citrix Systems

10 essential elements for a secure enterprise mobility strategy

Best practices for protecting sensitive business information while making people productive
from
Learn More

Let's examine a few applications of SOA. Consider supply chain management. You have
scenarios of manufacturers, retailers, and consumers interacting with each other using
numerous systems and applications, mostly over the Internet. An SOA is an ideal enabler of
such loosely coupled interactions. An integral part of an enterprise-grade SOA is the
application of security services and governance policies in the various layers of
communication between trading partners.
When a customer places an order at a retailer's Website, it is readily apparent that the order
transaction must be secure. However, there is more to it than meets the eye. The retailer's
order fulfillment applications should involve interactions with inventory management
systems. Once the order is ready to be shipped, the retailer interacts with a shipping trading
partner, and the customer should be provided with services to monitor the order's status. Each
of these interactions would need security implementation at the application layers and,
generally, the transport protocol layer as well. Moreover, organizations must set up and
manage various policies: Who owns the data? Who is responsible for its veracity? How do
departments and trading partners share their data? This is what SOA governance is all about.

These interactions bring up requirements similar to a customer placing an order on a Website.

Security must be enforced in several layers during the message exchanges between these two
trading partners, and policies must be established to govern the services.
Another use-case is a manufacturer's product development lifecycle. This process may or
may not involve external trading partners, but typically, a large manufacturer has several
departments participating in the production of a single finished product. SOA delivers the
benefits of reuse and agile development even in scenarios where the manufacturer is not
involved with external partners; and, you guessed it, the same security and policy
requirements manifest themselves here.
The security requirements common to these scenarios include:

Authentication: How do I know your identity is true?

Authorization: Are you allowed to perform this transaction?
Integrity: Is the data you sent the same as the data I received?
Signature: Create and verify an electronic signature analogous to a handwritten signature.
Confidentiality: Are we sure that nobody read the data you sent me?
Auditing: Record all transactions for verification after the fact.
Nonrepudiation: Both sender and receiver can legally prove to a third party (e.g., a judge)
that the same data was sent and received in a transaction.

Other security requirements such as single sign-on (SSO) have become important due to the
proliferation of silos of identity information across applications. Threat prevention has also
evolved as another important security requirement for excluding bad data (spyware, malware,
etc.).
This article details the standards and approaches necessary for incorporating the above
mentioned security requirements into an SOA.
XML security standards and SOA
XML is a standards-based choice for representing the above requirements, thus XML security
standards can be employed to enable them. XML security standards leverage existing XML
standards and also enhance these standards as follows:
Popular on JavaWorld

Java programming with lambda expressions

Hello, OSGi, Part 1: Bundles for beginners

Review: 10 JavaScript editors and IDEs put to the test

The XML security standards define XML vocabularies for representing security information,
using XML technologies such as XML Schema for definitionfor example, the <KeyInfo>
element defined in the XML-Signature Syntax and Processing recommendation for carrying,
signing, or encrypting key information.
The XML security standards use other existing XML standards where possible to leverage
current XML efforts. For example, XML-Signature Syntax and Processing allows XPath
expressions to extract portions of XML for processing. It is important to note that this type of
selective signature processing was not really possible prior to the established XML security
standards; either the entire document was signed or not at all. The XML security standards
are designed to offer XML's flexibility and extensibility. They allow security to be applied to
XML documents, to XML elements, and element content, as well as to arbitrary binary
documents. They support the extension of XML vocabularies through the use of XML
namespaces and extensible XML Schema definitions.
XML security technologies may be applied to end-to-end security, which is especially
important when XML messages are routed through numerous processing intermediaries.
Persistent security is associated with the content, rather than with a transport pipe. The
security remains with the content. XML security technologies may be also used in
conjunction with transport security technologies, such as Secure Sockets Layer and
Transport Layer Security (SSL/TLS). Another point to note here is that identities designed for
SSO capabilities travel with the message as well.
XML security technologies reuse existing cryptographic and security technologies whenever
possible, without reinventing the wheel. For example, X.509 V3 certificates are used without
redefinition when neededthey are simply encoded in a text format. Existing algorithms,
such as the SHA1 digest algorithm, are also brought into the XML security standards world
by associating unique URI identifiers with them and defining how they may be used in the
XML security processing models. It is important to note that URI identifiers are used
pervasively in XML security for encryption and signature algorithms as well, not just hashing.

Similar Articles

Review: Cloud Foundry brings power and polish to PaaS

Microservices vs. the monolith

Heroku joins other PaaS providers in supporting PHP

The core XML security standards are:

XML Encryption
XML-Signature Syntax and Processing
Digital certificates
XML Key Management (XKMS)

XML Encryption, a World Wide Web Consortium (W3C) specification, provides end-to-end
security for applications that require secure exchange of structured data. As we know, XML
itself is the most popular technology for structuring data; therefore, XML-based encryption is
the natural way to handle complex requirements for security in data interchange applications.
XML-Signature Syntax and Processing, a W3C recommendation, provides integrity, message
authentication, and signer authentication services. XML signatures are digital signatures
designed for use in XML transactions. The standard defines a schema for capturing the result
of a digital signature operation applied to arbitrary (but often XML) data. Like non-XMLaware digital signatures (e.g., Public-Key Cryptography Standards, or PKCS), XML
signatures add authentication, data integrity, and support for nonrepudiation to the data they
sign. However, unlike non-XML-Signature Syntax and Processing standards, XML-Signature
Syntax and Processing has been designed to both acknowledge and leverage the Internet and
XML.
Digital certificates are electronic files that act like online passports. They are issued by a
trusted third party, a certificate authority (CA), which verifies the identity of the certificate's
holder.
XKMS, a W3C note, simplifies the securing of XML-based Internet transactions using public
key infrastructure (PKI) and digital certificates. It specifies protocols for distributing and
registering public keys suitable for use in conjunction with W3C's XML-Signature Syntax
and Processing. XKMS is composed of two partsthe XML Key Information Service
Specification (X-KISS) and the XML Key Registration Service Specification (X-KRSS).

As understood from the supply-chain use-case referenced earlier, accessing information over
the Internet is essential to the solution. Web services allow such functionality as they permit
the exchange of information over a network. Web services are based on three key standards:

SOAP (Simple Object Access Protocol), a protocol for data transmission

WSDL (Web Services Description Language), a language for the description of Web services
UDDI (Universal Description, Discovery, and Integration), a registry for locating a Web
service

Note that all of the above can be defined in XML. However, two issues must be specifically
addressed in our supply-chain solution:

Restricting access to XML-based Web services to authorized users. This is addressed by

XACML (Extensible Access Control Markup Language) and WS-Policy standards.
Protecting the integrity and confidentiality of XML messages exchanged in a Web services
environment. This is addressed by Web Services Security (WSS) and Security Assertion
Markup Language (SAML).

This article provides a brief overview of WS-Policy, WSS, SAML, XACML, and how
security is empowered by XQuery and XML databases. WSS provides message protection in
a SOAP environment. SAML and XACML support authorization and offer considerable
support for large-scale distributed systems. Most importantly, all these standards represent
information using XML. WS-Policy, WSS, SAML, and XACML all have some
commonalities. While all of these standards enable security services used in previous years,
each has specific features intended to make them suitable for large-scale, distributed
environments, such as the Internet. Additionally, these standards reference and incorporate
preexisting security standards.
As previously mentioned, these standards use XML. XML enables technologies to be
conveniently extended to meet special requirements in a way not possible using older
formats. In addition, XML allows implementers to use the many software tools available for
processing. In the case of WSS, it is designed to integrate closely with the syntax and
processing model of SOAP, which is defined in XML.
Furthermore, XML is a markup language, capable of labeling the information content of
diverse datasources, including structured and semi-structured documents, relational
databases, and object repositories. With so much relevant data available in XML form, it
becomes imperative that this data be queried and mined for further applicability. The query
language that understands XML and can express queries across all forms of XML data,
whether physically stored in XML or viewed as XML via middleware, is XQuery. XQuery is
broadly applicable across many types of XML datasources.
The recommended practice for persisting XML data is to use a native XML database
technology that treats XML not as another relational artifact, but as a natural XML artifact.
XML database management servers (XDMSs) are enterprise-grade XML persistence
mechanisms with all the bells and whistles that come with a traditional relational database.
XDMSs that feature powerful XML indexing, profiling, and acceleration are a big plus.

WS-Policy
As shown in Figure 1, the Web Services Policy Framework provides a general-purpose model
and corresponding syntax to describe and communicate the policies of a Web service. WSPolicy defines a base set of constructs that can be used and extended by other Web services
specifications to describe a broad range of service requirements, preferences, and capabilities.

Figure 1. The Web Services

Policy Framework stack

WS-Policy provides a flexible and extensible grammar for expressing the capabilities,
requirements, and general characteristics of entities in an XML Web services-based system.
WS-Policy defines a framework and a model for the expression of these properties as
policies. Policy expressions allow for both simple declarative assertions as well as more
sophisticated conditional assertions.
WS-Policy defines a policy to be a collection of one or more policy assertions. Some
assertions specify traditional requirements and capabilities that will ultimately manifest on
the wire (e.g., authentication scheme and transport protocol selection). Some assertions
specify requirements and capabilities that have no wire manifestation, yet are critical to
proper and usage (e.g., privacy policy and quality-of-service characteristics). WS-Policy
provides a single policy grammar to allow both kinds of assertions to be consistently
considered.

SOA goals
Before we explore the challenges that lie in the path of SOA, let's step back and reexamine
the goals of an organization embarking on an SOA implementation.
To achieve process visibility and flexibility
The worldwide SOA wave is definitely a well-justified one; SOA has come to represent an
amalgamation of several radical changes in distributed computing. Organizations always
invest heavily in technology to stay ahead of their competition, and SOA provides that
breakthrough opportunity. At the same time, organizations have also been refining their
business processes to squeeze out every last bit of competitive advantage. The emergence of
business process management (BPM) promises continuous process improvement and neverseen-before collaboration between businesses and IT groups. SOA is the umbrella under
which organizations are making a concerted effort to gain complete visibility into their data
and processes, perform continuous improvements, and exercise fine-grained control in an
effective and transparent manner.

To break down silos

The second goal of SOA is to break down application, department, and trading partner silos
built through years of software developmentthat addressed ever-evolving business
requirements and technology improvements. Having been assigned their own IT budgets,
departments have built applications to address their immediate needs, with little visibility into
projects around them that might have overlapping functionality. The result: numerous legacy
applications that leave IT departments struggling to reconcile duplicate information, and bits
and pieces of business processes strewn across hundreds of applications. An SOA promises to
break down these silos and let organizations gain better visibility into their data and
processes.
To manage better data
Popular on JavaWorld

Java programming with lambda expressions

Hello, OSGi, Part 1: Bundles for beginners

Review: 10 JavaScript editors and IDEs put to the test

Organizations not only want to manage data better, they also want to manage better data. It is
important to ensure that the data being produced and consumed across the organization and
its trading partners is clean, reliable, secure, well-governed, and fast. One of the goals of
SOA is to provide a composite data services platform with a unified set of components for
data access, quality, transformation, governance, and caching, among many other data-centric
services.
A typical composite data service is an assembly of well-behaved and well-understood atomic
activities and business rules deployed as a more functional service. For example, a composite
data quality service for customer contact information might sequence an address validation

service and an email validation service, and add the business rules to dictate what happens
when either service reports an error. Composite data services themselves are deployed and
managed in a metadata repository so that they are transparent and easily governed.
To reuse services
A related goal of SOA is to effectively manage and reuse enterprise services and data.
Services developed by one group in an organization can be used by any other group within or
outside the organization if they are published and described in a standards-based format in an
accessible registry. When data and services reside with their owners and are shared by
consumers as they need it, operational costs associated with their maintenance and
management are reduced. Reuse is one of SOA's biggest incentives.
To align organizational goals
Another goal of SOA is to align the business and IT groups behind the organization's goals to
better aid the development of flexible and configurable business processes. Historically,
business and IT domains have maintained quasi-independent charters to improve the
organizational bottom line. Business groups try to streamline business processes for
competitive advantages, and IT departments try to use technology adoption for implementing
these processes. The traditional mode of operation has the business group identifying the
process changes and then "tossing them over the wall" for IT engineers to implement. Neither
group has much visibility into the other group's function. BPM is a facet of SOA that tears
down the business-IT divide by enabling continuous process improvement through modeling,
simulation, execution, and monitoring in vocabularies that are shared and understood by both
business and IT departments

SOA goals
Before we explore the challenges that lie in the path of SOA, let's step back and reexamine
the goals of an organization embarking on an SOA implementation.
To achieve process visibility and flexibility
The worldwide SOA wave is definitely a well-justified one; SOA has come to represent an
amalgamation of several radical changes in distributed computing. Organizations always
invest heavily in technology to stay ahead of their competition, and SOA provides that
breakthrough opportunity. At the same time, organizations have also been refining their
business processes to squeeze out every last bit of competitive advantage. The emergence of
business process management (BPM) promises continuous process improvement and neverseen-before collaboration between businesses and IT groups. SOA is the umbrella under
which organizations are making a concerted effort to gain complete visibility into their data
and processes, perform continuous improvements, and exercise fine-grained control in an
effective and transparent manner.
To break down silos
The second goal of SOA is to break down application, department, and trading partner silos
built through years of software developmentthat addressed ever-evolving business

requirements and technology improvements. Having been assigned their own IT budgets,
departments have built applications to address their immediate needs, with little visibility into
projects around them that might have overlapping functionality. The result: numerous legacy
applications that leave IT departments struggling to reconcile duplicate information, and bits
and pieces of business processes strewn across hundreds of applications. An SOA promises to
break down these silos and let organizations gain better visibility into their data and
processes.
Organizations not only want to manage data better, they also want to manage better data. It is
important to ensure that the data being produced and consumed across the organization and
its trading partners is clean, reliable, secure, well-governed, and fast. One of the goals of
SOA is to provide a composite data services platform with a unified set of components for
data access, quality, transformation, governance, and caching, among many other data-centric
services.
A typical composite data service is an assembly of well-behaved and well-understood atomic
activities and business rules deployed as a more functional service. For example, a composite
data quality service for customer contact information might sequence an address validation
service and an email validation service, and add the business rules to dictate what happens
when either service reports an error. Composite data services themselves are deployed and
managed in a metadata repository so that they are transparent and easily governed.
To reuse services
A related goal of SOA is to effectively manage and reuse enterprise services and data.
Services developed by one group in an organization can be used by any other group within or
outside the organization if they are published and described in a standards-based format in an
accessible registry. When data and services reside with their owners and are shared by
consumers as they need it, operational costs associated with their maintenance and
management are reduced. Reuse is one of SOA's biggest incentives.
To align organizational goals
Another goal of SOA is to align the business and IT groups behind the organization's goals to
better aid the development of flexible and configurable business processes. Historically,
business and IT domains have maintained quasi-independent charters to improve the
organizational bottom line. Business groups try to streamline business processes for
competitive advantages, and IT departments try to use technology adoption for implementing
these processes. The traditional mode of operation has the business group identifying the
process changes and then "tossing them over the wall" for IT engineers to implement. Neither
group has much visibility into the other group's function. BPM is a facet of SOA that tears
down the business-IT divide by enabling continuous process improvement through modeling,
simulation, execution, and monitoring in vocabularies that are shared and understood by both
business and IT departments
\

SAML
The XML Security Assertion Markup Language defines an XML vocabulary for sharing
security assertions, including authentication and authorization assertions, enabling single
sign-on and third-party management of these functions. It also defines a request/response
protocol definition and an XML protocol (SOAP) binding. The SAML specification defines a
general assertion framework, allowing assertions to be given validity time periods and
allowing assertions to be targeted to specific audiences (avoiding the potential for misuse).
Assertions are associated with a given "subject" or named entity.
SAML is a standard way of exchanging security and related data across heterogeneous,
distributed systems crossing domain boundaries. Authorization and audit trail are familiar
security services. In the past, most systems were designed under the assumptions that a single
system would posses all of the information necessary to make access control decisions and all
the data would be recorded in the audit trail. However, large-scale distributed systems are
always built by multiple organizations with a mixture of products. Thus, users may be
authenticated by different authorities using different methods. In addition, different
authorities retain different information about user properties and attributes. Centralizing all
capabilities and information is just not practical. SAML provides standard formats to express
authentication and user attributes, and the protocols to request and receive.
The SAML specification defines:

An XML vocabulary for expressing authentication and authorization assertions,

allowing statements to be passed among parties about how and when authentication
and authorization occurred.
A request response protocol for conveying SAML assertions, as well as an XML
protocol (SOAP) binding.
Unique identifiers (URNs) for different authentication mechanisms and authorization
actions.
How digital signatures are associated with assertions.
SAML Token Profile, which describes how SAML assertions are carried in and
referenced from <wsse:security> headers, and how SAML assertions are used with
XML-Signature Syntax and Processing to bind the statements of the assertions (e.g.,
the claims) to a SOAP message.

Why SOA?
So why do we need SOA now? The answer is in one wordagility.
Business requirements change frequently, as they always have. The IT department has to
respond more quickly and cost-effectively to those changes. With a traditional architecture,
all components are bundled together with each other. Thus, even a small change to one
component will require a large number of other components to be recompiled and
redeployed. Quality assurance (QA) effort is also huge for any code changes. The processes
of gathering requirements, designing, development, QA, and deployment are too long for
businesses to wait for, and become actual bottlenecks.

To complicate matters further, some business processes are no longer static. Requirements
change on an ad-hoc basis, and a business needs to be able to dynamically define its own
processes whenever it wants. A business needs a system that is agile enough for its day-today work. This is very hard, if not impossible, with existing traditional infrastructure and
systems.
This is where SOA comes into play.
SOA's basic unit is a service. These services are building blocks that business users can use to
define their own processes. Services are designed and implemented so that they can serve
different purposes or processes, and not just specific ones. No matter what new processes a
business needs to build or what existing processes a business needs need to modify, the
business users should always be able to use existing service blocks, in order to compete with
others according to current marketing conditions. Also, if necessary, some new service blocks
can be used.
These services are also designed and implemented so that they are loosely coupled, and
independent of one another. A change to one service does not affect any other service. Also,
the deployment of a new service does not affect any existing service. This greatly eases
release management and makes agility possible.
For example, a GetBalance service can be designed to retrieve the balance for a loan. When a
borrower calls in to query the status of a specific loan, this GetBalance service may be called
by the application that is used by the customer service representatives. When a borrower
makes a payment online, this service can also be called to get the balance of the loan, so that
the borrower will know the balance of his or her loan after the payment. Yet in the payment
posting process, this service can still be used to calculate the accrued interest for a loan, by
multiplying the balance with the interest rate. Even further, a new process can be created by
business users to utilize this service if a loan balance needs to be retrieved.

How do we implement SOA?

Now that we've established why SOA is needed by the business, the question becomeshow
do we implement SOA?
To implement SOA in an organization, three key elements have to be evaluatedpeople,
process, and technology. Firstly, the people in the organization must be ready to adopt SOA.
Secondly, the organization must know the processes that the SOA approach will include,
including the definition, scope, and priority. Finally, the organization should choose the right
technology to implement it. Note that people and processes take precedence over technology
in an SOA implementation, but they are out of the scope of this article. In this article, we will
assume people and processes are all ready for an organization to adopt SOA.
Technically, there are many SOA approaches. At certain degrees, traditional technologies
such as RPC, DCOM, CORBA, or some modern technologies such as IBM WebSphere MQ,
Java RMI, and .NET Remoting could all be categorized as service-oriented, and can be used
to implement SOA for one organization. However, all of these technologies have limitations,
such as language or platform specifications, complexity of implementation, or the ability to
support binary transports only. The most important shortcoming of these approaches is that

the server-side applications are tightly coupled with the client-side applications, which is
against the SOA principle.
Today, with the emergence of web service technologies, SOA becomes a reality. Thanks to
the dramatic increase in network bandwidth, and given the maturity of web service standards
such as WS-Security, and WS-AtomicTransaction, an SOA back-end can now be
implemented as a real system.

SOA from different users' perspectives

However, as we said earlier, SOA is not a technology, but only a style of architecture, or an
approach to building software products. Different people view SOA in different ways. In fact,
many companies now have their own definitions for SOA. Many companies claim they can
offer an SOA solution, while they are really just trying to sell their products. The key point
here isSOA is not a solution. SOA alone can't solve any problem. It has to be implemented
with a specific approach to become a real solution. You can't buy an SOA solution. You may
be able to buy some kinds of products to help you realize your own SOA, but this SOA
should be customized to your specific environment, for your specific needs.
Even within the same organization, different players will think about SOA in quite different
ways. What follows are just some examples of how different players in an organization judge
the success of an SOA initiative using different criteria. [Gartner, Twelve Common SOA
Mistakes and How to Avoid Them, Publication Date: 26 October 2007 ID Number:
G00152446]

To a programmer, SOA is a form of distributed computing in which the building blocks

(services) may come from other applications or be offered to them. SOA increases the scope
of a programmer's product and adds to his or her resources, while also closely resembling
familiar modular software design principles.
To a software architect, SOA translates to the disappearance of fences between applications.
Architects turn to the design of business functions rather than to self-contained and isolated
applications. The software architect becomes interested in collaboration with a business
analyst to get a clear picture of the business functionality and scope of the application. SOA
turns software architects into integration architects and business experts.
For the Chief Investment Officers (CIOs), SOA is an investment in the future. Expensive in the
short term, its long-term promises are lower costs, and greater flexibility in meeting new
business requirements. Re-use is the primary benefit anticipated as a means to reduce the
cost and time of new application development.
For business analysts, SOA is the bridge between them and the IT organization. It carries the
promise that IT designers will understand them better, because the services in SOA reflect
the business functions in business process models.
For CEOs, SOA is expected to help IT become more responsive to business needs and
facilitate competitive business change.

What is Service-Oriented Architecture?

SOA - What is Service-Oriented Architecture? - August 27, 2008 at

17:10 pm by Amit Satpute
What is Service-Oriented Architecture?

SOA is an IT architecture strategy for business solution (and

infrastructure solution) delivery based on the concept of serviceorientation.
It is a set of components which can be invoked, and whose interface
descriptions can be published and discovered.
It aims at building systems that are extendible, flexible and fit with
legacy systems.
It promotes the re-use of basic components called services.
What is Service-Oriented Architecture?

SOA is an IT architecture strategy for business solution (and

infrastructure solution) delivery based on the concept of serviceorientation.
It is a set of components which can be invoked, and whose interface
descriptions can be published and discovered.
It aims at building systems that are extendible, flexible and fit with
legacy systems.
It promotes the re-use of basic components called services.

Challenges faced in SOA adoption

One of the challenges faced by SOA is managing services metadata.

Second biggest challenge is the lack of testing in SOA space.
Another challenge is providing appropriate levels of security.
Interoperability is another important aspect in the SOA implementations.
Vendor hype concerns SOA because it can create expectations that may not be fulfilled.

What is SOA governance? What are its functions?

Service-Oriented Architecture (SOA) governance is a concept used for activities related to

exercising control over services in an SOA
Some key activities that are often mentioned as being part of SOA governance are:

Managing the portfolio of services: This includes planning development of new services and
updating current services.
Managing the service lifecycle: This is meant to ensure that updates of services do not
disturb current services to the consumers.
Using policies to restrict behavior: Consistency of services can be ensured by having the
rules applied to all the created services.
Monitoring performance of services: The consequences of service downtime or
underperformance can be severe because of service composition. Therefore action can be
taken instantly when a problem occurs by monitoring service performance and availability.

Why Web Services?

Here are the benefits of using Web Services:
Exposing the function on to network: A Web service is a unit of managed code that
can be remotely invoked using HTTP, that is, it can be activated using HTTP
requests. So, Web Services allows you to expose the functionality of your existing
code over the network. Once it is exposed on the network, other application can use
the functionality of your program.
onnecting Different Applications: Web Services allows different applications to talk
to each other and share data and services among themselves. Other applications can
also use the services of the web services. For example VB or .NET application can
talk to java web services and vice versa. So, Web services is used to make the
application platform and technology independent.
Standardized Protocol: Web Services uses standardized industry standard protocol for
the communication. All the four layers (Service Transport, XML Messaging, Service
Description and Service Discovery layers) uses the well defined protocol in the Web
Services protocol stack. This standardization of protocol stack gives the business
many advantages like wide range of choices, reduction in the cost due to competition
and increase in the quality.
Low Cost of communication: Web Services uses SOAP over HTTP protocol for the
communication, so you can use your existing low cost internet for implementing Web
Services. This solution is much less costly compared to proprietary solutions like
EDI/B2B.
Support for Other communication means: Beside SOAP over HTTP, Web Services
can also be implemented on other reliable transport mechanisms. So, it gives
flexibility use the communication means of your requirement and choice. For example
Web Services can also be implemented using ftp protocol (Web services over FTP).
Loosely Coupled Applications: Web Services are self-describing software modules
which encapsulates discrete functionality. Web Services are accessible via standard
Internet communication protocols like XML and SOAP. These Web Services can be
developed in any technologies (like c++, Java, .NET, PHP, Perl etc.) and any
application or Web Services can access these services. So, the Web Services are
loosely coupled application and can be used by applications developed in any
technologies. For example, I have heard of people developing Web Services using
Java technologies and using the Web Services in VB or .NET applications.

Web Services Sharing: These days due to complexness of the business, organizations
are using different technologies like EAI, EDI, B2B, Portals etc. for distributing
computing. Web Services supports all these technologies, thus helping the business to
use existing investments in other technologies.
Web Services are Self Describing: Web Services are self describing applications,
which reduces the software development time. This helps the other business partners
to quickly develop application and start doing business. This helps business to save
time and money by cutting development time.
Automatic Discovery: Web Services automatic discovery mechanism helps the
business to easy find the Service Providers. This also helps your customer to find your
services easily. With the help of Web Services your business can also increase
revenue by exposing their own Web Services available to others.
Business Opportunity: Web Services has opened the door to new business
opportunities by making it easy to connect with partners.

Business Benefits of Service-Oriented Architecture

SOA can help businesses respond more quickly and economically to changing market
conditions.
SOA can be considered an architectural evolution. It captures many of the best practices of
previous software architectures.
The goal of separating users from the service implementations is promoted by SOA.
The goals like increased interoperability, increased federation and increased business &
technology domain alignment can be achieved by SOA due to its architectural and design
discipline.
SOA is an architectural approach for constructing complex software-intensive systems from
services.
SOA realizes its business and IT benefits through utilizing an analysis and design
methodology when creating services.
How can you achieve loose coupling in a soa ?
One strategy for achieving loose coupling is to use the service interface (the WSDL for a SOAP Web
Service) to limit this dependency, hiding the service implementation from the consumer. Loose
coupling can be addressed by encapsulating the service functionalities in a manner that limits the
impact of changes to the implementation on the service interface. However, at some point you will
need to change the interface and manage versioning without impacting service consumers, in
addition to managing multiple security constraints, multiple transports, and other considerations

At my company the most common delivering mechanism for services is XML over JMS. It works
alright. Since this messaging stuff if asynchronous there has to be some trick played to get a
response back. That trick is the temporary queue.
Say I'm a service behind a JMS queue. You call me by sending some XML to this Queue. You expect
a response. So in the message you also send me the name of a temporary queue which you've
created and started listening on. I'll take in your XML do my thing and respond to you on the
temporary queue which you created.

A "Service" is thought of as a Request and a Reply. You ask for something and you get
something.
SOA - Service Orientated Architecture (Exposing business tasks piece meal and letting users
select what parts they want.)
Basically, a Web Service is a fully designed specification and as you pointed out works
across the Web, if you want it to. But you have to work within the Web Service spec only one
way.
ESB - Something you build (or buy) that take all kinds of messages (Web Service, JMS,
paper airplanes, etc, etc) runs them through some transformations and sends the request to the
correct process. Basically, a big funnel taking all kinds of things and building a common
message from them before sending them on.
>> I need some services that should be not be exposed over the web. Is this possible?
If you are already using WS check into blocking them through your router
configuration. That way you can leverage your expertise.
If not WS expertise then you can setup a simple JMS messaging and use that for your
services. JMS is really powerful technology that will give you a lot of flexibility now and in
the future to do others stuff as you think of it. It can do binary transfers as well if you have
need. You can do store and forward stuff, push, pull, hook in with AJAX pretty much
whatever you can think off.
And if you got the need for a ESB look at Mule but why do ESB if all you need is a single
type of service.
If you need more Bla, Bla, Bla just let us know we have plenty of it stored up.
Web Services is a technology that was initially introduced by IBM and
Microsoft. There are 3 main specs in Web Services. SOAP, WSDL, and
UDDI. SOAP is the wrapper protocol around a transport protocol, WSDL
is the descriptor language that describe the web service, its
operations, request, response documents, etc. and UDDI is the service
registry, and it's an optional component of Web Service.

With Web Service, one can expose a Java Enterprise Edition, .NET, and
other applications out to a business partner or even the internet
public, like Amazon.com Web Service. Everything is XML-driven. The
request is made via XML, the response is XML. The UDDI lookup and
registration is XML-based as well. The WSDL that describes the Web
Service is also XML. Since it's XML, then it's not proprietary, and
therefore interoperable. My first web service experience was using a
VB Web Service client calling a WebLogic Web Service exposing an
Enterprise JavaBean, which then calls another CRM system. Web Service
seems to be the easiest way to expose your application for others to
call.
SOA or Service Oriented Architecture is a paradigm shift. To implement
a SOA, most companies have chosen to use an Enterprise Service Bus as
the backbone of their integration environment. With an ESB, all
applications can then be plugged into the the ESB as endpoints.
Different protocols and message formats can be used. Of course, Web
Services is one of the key endpoints that can be called. Kyle and
others also mentioned JMS. In fact, you can have SOAP over HTTP, or
SOAP over JMS. There are other transports that are possible: SMTP,
FTP, File, and mostly any other TCP based protocol bindings can be
supported. As far as the message formats, most of the ESBs not only
support XML, but can also support non-XML data, binary, etc. With some
ESBs, there's proxy service, data transformation, routing, monitoring,
SLAs, etc. that is provided by the vendor to give you a complete ESB
solution.
ESB is the core component of a SOA infrastructure, but that's not all
of it. In order to deploy a successful SOA solution, there are many
other parts. For examples, you may need a service registry for dynamic
web service, registration and lookup of service. The service registry
should be UDDI compliant. You may need an enterprise repository, to
catalog all your assets. You may need a management piece to monitor
and report on the services being executed. Let's not forget about
Security. Since you're exposing all these services, how do you protect
the services? at the transport level, at the message level, and at the
apps level.
SOA is a very powerful solution for many companies, but it's certainly
not a one-size-fits-all. I see many people recommended looking at
Mule. It's a free way to try out a service bus, but can be tough to
learn. You may also want to take a look at some products offered by
vendors as well. BEA and TIBCO both have an enterprise service bus. I
would steer you away from IBM, since they really have 2 solutions for
ESB.

We are defining services that uses SOAP/HTTP end point for synchronous and SOAP/JMS
end point for asychronous communication in the WSDL definition.
To add my two cents on ESB, it is also used to define Orchestration using BPEL (Business
Process Execution Language) or other language that supports business process. In other
words it is a process flow diagram that links different services implemented as WSDL
services or other services. Some of the vendors support only WSDL in the orchestration.
Some of them support WSDL and other type of services. Here the main advantage is, the
WSDL services that are participating in the orchestration can belong to multiple systems. One
from accounting, one from customer, one from inventory all participating in harmony that has
different end points

In an SOA, services and service orchestrations will interact with services spread across an
organization, and between organizations. An ESB provides the communications facilities
which link them together with configurable qualities of service and messaging semantics,
with both queuing and publish-and-subscribe behavior. This allows the gathering and
distribution of data, as well as the notification of business events and correlation of replies of
subscribing services. In a federated environmentone in which services cross organizational
boundariesor in a distributed environmentone in which service communications bridge
geographic boundariesit is critical that data, events, and replies are directed to the right
place at the right time, without management overhead. Advanced distribution capabilities
allow flexible extension of the ESB to incorporate and connect resources in additional
security domains without any reconfiguration or disruption of running systems.

15.What is the difference between SOA and a Web service?

Ans:SOA is a software design principle and an architectural pattern for implementing loosely
coupled, reusable and coarse grained services. You can implement SOA using any protocols
such as HTTP, HTTPS, JMS, SMTP, RMI, IIOP (i.e. EJB uses IIOP), RPC etc. Messages can
be in XML or Data Transfer Objects (DTOs).
Web service is an implementation technology and one of the ways to implement SOA. You
can build SOA based applications without using Web services for example by using other
traditional technologies like Java RMI, EJB, JMS based messaging, etc. But what Web
services offer is the standards based and platform-independent service via HTTP, XML,
SOAP, WSDL and UDDI, thus allowing interoperability between heterogeneous technologies
such as J2EE and .NET.
16.Web services when you can use traditional style middle-ware such as RPC, CORBA,
RMI and DCOM?
Ans:The traditional middle-wares tightly couple connections to the applications and it can
break if you make any modification to your application. Tightly coupled applications are hard
to maintain and less reusable. Generally do not support heterogeneity. Do not work across
Internet. Can be more expensive and hard to use.

Web Services support loosely coupled connections. The interface of the Web service
provides a layer of abstraction between the client and the server. The loosely coupled
applications reduce the cost of maintenance and increases re-usability. Web Services present
a new form of middle-ware based on XML and Web. Web services are language and platform
independent. You can develop a Web service using any language and deploy it on to any
platform, from small device to the larges
Do you recall any pattern which could be used to leverage loose coupling ?
Ans:The Mediation pattern, using an enterprise service bus (ESB), will help in achieving this.
Mediation will take loose coupling to the highest level. It will establish independence
between consumers and providers on all levels, including message formats, message types
(including SOAP, REST, XML, binary) and transport protocols (including HTTP, HTTPS,
JMS). Architecturally speaking this means the separation of concerns between consumers and
providers on the transport, message type, and message format levels.
.How do I integrate my Legacy applications with SOA ?
Ans:Legacy applications are frequently at the core of your IT environment. With the right
skills and tools, you need to identify discrete elements within your legacy applications and
wrap them in standards-based interfaces and use them as services within your SOA.

Service
A service is a piece of self-contained business functionality. The functionality might be
simple (storing or retrieving customer data), or complex (a business process for a customers
order). Because services concentrate on the business value of an interface, they bridge the
business/IT gap.

ESB

ESB is the infrastructure that enables high interoperability between distributed systems for
services.
It makes it easier to distribute business processes over multiple systems using different
platforms and technologies.
TCP network + DNS may be consider a type of ESB

Loose Coupling

Concept of reducing system dependencies.

Minimize the effects of modifications and failures.
Price for loose coupling: complexity.
Loosely coupled distributed systems are harder to develop, maintain, and debug.