Mary Hudachek-Buswell Wooyoung Kim Anjum Reyaz-Ahmed Spring 2009 1.

Mary Hudachek-Buswell Wooyoung Kim

Anjum Reyaz-Ahmed

Spring 2009

1

SOA Security Outline

1. Brief General Introduction to SOA2. Introduction into SOA Security3. SOA Security Problems and Three

Enhancement Solutions4. SOA Security Problem and Design

Solution

2SOA Security Introduction

Service, and Web ServicesTypes of Services

Windows Service RPC Locator, Event Log, DHCP Client

Software Service Distribution Service, Alert Service, Security Service, Log Service

Business Service Common Operational Picture, Navigation, Accounts Receivable,

Customers

Multiple services are connected via Web Services, and the service is the endpoint of a connection.

The service has an underlying computer system that supports the connection offered.


Service Oriented Architecture Service Oriented Architecture

Allows a collection of services to communicate each other and unifies processes by collecting smaller service modules in an ad hoc manner.

Operational – a set of agreements between service consumers and providers that specify the quality of service

Implementation – uses a standards based infrastructure, programming model, and technologies (Web Services)

Architectural – architecture style that supports service orientation

Business – defines a set of services composed to capture the design the enterprise wants to expose internally, and externally to customers and partners

Architectural Principles: encapsulation, loose coupling, contract , abstraction, reusability, composability, autonomy, optimization, discoverability


5SOA Security Introduction Figure from Understanding SOA Security Design and Implementation by IBM Redbooks

6SOA Security Introduction Figure from Wikipedia

Tree Diagram of SOA

Service Composition

7SOA Security Introductionhttp://www.radware.com/uploadedImages/Solutions/Enterprise/Data_Center/

DC_SOA_Diagram

SOA TimelineExtensible Markup Language (XML)

Created using Standard Generalized Markup Language of 60s

Web ServicesSimple Object Access Protocol (SOAP) specification in

2000 triggers Web Services, Existing messaging platforms incorporate Web Services to support SOAP

SOA entersEarly model of SOA components by Web Services

standards: service requester, service provider and service registry

WSDL - Web Services Definition Language UDDI - Universal Description, Discovery, and Integration

SOAWS-* : second generation of SOA standards,

extending specific functionalities.8SOA Security Introduction

Performance

Availability

Usability

Security

End User’s view

Developer’s view

Businessview

A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software A list of quality attributes exists in ISO/IEC 9126-2001 Information Technology – Software Product Quality Product Quality


SOA Security, System Quality Attributes

Maintainabili

ty

Portability

Reusability

Testability

Time to Market

Cost & Benefits

Projected

lifetime

Targeted market Integration with

Legacy System Rollback

Schedule

Identification AuthenticationAuthorizationPrivacyConfidentialityIntegrityAvailabilityAuditing


SOA Security Requirements

Single-sign-onDo not want to sign-on every time of requestOnce authenticated by a service provider, no sign-on

process for the connected providerTransport level security

Point-to-point protectionOnly protects the message during transit between service

endpoints. (Secure Sockets Layer)Message level security

End-to-end message protectionNeed digital signature and encryption.


SOA Security Characteristics

Encryption and digital signaturesRealize the message-level confidentiality.XML-encryption

cornerstone part of the WS-Security framework. Applied to parts of a SOAP headers or body.

XML-Signature ensure message integrity. Reside in the SOAP header when signing a document.

Message level security is a core component of service-oriented solution.

WS-Security framework fulfill fundamental Quality of Service requirements that enable enterprises toRealize Service-oriented solution for the processing dataRestrict service access as required.


SOA Security Characteristics

figure by Rahaman et al13SOA Security Introduction

Requester of a service Intermediary

Web service

Security Context Security Context

Figure : Point-to-Point ConfigurationTransport Level Security

Figure : End-to-End ConfigurationMessage Level Security

Security Context

SOA Basic Message Security


SOAP Clien

t

SOAP Handler

Banking Service

Validate

Authorize

New Token

Security Token

Service

Transaction

Gateway

Application

1

2 3

4 5

Database

RACF

6

7

89101

1

Web Application Server

An inline approach for secure SOAP requests and early validation, by Rahaman, M.A.a.M., Rits and Schaad, 2006.

Problem: Despite of various standards such as WS-Security with WS-Policy for the message level security, certain attacks such as XML rewriting still happen. In addition, the generation and validation of the key security mechanism are necessary.

Solution: Include SOAP Account (SOAP Structure information) in outgoing SOAP messages and validate this information before policy driven validation in the receiving end.

Security Enhancement[1]

