SOA Gateway - The Evolution of SOA and Cloud Computing

It has been a long time coming. For many years SOA Governance was the industry buzzword that
virtually every company employed to indicate that they played in the SOA arena. The term "SOA
Governance" was used to describe everything from design time management of test and design
artifacts, monitoring, enforcement, UDDI registry storage, SLA expectations, etc. Many of the
industry analysts latched onto UDDI as the central technology that would drive the governance
initiatives.

The reality of successful SOA deployment turned out to be a different story. Successful SOA was
measured on a project by project basis. Feedback from the CIO and CFO level as to the benefits of
each project then reinforced the technology decision to invest further in SOA. It is the individual
advantages first that lead to the higher level advantages later of investing in SOA. Due to the
fractured nature of SOA deployments, it began to become a technology and architecture of multiple
domains within an organization. Teams that each was able to show success of SOA did not do so in
concert with each other.

That all changed once the adoption of SOA gateway technology began to take hold. SOA Gateways
allow for the runtime governance of services and transactions. This in turn provides the means to
aggregate the services of an enterprise in one consolidated location and centrally enforce reusable
policies with regard to access control, security, and monitoring. This technology has led the way to
the recognition of SOA as a true enterprise ROI optimization investment. As a result, the SOA
Gateway has now also become what analysts had envisioned for UDDI in the early phases of SOA,
which is the central place by which to manage, enforce, and monitor (a.k.a. govern) services and
transactions.

Now we come to the age of cloud computing which is the new buzz phrase that has all but replaced
"SOA Governance" in blogs, press releases, analysis coverage, and news cycles. This is the next
frontier, the new promise of technology. Let's be clear, cloud computing has potential and real
promise as a game-changing technology paradigm, but the actual adoption and recognition of this
outcome will follow the same path as SOA did to get there.

Consider that SOA as a concept has been around for many years. Software as a service is not a new
concept, but the open nature of services extended this concept to SOA. Cloud computing extends
this concept further by providing dynamic SaS as lower cost, on-demand services. While the notion
is easy to recognize in it's simplicity and elegance, it becomes a little more difficult to map to
actual enterprise business use-cases.

Enter the SOA Gateway. This technology has become the central governance broker for transactions
among clients and services. By that nature, the SOA gateway already abstracts the client from the
service. This abstraction lends itself perfectly to the adoption of cloud based services that can
extend the capacity and computing requirements on both sides of the transaction.

The success of Cloud Computing for enterprise transactions will depend on solving the core business
concerns of reliability, security, access control, and accountability. It is not a coincidence that
these topics happen also to be the core feature set of the SOA gateway industry.

Just as protocol firewalls and web application firewalls paved the way to the adoption of the
internet for business communication, SOA Gateways will pave the way to the adoption of cloud
computing for the next generation of business communication.

INTRODUCTION TO SOA GATEWAYS: BEST PRACTICES, BENEFITS &

REQUIREMENTS
Learn best practices and common deployment scenarios of SOA Gateways and why they are an
essential component of a secure, robust and scalable SOA deployment.

I. OVERVIEW

Modern web services-based Service Oriented Architecture (SOA) enables service consumers and
producers to exchange messages over ubiquitous standards such as XML and SOAP. Typically,
companies embark on SOA projects for system-to-system integration within their corporate domains
as well as with external trading partners. The success of a SOA deployment is measured by the
level of reuse of producer services. A well thought out SOA is flexible, loosely coupled and nimble
and enables consumer applications to rapidly integrate with published producer services. The
driving force of a successful SOA to reuse producer services is usually at odds with
security. Integration flexibility and security typically pull in diametrically opposite
directions. Integration pulls corporations towards "opening up" internal systems for other systems to
call into whereas security pulls a company towards "locking down" business information through
access control and data privacy. For a successful SOA deployment, ease-of-system integration
without compromising security is paramount. Overly strict security models can eliminate the ease-
of-integration advantage and an overly open SOA deployment with little or no consideration for
security is a recipe for disaster, especially where sensitive and valuable corporate data is
involved. SOA Gateway products such as Forum Sentry (a FIPS and DoD Certified hardware
appliance) and Radware AppXML provide the necessary balance between rapid integration and
security that results in a successful SOA deployment.

