Unlocking the Power of SOA Overcoming the obstacles Sung-Ik Son 손성익(孫聖翼) Senior Software Engineer firstname.lastname@example.org
Agenda • From XML to Web Services to SOA • XML의 중요성 • Web Services 의 의미와 XML • SOA (Service oriented Architecture) 와 Web Services • ESB (Enterprise Service Bus) 의 중요성 • Successful SOA Implementation • Obstacles of adopting SOA (SOA 도입상 취약성) • IBM Strategy against the Obstacles (취약성에 대한 IBM의 대책) • DataPower SOA Appliance 성공사례
From XML to Web Services to SOA - XML • XML data 는 the foundation layer of SOA data 를 표시 (platform neutral, universal data format, and self describing) • XML technology의 핵심이되는 주요 부분의 계속적인 specification 의 기반 • SOAP, WSDL, UDDI (WS standards) • XML Encryption, XML Signature (WS-security) • Within SOA, XML establishes the format and structure of messages traveling throughout services XML
From XML to Web Services to SOA – Web Services • An application that provides a Web API for interoperability • The API enables the software resource to act as a service and allows application to application integration using XML • SOAP • XML defines the content of a message • SOAP defines how the data moves from one place to another • WSDL (Web Services Description Language) • Schema for XML/SOAP objects and Interfaces • Contains XML schemas that describe the data so that both sender and receiver understand the data being exchanged • UDDI (Universal Description, Discovery, and Integration) • Publishing and discovering Web Services
From XML to Web Services to SOA - SOA • Interface is completely separated from the implementation • Provide Software as a service which promotes reuse and sharing by applications and organizations • Web Services enable to wrap legacy applications and turn them into shared services • Functionality is accessed by sending a request to the SOA application which it responds. • The applications now can be integrated with other applications and with trading partners • Using services as building blocks to build an application or process
ESB (Enterprise Services Bus) • A collection of runtime components that provides service intermediation such as routing, transformation, protocol bridging, management, security, and other control functions • ESB incorporates web Services and SOA into a meaningful architecture for integrating applications and services into a backbone that spans the extended enterprise in a large-scale fashion. • ESB makes Web Services, XML, and other integration technologies immediately useful with the mature technology that exists today.
Successful SOA Implementation • For SOA to be truly successful, it must build upon and remain in alignment with the underlying XML data representation architecture • Choose levels of standards based on comfort level with new technologies • Key standards: SOAP,WSDL,WS-*,HTTP, XML, JMS • Handling XML processing • Handling XML Schema, XML Transformations (XPATH, XSLT) • Handling XML based WS-security • Built-in functions • ESB application integration to allow different software systems to share or aggregate information. • Reuse existing services and infrastructure • Avoid a point-to-point services • Monitoring • Tooling support • Administration • Trouble shooting
Obstacles of adapting SOA • Scalability • XML is bandwidth, CPU, disk and memory intensive • Performance • Security • Standards Proliferation • Operations
Obstacles of adapting SOA • Performance • Layers of data processing • Web Services’ dependence on XML data • XML processing-related performance challenging • Web Services security XML processing • Web Services monitoring, auditing, and logging • XML transformations • HTTP Compression of Web Service Requests • Client Caching
Obstacles of adopting SOA • Security . • All the security and trust issues of the open Web infrastructure • Information security and message security issues • All the authorization and authority security issues • All new malicious threats need to be identified (DoS, SQL Injection, ..) • No consideration of WS-security will inevitably lead to expensive re-development • Acquiring a sound knowledge of the WS-security framework now will allow you to adjust your current architecture and application design to better accommodate upcoming changes
Web Services Security SSL is not the technology choice of the SOA but Message level security is. Transport and Session level – layer 4 and 5 SSL Point-to-pointEncrypt the sessiondeals only with the originator of the SOAP requester Application layer – layer 7 Authentication/Authorization – SAML, XACML WS-Security XML SOAP Message Encryption XML SOAP Message Signature Message level • Inserting security data into SOAP message • Transport independent and can be sent via any protocol • end-to-end security
Obstacles of adapting SOA • Standards Proliferation • Starting with an XML foundation architecture • Successfully propagating service-orientation across an enterprise imposes requirements, such as the disciplined application of open industry technology standards as well as the consistent usage of internal design standards. • WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation, WS-Authorization, WS-ReliableMessaging, WS-Addressing, WS-Transactions,… • XKMS, XACML, SAML,…
Obstacles of adapting SOA • Operations • Avoid SOA architecture like traditional distributed architecture • Complexity of SOA solutions continues to grow • Create a transition plan • SOA adoption is dominated by large organizations that tend to have a greater need for integrating applications and services across their businesses. • Large enterprises are also more often challenged with unforeseen and changing dynamics created by M&A (Mergers and acquisitions) activity, new partnerships, expansion, and new customer requirements.
IBM Solutions to the Obstacles • Scalability • Performance • Enhance XML processing through the XML Acceleration Appliance • Separation of the XML Processing from the Application • XML-to-binary for legacy application • XML-to-XML for interoperability • XPATH operations • XML parsing • XML Schema validation • Various types of WS-security • HTTP Compression of Web Service Requests • Client Caching • Security • Manage security in a centralized fashion across a number of web services applications through the XML security gateway • SOAP firewall - Message-level security & XML threat protection • Integrate with industry standard security • Standards Proliferation • WS-*, SOAP 1.2, MTOM, XOP • Operations • Complexity of SOA solutions continues to grow
An Unbeatable Combination from IBM • ESB: WebSphere ESB, a product that delivers an Enterprise Service Bus. • Advanced ESB: WebSphere Message Broker, a version of our proven product that delivers an advanced Enterprise Service Bus. • SOA Appliance: WebSphere DataPower Helps Solve XML, Web Services Challenges • IBM and DataPower redefine the boundaries of middleware extending the SOA Foundation with specialized, consumable, dedicated SOA appliances that combine superior performance and hardened security for SOA implementations Only IBM delivers the most comprehensive Enterprise Service Bus solutions to power your SOA! WebSphere Message Broker and WebSphere ESB Plus WebSphere DataPower:
WebSphere DataPower Characteristics Summary • XML processing • Parsing, Schema validation, transformation, routing • Security processing • XML security, Web Services security, interaction with 3rd party components • Support for a wide array of security standards • Hardware assist for both XML and encryption capabilities • Low latency processing • Innovative, appliance based implementation • Straightforward configuration • Ease of operation • Suitable for DMZ deployment • “Packaging in a single box” • No other software/hardware pre/co-reqs
SOA Appliance Successes through DataPower 데이터파워 성공사례
FTP to MQ Protocol Bridging • Multi-Protocol Gateway (MPGW) polls a ZIP file from a FTP server’s directory, extracts the DAT file and XML file from it, and checks such as schema validation and certain field value matching from both DAT file and XML. • After the successful validation, MPGW will separate the XML file into several smaller child XML files and send them to an MQ queue. • The back-end application consumes those XML files from the queue. • Error handling and Logging • successful acknowledgement with date format • Protocol conversion and handling • MQ Queue Manager or Manager groups
XML Data Transformation to COBOL copybook DataPower SOA Appliance Integration with IBM WebSphere MQ to access legacy data • The XML request is converted to COBOL copybook request. • The backend application will receive the COBOL copybook request, process, and return COBOL copybook response. • The COBOL Copybook response file will be converted to an equivalent XML response file. • Binary mappings through IBM WebSphere Transformation Extender (WTX) Design Studio. After developing and testing the mapping from WTX Design Studio the final mapping files will be uploaded to the DataPower for production. • Optimized any-to-any data transformation
XML Management Interface • The web interface will fetch the domain name and the expected command from the user input and then post the request to the XML firewall service inside the DataPower. • The XML firewall service will build a SOAP request message according to the specified command and then forward the request to the XML Manager Interface. • The XML manager Interface will accept the command request, execute it, and send back the SOAP response as the result of the command execution. • The SOAP response will be returned to the XML firewall service and the result will be returned to the web client. • Web GUI Interface including portal • SSL SOAP-based XML Management Interface – Manage device
LDAP Integration – Data Mapping and Masking • Web Services Security • Optimized XML processing • XML-to-XML transformation • LDAP Integration • Data Masking using Rule • Error handling <ind1:addressLineOne>FILTERED</ind1:addressLineOne> <ind1:city>FILTERED</ind1:city> <ind1:state>NC</ind1:state> <ind1:zipCode>FILTERED</ind1:zipCode> </ind1:address> </ind1:subsDemoGphs> <ind1:plnSpnsrs plnSpnsrCtr="?"> <!--1 to 20 repetitions:--> <ind1:planSponsor> <ind1:uniqueId>0000000002160655</ind1:uniqueId> <ind1:srcName>Pepsi, Inc.</ind1:srcName> <ind1:urlLinkType>?</ind1:urlLinkType> <ind1:subsCumbIdResults subsCumbIdCtr="?"> <!--1 to 20 repetitions:--> <ind1:subsCumbIdResult> <ind1:cumbId>123456789</ind1:cumbId> <ind1:historyEffDate>2008-07-28</ind1:historyEffDate> <ind1:subsNo>FILTERED</ind1:subsNo> <ind1:hmoMbrId>000000000GFT6R010</ind1:hmoMbrId> <ind1:hmoSrcdSSN>FILTERED</ind1:hmoSrcdSSN> <ind1:custMbrPlnSpnsrNo>7654321</ind1:custMbrPlnSpnsrNo>
Routing & Scalability - Dynamic Routing to Load Balance Group • Client application submits the SOAP request to WebSphere DataPower (WDP) SOA Appliance. • The SOAP request contains Username in the SOAP Header. • WDP will fetch the Username from the SOAP request and look for the matching destination load balance group URL. • Finally WDP will route the request to the destination load balance group. • The target load balance group will route to the appropriate server who is a member of the load balance group. • This simple scenario will be further enhanced to implement the real world situation.
Tibco Integration & Performance Measurement • Using JMS client tool, you will place a SOAP request message to an input queue owned by Tibco EMS server. • WS-proxy from the DataPower will pick up the SOAP request message and then start the timer logging before forwarding the message to the back-end external web services endpoint. • The SOAP response will return from the web services endpoint and WS-proxy will record the elapsed time before sending the response to the output queue owned by the Tibco EMS server. • Using the JMS Client tool, you will view and verify the SOAP response from the output queue. • Logging will be sent to the external syslog server and you will view the log from the syslog server.
Thank you 감사합니다