slide by Rahaman et al17SECURITY ENHANCEMENT 1

Realization of WS-Security and Related standards


WS-Policydescribes the capabilities and constraints of the security (and other business) policies on intermediaries and endpoints (e.g. required security tokens, supported encryption algorithms)

WS-SecureConversationdescribes how to manage and authenticate message exchanges between parties including security context exchange and establishing and deriving session keys

RequesterWeb

Service

Security Token

Service

Policy

Security Token

Claims

Policy

Policy

Security Token

Claims

Security Token

Claims

WS-Securityhow to attach signature and encryption headers to SOAP messageshow to attach security tokens, including binary security tokens such as X.509 certificates and Kerberos tickets, to messages

WS-Trustdescribes a framework for trust models that enables Web services to securely interoperate

Architecture of Web Services Security


<Envelope> <Header> <Security> <UsernameToken Id=1> <Username>“Alice" <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" <Signature> <SignedInfo> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#2> <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> <Body Id=2> <StockQuoteRequest> <symbols> <Symbol>“SAP" <Symbol>"ORACLE"

UsernameToken assumes both parties know Alice’s secret

password p

Securing SOAP Messages

Each DigestValue is a cryptographic hash of the

URI target

hmacsha1(key, SignedInfo) where

keypsha1(p+nonce+created)

<Security> header defined by

OASIS WS-Security includes

identity tokens, signatures, encrypted

message parts

<Envelope> <Header/> <Body Id=2> <StockQuoteRequest> <symbols> <Symbol>“SAP"

<Symbol>“ORACLE"

</Envelope>

Soap Message to send Soap Message after addition of Security Header

N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.


Message Flow using WS*Standards

3.Sending to Policy Module

4. Sign/Encrypt & send SOAP message to web service

Web Service Requester

Web ServiceProvider

Security Token service2. Get tokens to add to SOAP messages

7. Receive response from Web Service

Figure: Typical message flow between web services using WS-Security

Incorporating WS-Policy in

SOAP

6. Validate tokens

Checking SOAP according to WS-

Policy

5.Enforcing WS-Policy

1. Request for tokens


XML Rewriting Attacks


A Signed SOAP Message Before...

<Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Rahim</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <Body Id=1> <TransferFunds> <beneficiary>Karim</> <amount>1000</>

Message to bank’s web service says: “Transfer

$1000 to karim, signed by Rahim”

Bank can verify the signature that has

been computed using key derived

from Rahim’s secret password

N.B All the SOAP messages here eliding some headers, all namespaces, and abbreviating long strings for brevity.


and After an XML Rewriting Attack<Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Rahim</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/>

Although Rahim’s password has not been broken, the message now reads “Transfer

$5000 to Charlie, signed Rahim”

Charlie(Attacker) has intercepted and rewritten

this message

The indirect signature of the body, now hidden in BogusHeader, may

still appear valid

<BogusHeader> <Body Id=1> <TransferFunds> <beneficiary>Karim</> <amount>1000</><Body> <TransferFunds> <beneficiary>Charlie</> <amount>5000</>


25

Conceptual Solution and Proposed Technique

slide by Rahaman et alSECURITY ENHANCEMENT 1

Conceptual SolutionAfter carefully observing the rewriting attacks the

following things are obvious:

All attacks are some kind of modification of SOAP message.The intended predecessor or successor relationship of the SOAP element is lost consequently.The number of predecessor, successor, and sibling elements of a SOAP element where the unexpected modification occurs is changed and thus the expected hierarchy of the element is modified as well.


SOAP Account

SOAP Account

Number Of Child Elements of Envelope

Number Of Header Elements in SOAP Header

Successor And Predecessor Relationship of Each Signed Object

Number Of References in each signature Element

Parent Element

Sibling Elements

Sucessor And Predecessor Relationship

Extentsion For Future

Figure : SOAP Account

At the time of sending SOAP message we can always keep an account of SOAP elements by including SOAP Account into the message:

Number of child elements of root.Number of header elements.Number of references for signing

element.Predecessor, successor, and

sibling relationship of the signed object.……….

The sender must sign the SOAP Account Information.

SOAP Structure/Account keeps the record of a SOAP message’s structure of elements.


Message Flow in Proposed Technique


5. Sending signed message with SOAP Account Information


6. Received SOAP message


Web ServiceProvider


4. Sending SOAP message to SOAPAccount module


Figure: Message flow using new approach between web services

Adding SOAP Account Info

Validating SOAP Account Info

Incorpor-ating WS-Policy in

SOAP


Policy


8. Validate tokens