A SOA Gateway is a core infrastructure component of a SOA deployment with the ability to integrate
services securely. Typically deployed as a hardware appliance, a SOA Gateway seamlessly controls
access to services, protects information through data-level encryption, ensures the integrity of a
message through signatures, and controls corporate information flow. This article covers SOA
Gateway deployment best practices, benefits and requirements with a focus on service
virtualization, message privacy and integrity, and message control and auditing.

II. BEST PRACTICE: ENABLE SERVICE VIRTUALIZATION AND CONTROL

Description: Service Virtualization - the most important best practice of a SOA - is the ability to
create a virtual service from one or more Web Services Description Language (WSDL) files generated
by producer applications such as application servers, RDBMS, CRM and ERP systems. As shown in
Figure 1 below, service virtualization across multiple producer systems is accomplished through an
intermediary SOA Gateway that sits between the producer and the consumer. Instead of directly
importing services from a variety of producer applications, consumer applications can import
virtualized services from an intermediary SOA Gateway that aggregates and consolidates multiple
back-end producer services into a single WSDL and a single entry point. Service virtualization
enables enterprises to expose only specific business services required by a consumer rather than
exposing all services from producer applications. On requesting a WSDL from the
intermediary SOA Gateway, the consumer is presented with a set of virtual services that it is
allowed to access. In the sample deployment shown in Figure 1 below, the "Internal" consumer is
authorized to use services A-C and D,E from the producer Application Server and Business
Application respectively. However, the "External" consumer, perhaps a supplier, is only allowed
to use services B and F. Thus, a SOA Gateway acts as a central point of control that cloaks and
safeguards producer services through access control policies and through virtualization only shows
the services available to a consumer.

Figure 1: Enabling Service Virtualization through a SOA Gateway

Benefits: Enabling Service Virtualization by using SOA Gateways has significant benefits including:

 Consistency: Virtualization enables service selection across multiple WSDLs and exposes
only authorized services to clients as a coherent single WSDL.
 Security: The virtual WSDL can selectively expose some of the services of the original
WSDLs. The WSDL endpoints are cloaked with only the SOA Gateway endpoints being
exposed. The SOA Gateway endpoints are protected through credential-based access
control.
 Productivity: Service virtualization improves productivity by enabling mixing services across
different producer services without having to copy and paste parts of the desired WSDLs
into new WSDL files. It allows a customer to be able generate a library of all the services
supported by its organization and only expose the ones required for a particular customer.

Requirements: SOA Gateways require industry-hardened WSDL and schema parsing to import,
aggregate and publish complex WSDLs generated from a variety of application servers, RDBMs, and
business applications. For enterprise-class service virtualization, a SOA Gateway is required to have
the following essential features:

 Integration with existing Identity Management Systems: A SOA Gateway must have deep
authentication and authorization-level integration with existing Identity Management
Systems such as CA SiteMinder, Sun Access Manager, and HP Select Access for service access
control.
 Identity Bridging: A SOA Gateway must have sophisticated identity token processing
capabilities to intercept, process and convert credentials among a variety of protocol
formats (Basic Auth, SSL Mutual Auth) and content formats (SAML, WS-Tokens, X.509
Tokens) for Authentication and Authorization decisions.
 Manage complex WSDLs: Ability to parse, merge and administer multiple compound WSDLs
and schemas and avoid namespace collisions while aggregating WSDLs from multiple
systems.

Deploying Service Virtualization with granular access control is crucial for a scalable SOA. The vices
of free-for-all services can quickly set chaos within a SOA deployment. A SOA Gateway can control
and manage an increasingly complex SOA deployment through service virtualization. Identity
integration goes hand-in-hand with service virtualization. Leveraging existing identity
infrastructure with service-level access control is the most crucial best practice of a SOA
deployment. The quality of SOA Gateway integration with identity systems along with the gateway's
performance optimization features - such as intelligent credential caching - will determine the
overall performance of a SOA deployment.
III. BEST PRACTICE: ENFORCE DATA-LEVEL PRIVACY AND INTEGRITY

