secure your soa

8/10/2019 Secure Your SOA

1/19


2/19

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 severaldepartments 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 abovementioned 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
http://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.html


3/19

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

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
http://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.html


4/19

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, XMLitself 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-XML-

aware 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 andXML.

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).
http://www.javaworld.com/article/2455358/cloud-computing/review-cloud-foundry-brings-power-and-polish-to-paas.htmlhttp://www.javaworld.com/article/2455358/cloud-computing/review-cloud-foundry-brings-power-and-polish-to-paas.htmlhttp://www.javaworld.com/article/2362021/architecture-scalability/microservices.htmlhttp://www.javaworld.com/article/2149243/cloud-computing/heroku-joins-other-paas-providers-in-supporting-php.htmlhttp://www.javaworld.com/article/2149243/cloud-computing/heroku-joins-other-paas-providers-in-supporting-php.htmlhttp://www.javaworld.com/article/2455358/cloud-computing/review-cloud-foundry-brings-power-and-polish-to-paas.htmlhttp://www.javaworld.com/article/2149243/cloud-computing/heroku-joins-other-paas-providers-in-supporting-php.htmlhttp://www.javaworld.com/article/2362021/architecture-scalability/microservices.htmlhttp://www.javaworld.com/article/2455358/cloud-computing/review-cloud-foundry-brings-power-and-polish-to-paas.html


5/19

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.


6/19

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. WS-

Policy 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-Policyprovides 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 never-

seen-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 aneffective and transparent manner.


7/19

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 intoprojects 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
http://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.htmlhttp://www.javaworld.com/article/2094847/enterprise-java/review-10-javascript-editors-and-ides-put-to-the-test.htmlhttp://www.javaworld.com/article/2077837/java-se/hello--osgi--part-1--bundles-for-beginners.htmlhttp://www.javaworld.com/article/2092260/java-se/java-programming-with-lambda-expressions.html


8/19

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 never-

seen-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 silosbuilt through years of software developmentthat addressed ever-evolving business


9/19

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 andprocesses.

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 compositedata 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 anaccessible 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 implementingthese 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

\


10/19

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 ageneral 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, differentauthorities 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 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 forbusinesses to wait for, and become actual bottlenecks.


11/19

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-to-

day 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, andindependent 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 GetBalanceservice can be designed to retrieve the balance for a loan. When aborrower calls in to query the status of a specific loan, this GetBalanceservice 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 tosupport binary transports only. The most important shortcoming of these approaches is that


12/19

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 beimplemented 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 pointhere 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.


13/19

What is Service-Oriented Architecture?

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

17:10 pm by Amit Satpute


SOA is an IT architecture strategy for business solution (and

infrastructure solution) delivery based on the concept of service-

orientation.

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.


SOA is an IT architecture strategy for business solution (and

infrastructure solution) delivery based on the concept of service-

orientation.

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.


14/19

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 usingJava technologies and using the Web Services in VB or .NET applications.


15/19

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 partnersto 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


16/19

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'vecreated 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.


17/19

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, andtherefore 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, WebServices is one of the key endpoints that can be called. Kyle and

others also mentioned JMS. In fact, you can have SOAP over HTTP, orSOAP 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.


18/19

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 WSDLservices 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. AnESBprovides 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 anddistribution 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 organizationalboundariesor 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 isan implementation technology and one of the ways to implement SOA. Youcan build SOA based applications without using Web servicesfor 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:Thetraditional middle-warestightly 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 acrossInternet. Can be more expensive and hard to use.
http://psm/esb/index.ssphttp://psm/esb/index.ssphttp://psm/esb/index.ssphttp://psm/esb/index.ssp


19/19

Web Servicessupport 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 rightskills 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 besimple (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 infrastructurethat 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.

secure your soa

Documents