A SOAP message after SOAP Account<Envelope> <Header> ………… <Security> <UsernameToken Id=3> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI=

#1><DigestValue>Ego0...</> <Reference URI=

#2><DigestValue>Qser99...</> <Reference URI=

#3><DigestValue>OUytt0...</> <SignatureValue> vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference

URI=#3/> <SoapAccount id=2> <NoChildOfEnvelope>2</> <NoOfHeader > 2 </> </SoapAccount><Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</>

Message to bank’s web service says:”Transfer1000 euro to Bob,signed Alice”

Verifying signature using key derived from Alice’s secret password


SOAP request after an attack<Envelope> <Header> ……………. <Security> <UsernameToken Id=3> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <Reference URI= #2><DigestValue>Qser99...</> <Reference URI= #3><DigestValue>OUytt0...</> <SignatureValue> vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#3/> <SoapAccount id=2> <NoChildOfEnvelope>2</> <NoOfHeader > 2 </> </SoapAccount> <BogusHeader> <Body Id=1> <TransferFunds> <beneficiary>Bob</>

<amount>1000</><Body> <TransferFunds> <beneficiary>Bob</> <amount>5000</>

Attacker has intercepted the message

This reference is not valid anymore because No ofheader is not 2. After attack it is 3

Attacker has added a BogusHeader& included the Body

Amount has been changed to5000 by the attacker


Towards Secure SOAP Message Exchange in a SOA, by Rahaman, M.A.a.M., Rits and Schaad, 2006.

Problem:

The SOAP Account itself is vulnerable to XML rewriting attacks.

Solution:

Routinely check SOAP Account as soon as the SOAP message arrives.

Security Enhancement[2]

31SECURITY ENHANCEMENT 2

Attacks against SOAP Account


A SOAP Msg with SOAPAccount Before...<Envelope> <Header> <Security> <UsernameToken Id=1> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <Reference URI= #2><DigestValue>Oser99...</> <Reference URI= #3><DigestValue>OUytt0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#1/>

<SoapAccount id = 2> <NoChildOfEnvelope>2</> <NoOfHeader>2</></SoapAccount>

<Body Id=3> <TransferFunds> <beneficiary>Bob</> <amount>1000</>

Message to bank’s web service says: “Transfer

$1000 to Bob, signed by Alice”

Verifying signature using key derived from Alice’s secret

password


<Envelope> <Header> <Security> <UsernameToken Id=1> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <Reference URI= #2><DigestValue>Oser99...</> <Reference URI= #3><DigestValue>OUytt0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#1/> <BogusHeader>

<SoapAccount id = 2> <NoChildOfEnvelope>2</> <NoOfHeader>2</></SoapAccount>

<Body Id=3> <TransferFunds> <beneficiary>Bob</> <amount>1000</>

After an attack…

SoapAccount is not a SOAP header

anymore


Conceptual Solution to Attacks Against SOAP Account

Routinely check CheckSOAPAccount Module in the previous model

First check if the SOAP message contains SOAP AccountThen the module will verify the signature of the SOAP AccountIf several intermediaries have their own SOAP Account, then there will be a nested signature. After verified, CheckSOAPAccount module do the rest of check as before.


Message Flow in Proposed Technique


5. Sending signed message with SOAP Account Information


6. Received SOAP message


Web ServiceProvider


4. Sending SOAP message to SOAPAccount module


Figure: Message flow using new approach between web services

Adding SOAP Account Info

Validating SOAP Account Info

Incorpor-ating WS-Policy in

SOAP


Policy


10. Validate tokens

7. Check if the message has SOAP Account information.

8. Verify the signature of SOAP Account


Other ScenariosEven if the attacker provides its own SOAP Account, it will not match to the existing <Security> header.Even if the attacker insert new <Security> header, then CheckSOAPAccount module will check it by matching with existing <Security> header.Moreover, the nested signature feature of SOAP Account will make things harder the attacker to forge the SOAP Account.


Security Problem

Why Applying Standards to Web Services Is Not Enough, by JOHN VIEGA and JEREMY EPSTEIN, 2006

Service Oriented Architecture(SOA) – Security Challenges and Mitigation Strategies, by Cecilia Phan, 2007


PitfallsSecurity Standards might not be secure

Using the wrong standard

Ignoring what the standard doesn’t do


The Role of Security StandardsStandards leave several of the authentication choices up to the

individual system administrator; because requirements vary widely between organizations, some of them opt for low-security solutions like passwords, whereas others rely on biometrics, RSA SecurID, or other hardware solutions.

Those creating the standards are more concerned with providing the tools necessary for achieving common assurance levels in an interoperable manner, and not on providing the highest levels of assurance