Description: Data-level privacy and integrity is the cornerstone of enterprise-class SOA. With
SOAP/XML encryption and signature, confidentiality and integrity remain "always on" by being
independent of transport protocols. With security now living within the SOAP/XML messages, it does
not matter if the transport pipe – HTTP, FTP, JMS – between Web service consumers, producers, or
intermediaries is SSL enabled.

The protocol independent nature of SOAP/XML-based messaging within a SOA decouples the
messages from protocol security such as SSL. In a SOA, messages traversing the enterprise may do
so over non-secure protocols such as FTP and JMS. To ensure that a message retains its privacy and
integrity, security has to live within the message through data-level encryption and signatures. By
using WS-Security (an OASIS security standard), messages can be granularly encrypted/decrypted
and signed/verified for ensuring privacy and integrity at the data level, independent of protocol
security.

Deploying a SOA Gateway to handle data-level encryption/decryption and signature/verification is a

widely used industry best practice for ensuring strong privacy and integrity. Figure 2 below shows a
typical SOA Gateway deployment for verifying and decrypting inbound messages from a consumer
that has first encrypted and then signed the message before sending it out to the producer
services. The message is intercepted by the SOA Gateway that performs signature verification on
the message to ensure that it has not been tampered with and then decrypts the message before
sending it to the back-end producer application. The SOA Gateway takes away the burden of
signature verification and decryption from the producers and provides a central location for
maintaining security policies.

Figure 2: Enabling Data-level message privacy and integrity.

Benefits: Enabling Data-level privacy and integrity using SOA Gateways has significant benefits
including:

 Consistency: By centralizing security policies and separating the security policies from the
producer services, SOA Gateways provide a high-degree of policy consistency and
control. Service implementations become independent of security policies that are
centrally managed on the SOA Gateway.
 Security: Data-level security provides "data-at-rest" security over protocol-level security
(SSL). Highly sensitive data within a message can be secured using strong cryptography
whereas public data can be left as clear text. Data-level security is always-on, even when
the message is at rest where it is most vulnerable. SOA Gateways provide protection of
messages in-flight through protocol security as well as security for messages at rest through
granular data-level security.
 Productivity: By centralizing security policies to a SOA Gateway, developers building
producer services need not worry about writing code for security policies. For example, as
shown in Figure 2, developers can focus on building core functionality rather than writing
code that verifies and decrypts messages - functionality that is handled by the SOA
Gateway. With no coding required for such centralized security functions, the overall
productivity of the SOA project increases significantly.

Requirements: SOA Gateways have to be secure, robust, performing and highly interoperable in an
enterprise-class environment where many internal and external systems are exchanging
messages. For deploying privacy and integrity, a SOA Gateway must meet the following
requirements:

 Extensive Standards Support: A message encrypted has to be eventually

decrypted. Similarly, when an application signs a message, at some point, this message has
to be verified to check for its integrity. WS-Security provides extensive standards support
to ensure that when a system performs a security operation, the inverse operation can be
performed by the receiving entity. A SOA Gateway intercepts secured messages from a
variety of consumers and has to perform inverse security functions on the
messages. Without an extensive standards-based implementation, the SOA Gateway would
fail to process messages from a broad array of consumers.
 Robust PKI Management: Encryption/Decryption and Signature/Verification are based on
Public Key Infrastructure (PKI). A SOA Gateway is required to support Key Life-cycle
Management such as Public-Private Key Generation, Enrollment and Revocation. For
hardened security, SOA Gateways also use Hardware Security Modules (HSMs) to protect
private keys used for message signature and decryption. Solid PKI Management coupled
with HSMs is a requirement for SOA Gateways deployed at the edge in a corporate DMZ. In
highly senstive SOA deployments within, for example, the Federal Government and Financial
institutions, only SOA Gateways that have been independently certified by non-commercial
 agencies should be considered. Hardware appliance-level FIPS and DoD/PKI are two