Standards only give us a framework for achieving common security goals, but we should expect that we will have to do some work to realize this assurance in real world systems.


Problems with XMLXML is a very verbose language

Overwhelming bulk of data will be tags instead of data

XML’s flexibility is also its Achilles‘ heel from a security standpoint.

XML’s signature is problematic since XML parse is free to change the formatting of the data.

To avoid this we can use canonicalization which will ensure that two versions of the same message formatted different will yield identical results

XML –Encryption suffers due to need to buffer the complete document which might cause Denial of Service(DoS) attack


Problems with SAMLMechanism for preventing some of the weakness are

optional It is a good authorization mechanism but falls short in

authentication mechanism

Problems with Single Sign On(SSO) SSO is a “token granting” authentication mechanism where

a requester is supplied with a token that indicates that he has successfully authenticated to an identity server ‘at a particular time and via a particular authentication method’

Does not work well in loosely coupled system such as SOA

Shared cryptographic keys providing protocol such as Group Secure Association Key Management(GSAKM) and Kerberos must be used instead

SECURITY ENHANCEMENT 3 42

Security Enhancement[3]Use of Data Mining to Enhance Security

for SOA by Yamany and Capretz, 2008

Problem : Security standards alone are not enough

Solution : Data mining model to predict attacks

from SOAP messages and for validating new security policies.


The SOA Security Framework


Security Specification Layers

Both security service layer and message security layer are the basis for this enhancement

They aim to provide dynamic decision point and the security service in order to predict and disable an attack from SOAP

This is done by an intelligent engine that makes use of data mining


Data Mining and SOA SecurityProcess of analyzing data from different

perspectives and summarizing into useful information.

Techniques used in data mining – decision trees, neural network and association rules. Association rule technique is used here.

In this paper they use it to enhance the construction of web services security and its related policies in SOA environment.

SECURITY ENHANCEMENT 346

Three Benefits of Using Data MiningA Potential attack can be predicted during the

receipt of SOAP messages, based on its size and parsing time.

Classify the service customer based on their request message. Three rating are given to customers

Clean Suspect Prohibited

Validate a new security policy before deploying SECURITY ENHANCEMENT 3 47

Security Service for SOA


Mining ModelThe prototype is constructed by using association rules

mining model in SSDM ( SQL Server Data Mining 2005)

Two different models are prototyped for the two attack categories

Based on the time taken to parse a message a “Message Alternation” attacks can be predicted

Based on message size “ Message Eavesdropping” can be predicted

Each rule has two factors

Probability

ImportanceSECURITY ENHANCEMENT 3 49

Summary and Future workThe core uses data mining to predict the various

web attacks to which the web services with the SOA environment are subjected as they receive the incoming SOAP messages

The mining model is used to validate the new security policies which are managed using WS-Security Policy

This work need to be corroborated in a business environment in order to determine its accuracy.

Mining model needs sufficient training data in order to achieve greater and more efficient results.


Security Design [1] Methodology and Tools for End-to-End

SOA Security Configuration, by Satoh, Nakamura and Mukhi, 2008

Problem: Configuring security requirement properly is quite difficult for developers due to cross-domain nature of SOA security

Solution: A new Model-Driven Security and Pattern

Based Policy configuration

51SECURITY DESIGN 1

Application Development Process

1. A business analyst creates business process model

2. A software architect designs service assemblies to satisfy the business requirement and creates the service model

3. A developer develops and tests atomic services

4. An assembler assembles the atomic services to implement the application according to the service model

5. A developer deploys the application to the platform

52SECURITY DESIGN 1

End-to-End Security Configuration1. A business analyst is responsible for clarifying the

business-level security requirements, as a business-level policy

2. A software architect creates a service model to satisfy the business process model and hence the security requirement for the composite services should be specified in the service model.

3. An assembler creates security configuration files for each atomic service to meet the security requirement from phase (2)

4. A deployer sets up the platform that runs the services for secure service execution and deploys the configuration to the platform

53SECURITY DESIGN 1

Supporting TechnologyModel-Driven Security (MDS)

To generate concrete security configuration files by model transformation from the abstracted security requirements specified by a software architect.

Pattern-based PolicySupports a software architect in specifying the

security requirements on the composite services.

54SECURITY DESIGN 1

Model Driven Security Configuration

55SECURITY DESIGN 1

Model Driven Security ConfigurationA business analyst defines the business-level

security requirements

Software architect creates service model and adds intents, which are abstract keywords representing security requirements, to each service in the model

The intents are transformed into concrete security configuration by model transformation executed by assembler