certifications that are strongly recommended.
 Performance Acceleration: Cryptographic operations necessary for encryption/decryption
and signature/verification are computationally intensive operations and cannot scale with
general purpose processors, specialized cryptographic processors are necessary. With a SOA
Gateway managing such operations for many service producers and consumers, using
hardware accelerators is required for a scalable architecture that does not add latency to
message processing.

Requiring developers to intertwine security policy code with their services is a failing long-term
strategy. It puts tremendous maintenance burdens on the service implementation and exposes SOA
to security risks as well as interoperability pitfalls. Separating security policies from a service
implementation and centralizing such policies using an intermediary SOA Gateway ensures that the
security holes are not inadvertently introduced by developers and the SOA deployment can be built
up rapidly by decoupling security processing tasks from the producer services.

IV. BEST PRACTICE: CONTROL AND AUDIT INFORMATION FLOW

Description: In a well-built SOA, business information flows effortlessly between applications. The
applications are not only internal applications - one of the key benefits of SOA is that external
partner applications can also be readily integrated with internal corporate systems for process
automation. This ease of information flow facilitated by a SOA puts significant message control and
audit requirements on the infrastructure including message filtering and message archiving
requirements. Message filtering ensures that nothing malicious enters a corporation through
SOAP/XML channels. Message filtering also prevents "information leak" by ensuring that classified
corporate information such as financial and customer information or top secret military/defense
information is not stolen or inadvertently sent over outbound SOAP/XML messages. In addition to
message filtering, corporations are mandated by regulatory requirements to archive and
store business transactions for auditing purposes. Regardless of regulatory mandates, it is a widely
instituted best practice to control inbound and outbound messages through filtering as well as
archiving selected messages for auditing purposes. As shown in Figure 3 below, a SOA Gateway
provides filtering and archiving functionality by intercepting SOAP/XML messages sent between
consumers and producers. The SOA Gateway intercepts and filters messages by performing deep-
content inspection of the SOAP/XML messages. Selected messages can then be archived to an
external RDBMS as a complete message or by extracting parts of the messages.
Figure 3: Enabling information control through filtering and archiving.

Benefits: Enabling information control through a SOA Gateways has significant benefits including:

 Consistency: By centralizing message filtering and archiving policies, a consistent set of

rules can be enforced across a SOA deployment for allowing or denying messages in and out
of a corporate network based on message payload. Messages can also be archived
consistently based on business data within a message.
 Security: SOA Gateways act as SOAP/XML Firewalls that inspect inbound messages for
malware and only let clean messages through. Through deep content inspection, SOA
Gateways provide security by ensuring that malicious content is kept out and sensitive
information is prevented from leaving corporate domains.
 Productivity: Deploying a SOA Gateway removes the burden of building filtering and
archiving functionality into consumer and producer applications. With simple, code-free
policy authoring for message control and archiving, SOA Gateway administrators can rapidly
author policies freeing developers to focus on building business functionality.

Requirements: SOA Gateways have to filter, control and archive messages between consumers and
producers seamlessly for messages traversing a SOA. For deploying filtering and archiving, a SOA
Gateway must meet the following requirements:

 Bi-directional Message Control: Both inbound and outbound SOAP/XML messages have to be
handled by the SOA Gateway. Typically, inbound messages are checked for malware,
validated and then archived to an off-board RDBMS. Outbound messages are usually
checked for sensitive information before they are permitted out of the corporate domain.
  Granular Message Capture: SOA Gateways should have the ability to capture full messages
and store them in an external database and also have the ability to select any element-level
information from a SOAP/XML message and store this information in the database as well.
 Flexible Configuration: SOA Gateways should provide a high degree of flexibility in
configuring policies for filtering and archiving messages. Message should be selected for
filtering and archiving on any criteria driven from message content. SOA Gateways should
be able to archive messages on arrival, at any stage of processing such as encryption,
signature or message enrichment and then archive processed messages again so that
multiple snapshots along the message processing may be captured for auditing and
analysis. One common best practice is to sign and store all inbound and outbound messages
for preserving a detailed message trail.

SOAP/XML messages can contain complex content including binary attachments that should be
scanned before allowing the messages to reach corporate back office systems that handle essential
business transactions. Similar to email systems that check for message size and content, SOA
Gateways should be deployed in a network to ensure that only good messages are permitted in and
that sensitive information that is not authorized to leave a corporation are prevented from leaking
out of corporate boundaries. Messages should be signed and stored through a robust archiving
process for ongoing auditing and data analysis.

V. CONCLUSIONS

A SOA Gateway is a core infrastructure component of a SOA with the ability to integrate services
securely. Typically deployed as a hardware appliance, a SOA Gateway seamlessly controls access to
services, protects information through data-level encryption, ensures the integrity of a message
through signatures, and controls corporate information flow. A SOA Gateway enables SOAP/XML
messaging across a variety of transport protocol such as HTTP, MQ Series, FTP, or JMS with protocol-
mixing amongst the protocols. In most deployments, SOA professionals choose to use SOA Gateways
as hardware-based network appliances primarily for the following reasons:

 Ease of Deployment: SOA Gateways are easy to install in a network as a snap-on

appliance. Appliance-based SOA Gateways eliminate the need to install software packages
and operating system patches and enable technologist to focus on configuring business
policies.
 Centralized Policy Management: SOA Gateways provide centralize policy management
removing the burden of security policies from service developers. Keeping such policies
separate from developers enables better on-going policy management, security and
developer efficiency.
 Superior Performance: Hardware-based SOA Gateways process SOAP/XML messages faster
than software based solutions. For resource-intensive processing such as message
encryption-decryption, signature-verification, filtering, transformation and access control,
 hardware-based SOA Gateways provide exceptional message throughput for enterprise-class
scalability.

SOA Gateways add significant productivity to project teams by providing code-free configuration of
policies and by freeing up development teams to focus on building core business functionality
instead of developing code for security policies, message control and service
aggregation. Enterprises serious about cutting costs and increasing revenue through service reuse
and rapid system-to-system integration must deploy a robust, secure and flexible SOA Gateway for
efficient message processing.

Virtues of WSDL Virtualization

WSDL virtualization is the ability to create a virtual WSDL from one or more predefined WSDLs files.
Typically, WSDL virtualization takes place across multiple back-end systems that expose their
operations through WSDL documents. An intermediary gateway sits between the producer and the
consumer and aggregates the WSDLs. Based on policies enforced on the gateway, operations are
exposed to the consumers. A sample deployment is shown below.

The virtues of WSDL virtualization include:

1. Security: The virtual WSDL can expose or hide some of the operations from the original
WSDLs. The WSDL endpoints are cloaked with only the intermediaries’ endpoints being
exposed.
2. Consistency: Virtualization allows selecting operations from multiple WSDLs and exposed
them to clients as a coherent single WSDL.
3. Productivity: The main benefit of virtualization is to be able to mix and match operations
without having to copy and paste parts of the desired WSDLs into new WSDL files. It allows a
customer to be able generate a library of all the operations supported on its organization
and only exposed the ones required for a particular customer.

Some of the challenges of WSDL Virtualization addressed by Sophisticated SOA Gateways, such as
Forum Systems Sentry include:
 1. Resolving different schemas that share the same namespace.
2. Multiple schemas might have different constraints for the same element that might be
incompatible.
3. Exposing the list of WSDLs that developers should be working on. Although external trading
partners typically require a single WSDL, internal developers work with multiple WSDLs. A
list of WSDL needs to be retrieved from the SOA Gateway to better manage developers
working across multiple WSDLs

WSDL Virtualization is a crucial part of deploying SOA. The vices of free-for-all operations can
quickly set chaos within a SOA deployment that can only be controlled through SOA Gateways that
provide strong WSDL virtualization.