Security infrastructure model(SIM) which is created by deployer and SIM is referred to when concrete configuration are generated

56SECURITY DESIGN 1

Pattern Based Policy ConfigurationSOA application has recursive structure, because

of this the architect needs to pay attention to the intents of the lower level components when adding intends to higher level components.

To solve this problem they propose Pattern based policy, which is a framework to define intent patterns for component assemblies.

Now the architect adds patterns instead of intents

57SECURITY DESIGN 1

ConclusionWeb Service Security is becoming the main focus of

SOA research and development.In enhancement 1 & 2, the concept of an SOAP

account increases the depth of security within SOA.In enhancement 3, the concept of data mining of

SOAP messages strengthens the policies within SOA breadth wise.

Lastly we discussed security configuration design for SOA application development.

We would like to acknowledge the individuals at IBM who provided the demo and other documents for our research Link to the IBM presentation : http://www.ibm.com/developerworks/offers/lp/demos/summary/saassecurity2.html

58

AcknowledgementsMary Taylor, Senior IT Architect, IBM Mahmoud A Badawi, Software IT Architect,

IBMMohamed Ibrahim, Software Engineer-

Application Developer

59

References1. Andrew, R., M. Alexandre, and S. Abdulmotaleb El. Security Considerations for SOA-Based Multimedia Applications. in

Multimedia, 2006. ISM'06. Eighth IEEE International Symposium on. 2006.2. Bertino, E. and L. Martino. Security in SOA and Web Services. in Services Computing, 2006. SCC '06. IEEE International

Conference on. 2006.3. Bertino, E. and L.D. Martino. A Service-oriented Approach to Security - Concepts and Issues. in Autonomous Decentralized

Systems, 2007. ISADS '07. Eighth International Symposium on. 2007.4. Buecker, A., et al., Understanding SOA Security, Design and Implementation. 2007, Redbooks, IBM.5. Cecilia Phan, L.L., Rod Fleischer. SERVICE ORIENTED ARCHITECTURE (SOA) – SECURITY CHALLENGES AND

MITIGATION STRATEGIES. in Military Communications Conference, 2007. MILCOM 2007. IEEE. 2007. Orlando, FL: IEEE Computer Society.

6. Erl, T., ed. Service-Oriented Architecture : Concepts, Technology, and Design 2005, Prentice Hall.7. Imamura, T., et al., Web services security configuration in a service-oriented architecture, in Special interest tracks and

posters of the 14th international conference on World Wide Web. 2005, ACM: Chiba, Japan.8. Kodali, R.R. (06/13/2005) What is service-oriented architecture? An introduction to SOA. JavaWorld.9. Maarten Rits, M.A.R. Secure SOAP Requests in Enterprise SOA. in Twenty-Second Annual Computer Security Applications

Conference (ACSAC). 2006. Miami Beach, FL: Annual Computer Security Applications.10. Mohammad Ashiqur Rahaman, M.R., and Andreas Schaad. Inline Approach for Secure SOAP Requests and Early Validation. in

European Conference on Open Web Application Security Project (OWASP). 2006. Leuven, Belgium.11. OASIS, Web Services Security:4 SOAP Message Security 1.1 (WS-Security 2004), in OASIS Standard Specification, . 2006,

OASIS, Organization for the Advancement of Structured Information Standards: http://docs.oasis-open.org/wss/v1.1/. p. 76.12. Rahaman, M.A., A. Schaad, and M. Rits, Towards secure SOAP message exchange in a SOA, in Proceedings of the 3rd ACM

workshop on Secure web services. 2006, ACM: Alexandria, Virginia, USA.13. Satoh, F., et al. Methodology and Tools for End-to-End SOA Security Configurations. in Services - Part I, 2008. IEEE Congress

on. 2008.14. Sprott, D., Wolkes, L., (2004) Understanding Service-Oriented Architecture. Microsoft Architect Journal.15. Viega, J. and J. Epstein, Why applying standards to Web services is not enough. Security & Privacy, IEEE, 2006. 4(4): p. 25-31.16. Yamany, H.F.E.L. and M.A.M. Capretz. Use of Data Mining to Enhance Security for SOA. in Convergence and Hybrid

Information Technology, 2008. ICCIT '08. Third International Conference on. 2008.17. Service-oriented architecture. 2009; Available from: http://en.wikipedia.org/wiki/Service-oriented_architecture.

60

Mary Hudachek-Buswell Wooyoung Kim Anjum Reyaz-Ahmed Spring 2009 1.

Documents

Transcript of Mary Hudachek-Buswell Wooyoung Kim Anjum Reyaz-Ahmed Spring 2009 1.