Thinking Beyond....
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
781
On Slideshare
781
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Thinking Beyond.... Making the Enterprise Service Bus address demanding Infrastructure Requirements  
  • 2. Agenda
    • SOA, ESB, Web Services Refresher
      • Architecture
    • Enterprise Web Service Services
      • Security, reliability
    • ESB Extension Services
      • High availability, Management
    • Amberpoint SOA Management
    • Organizations and Futures
    • Q&A
  • 3. What is SOA? Service Oriented Architecture Service System capabilities that provide access to functions and data are appropriately exposed to other components (applications, devices, networks, etc.) Oriented Uses “open” interoperability protocols Architecture In its purest form, it’s the connection of systems (simple or complex)
  • 4. W3C – What is a Web Service? Source: W3C Working Group Note 11 February 2004 http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/
      • “ A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”
  • 5. ESB as Infrastructure for SOA
    • “ An Enterprise Service Bus (ESB) is software infrastructure that enables SOA by acting as an intermediary layer of middleware through which a set of reusable business services are made widely available.”
    Forrester Research Source: Mike Gilpin, Forrester Research, August 2004
  • 6. Realizing SOA with Web Services
    • Web Services are an economical way to build SOA
      • Cost-centric – largest IT cost is labor
        • Simple technology, short learning curve
        • Standards minimize the risk of vendor lock-in
        • Web services are inexpensive, no huge initial investment
      • Integration-centric
        • Instead of just doing yet another point-to-point integration between two applications, you can build a set of services that can be used by other applications in your enterprise
      • Process-driven
        • Web services can be used to define processes in an SOA
      • Reuse-centric
        • Web services can easily wrap and thus enable reuse of existing computing services and applications
  • 7. SOA and Web Services
    • SOA does not need Web Services
    • Not every Web Service is based on SOA
    • BUT
    Through 2008, SOA and Web Services will be implemented together in more than 75 percent of new SOA or Web Services projects (0.7 probability)
  • 8. Government SOA Potential
    • Integration across government and public sector boundaries
    • Procurement - Enterprise data integration
    • Licensing Applications - Collaborative, distributed application development and deployment
    • E-Receipts - Enterprise service sharing
    • Tax Calculation - Enterprise enablement of common business processes
    • Criminal Background Checks - Enterprise service sharing
  • 9. Basic Web Services Technologies Review
    • XML Technologies
        • “ Extensible Markup Language”
        • Base XML for documents
        • XML Schema for describing XML documents
    • SOAP
        • A simple way to send documents (some people have called it “email for documents”)
        • How to format XML documents for transmission
    • WSDL - Web Services Description Language
        • Defines implementation details about a service
    • UDDI - Universal Description, Discovery and Integration
        • Store, advertise and discover services
  • 10. Basic Web Services Architecture XML documents within SOAP messages defined by WSDL discovered via UDDI
  • 11. How will all of this work? A Web Services Infrastructure WS Client WS Server XML document XML document Web Service SOAP Support SOAP Support SOAP message SOAP message HTTP Support over network
  • 12. What is the Web Service Server Doing?
    • The typical server pattern:
      • (passively) wait on arriving XML documents contained within a SOAP envelope
      • Extract and analyze the document
      • Interact with other software components to complete the processing of the document
      • Optionally: return another XML document in response
    Web Service SOAP Request SOAP Response server
  • 13. Enterprise Web Services
    • Extending WS throughout the enterprise and among enterprises  greater emphasis on Qualities Of Service (QoS)
        • Security, Reliability, Transactions, Scalability
        • Systems Management, Policy, Metadata Management/Governance
        • Interoperability
    • It’s also important to support multiple transports and data formats (other than SOAP over HTTP):
        • IIOP & RMI
        • WebSphereMQ
        • TIBCO Rendezvous
        • Tuxedo
        • FTP
        • JMS
  • 14. How will all of this work? A Web Services Infrastructure JMS HTTP Tuxedo TX Mgmt Security WS Client WS Server XML document XML document Web Service SOAP Support SOAP Support SOAP message SOAP message Support over network
  • 15. Industry organizations
    • Developing Web services standards
      • W3C
        • XML, SOAP (XMLP working group), WSDL , WS - Addressing, WS-Choreography, Semantic Web Services
      • OASIS
        • UDDI, WS-Security, WS-Reliable Exchange, WS-Transactions, WS-CAF, WS-Notification, WS-Secure Exchange, etc.
      • JCP (Java Community Process)
        • JAX-RPC, JWSDL, JAXM, JAXR, …
      • WS-I
        • Basic profile, security profile, etc.
      • OMG
        • IDL to WSDL, WSDL to IDL (WSDL 1.1), WSDL to C++
  • 16. Eclipse-Based GUI - WSDL
    • Eclipse-based UI for both Artix and Artix for z/OS
    • Leader in Eclipse SOA Tooling Project
  • 17. Extending WSDL Contracts Logical Contract Physical Contract WSDL
    • Logical contract defines
      • data types
      • messages
      • operations
    • Physical contract defines:
      • data formats
      • transports
    Bindings SOAP XML Bindings Transport Service HTTP Transports IIOP JMS Bindings SOAP CORBA
  • 18. Screen shot of WSDL file
  • 19. Web Service Technologies Relationships Run time vs. Design Time WSDL Specifies … Operations, Structure and Typing of Messages Encoding And Transport of Messages Physical Endpoint Service Communications Requirements: Design and Deploy time XML Schema E.g., HTTP Client Web Service SOAP Request SOAP Response XML Runtime execution
  • 20. Security
    • Confidentiality – no one can see my data
    • Integrity – my data gets there in one piece
    • Authentication – a user or program is confirmed to be who they say they are
    • Authorization – ensuring access to services and data only by those who are supposed to access them
    • No overall architecture yet defined
      • May include firewalls, proxies, security servers, and identity management
    • WS-Security is a well-agreed framework (OASIS)
    Security
  • 21. Extending WSDL Contracts – Enterprise Services Logical Contract Physical Contract WSDL Reliability required – Y/N Transactions required – Y/N Kerberos supported – Y/N Other SLAs Bindings SOAP XML Bindings Transport Service HTTP Transports IIOP JMS Bindings SOAP CORBA
  • 22. Eclipse-Based GUI – Adding basic security
  • 23. SOAP Header example (WS-Security) <S11:Envelope xmlns:S11=&quot;...&quot; xmlns:wsse=&quot;...&quot; xmlns:wsu=&quot;...“ xmlns:ds=&quot;...&quot;> <S11:Header> <wsse:Security xmlns:wsse=&quot;...&quot;> <fabtok:CustomToken wsu:Id=&quot;MyID&quot; xmlns:fabtok=&quot;http://fabr123/token“ /> <ds:Signature> . . . </ds:Signature> <ds:SignedInfo> . . . </ds:SignedInfo> </wsse:Security> </S11:Header> ... </S11:Envelope> Security
  • 24. Reliability requirements
    • Reliability of message delivery is critical to many applications
      • Guarantee of message delivery (both request and response)
        • At least once (duplicates are allowed)
        • At most once (“best effort”, ok to drop some messages)
        • Once and only once – the toughest to guarantee!
      • Eliminate duplicates (if any)
      • Preserve message ordering (when important)
    • Some of these features are provided as standard when WS are carried on a connection-oriented protocol
      • The “sessions” and correlation IDs of the connection-oriented protocol ensures features such as ordering
      • But some QoS must still be added (e.g., store-and-forward to allow clients to send messages even if a server isn’t running)
    Reliability
  • 25. Example message flow: WS-ReliableMessaging) Reliability
  • 26. Web Services Composition
    • Once you have a “critical mass” of Web services, you may want to:
        • link them together to create (composite) complex Web services
        • implement whole business processes based on those services
    • Of course you can “hard-code” this, but the result is
        • inflexible (hard to maintain)
        • proprietary, not explicit (business logic will be buried in code)
    • Better: Standardized high-level mechanisms
        • Standardized declarative, non-programmatic way to compose sequences of web service calls to accomplish a business function
    • Efforts ongoing to provide
        • WS-BPEL (seems to be winning at present) for run-time
        • WS-Choreography (more B2B oriented) between partners
    Composition
  • 27. Orchestration Architecture Adapters Message queuing system – A2A/B2B Integration broker Other applications Database tables and stored procedures ERP, CRM, Accounting, etc. Web service interfaces Composition Often, you have selection and loops as well just sequencing This overall sequence is viewed as a WS from outside You can also do transformation of data within the overall sequence
  • 28. Interoperability Requirements
    • Within the enterprise and among enterprises
      • Across hardware platforms, operating systems, programming languages, middleware and component technologies
    • SoapBuilders and WS-I have been working to correlate the many WS standards into more interoperable configurations. E.g.,
      • Defining a consistent selection of standards
      • Subsetting (“profiling”) a standard
    • Ensuring compatible message encoding is another key part of interoperability
      • As discussed in the new few slides
    Interoperability
  • 29. You have a choice of the encoding for complex data in msgs
    • The WS-I recommendation is literal
      • This uses XMLSchema in the normal way
        • The message references a schema that defines the elements and types for formatting arrays, sequences, records/structures, and other complex types
        • The message uses these elements and types
    • The alternative is SOAP encoded
      • This defines a set of elements that can be used for complex data
        • Mostly, these elements were good at formatting data that typically arises in RPC calls
      • It was first introduced before XMLSchema was available
        • Harder to achieve broad interoperability
        • Especially when using more complex data types
  • 30. You also have a choice between two message styles
    • The choice is rpc or document
      • document style is recommended by WS-I
      • many existing Web services use rpc style)
    • Operation have input and (optional) output messages
      • In rpc style, each message can have zero or more parts
        • <message name=“getQuoteRequest”>
        • <part name=“symbol” type=s:string”>
        • <part name=“date” type=“s:string>
        • </message>
      • In document style, each message have one part
      • An XML element, not a type
    WS-I has yet to profile SOAP 1.2
  • 31. Location Transparency Service
    • Artix Locator - WSDL-based Naming/Location Service
    • Dynamic, high performance service registration
    • Automatic service lookup adapts to:
        • Machine failures
        • New service instances
        • Site/server reconfiguration
    • Services automatically registered with the Locator upon start-up
    • Multiple instances of the same service can be registered to support load balancing and failover
  • 32. HOST Location Transparency Service Look-Up Artix Locator High Performance C++ Web Services Wide Client Diversity Bind Publish Publish Publish Artix Web Service Artix Web Service Artix Web Service
  • 33.
    • Technical Need:
      • State-full client / server interaction
      • Context management
    • Support in Artix:
      • Locator Service
        • Service Discovery
        • Session manager plug-in provides session context across calls and instance policies
    (3) Invoke (2) Lookup .NET, web services application or IIS/JSP Artix Enabled Server Session management interceptor plug-ins (1) Publish Stateful Session Service Locator
  • 34. Management Services – Runtime
    • Integration with Enterprise Management Services
    BMC Patrol IBM Tivoli HP Openview CA Unicenter
  • 35. Improved Eclipse-Based GUI
  • 36. Not to be confused WITH… Amberpoint SOA Management
  • 37. Runtime Governance of SOA Systems © 2006 AmberPoint, Inc.
  • 38. Wide Variety of Infrastructure for SOA Environments Mission Related Services Data Warehouse EJB Applications Analysis Services ( Purchased COTS ) Agency Portal Inter- Agency Services Enterprise Service Bus Inter- Agency Services DBMS
  • 39. End-to-End Services Management Inter- Agency Services Inter- Agency Services Data Warehouse EJB Applications Agency Portal DBMS <soapenv:Envelope xmlns:soapenv=&quot;http://schemas.xmlsoap.org/soap/envelope/&quot;> <soapenv:Body> <po-number> A234235 </po-number> </soapenv:Body> </soapenv:Envelope> Mission Related Svc Analysis Services Enterprise Service Bus Client App
    • SOA and Related Components
    Regardless of SOA Infrastructure Decisions
    • Visibility
    • Control
    • Validation
  • 40. Automatic End-to-End Visibility
    • Visibility into major SOA components…
      • Available services, endpoints, & containers
      • Instant overview of traffic throughput and availability
    • And into supporting components…
      • Databases
      • JAX-RPC and JMS messaging
      • EJBs
      • ESBs
      • Custom, user-defined interceptors
    • Dynamic discovery
      • Finds services deployed in the environment
      • Locates services even if they’re not in the registry
    • Dependency tracking
      • Non-invasively tracks actual interactions to determine dependencies
      • Displays relationships and potential impact
    Visibility across the complete SOA infrastructure is the required in all cases.
  • 41. AmberPoint Policies – What to Do, When, How?
    • Everything in AmberPoint implements Policies - Measurements, Exceptions, Availability and Capacity, Logging, Security. Examples:
      • All Mission Related Messages must be Encrypted
      • Any Imagery over 2 hours is not displayed
      • All Supply shipments delayed more than a day are routed to Expedite Service
    • Includes customizable Policy Library and Templates for most Common Policies
    • Automatically apply policies based on dynamic attributes and message content . Eg.
      • All production services of “Logistics” application
      • All requests containing Geographic Data
      • All services deployed in WebLogic containers
    • Identifies Conflicts between Policies
    • Automatic Synchronization with Registries – UDDI (Systinet) and others
    One-at-a-Time Approach s1 s5 s4 s2 s6 s3 where “ Logistics” Security Encryption all services where deployed on BEA app servers Logging Profile Based Approach s1 p1 s2 s3 s100 p1 p1 p50 100 services x 50 policies 5,000 policy points LB Weighted Reduces complexity of managing policies. Can manage system on “autopilot” where policies are assigned as appropriate. Eliminates production mistakes by reducing manual steps.
  • 42. AmberPoint Service Level Management
    • Automatically Sets Monitoring Policies to Collect and Display Service Level Statistics
      • Response Time
      • Availability
      • Faults
      • Throughput
      • Custom
    • Real time segmentation & prioritization based on Mission criteria
      • Give Priority to most important users – Warfighters, First Responders, Command Leaders or Agency Heads
      • Multiple objectives under one “agreement”
      • Flexible time windows – not just one average for all users
    • Baselining
    • Calendaring
      • Adjust Policies for Scheduled downtime, Holidays and Weekends, Time-zones
    • Reporting
      • SLA Compliance
      • Historical trends for capacity planning
    • Does not require creation of duplicate services
    Mission Related Svcs Warehouse (SAP) Inter-Agency Services Analysis Data (Siebel) Agency Portal QoS Data SLM Server
  • 43. AmberPoint Exception & Log Management
    • “ Error Handling System” for SOA
      • Track and Correlate Groups of Messages
      • Far more than SOAP Faults – Lack of Response, Message Patterns, etc.
    • Trigger Real-time Response or write to Log for future analysis
      • Alert when “No Response from Inter-Agency Service” within 1 minute after message sent”
    • Log Anything or Everything; powerful Search capabilities
      • Log Correlated Groups of Messages as a Unit
      • Search based on time, type, and content of requests & responses
      • Eliminates need to manually search through scattered logs
    • Automatically Feeds Root Cause Analysis
    • Selectively eliminate capture of sensitive data
    • Non-invasive – No need to Change Messages or Headers
  • 44. End-to-End SOA Management Without IONA ESB integration MQ-based Warehouse EJB Application Agency Portal Credit Service Credit Service DBMS Electronic Order Svc Order Service ??? Client App AmberPoint sees “external” traffic and usage
  • 45. End-to-End SOA Management With IONA ESB integration MQ-based Warehouse EJB Application Agency Portal Credit Service Credit Service DBMS Electronic Order Svc Order Service Client App Fine grained visibility into “internal” traffic and usage as well.
  • 46. SOA: An Integrated Approach ESB Service Endpoints CORBA / J2EE Systems JAVA / J2EE Systems MOM Based Systems Mainframe Transactions Artix Artix Celtix Data Services Business Processes Composite Services Management Services Transaction Services Location Services Security Services Service Intermediaries
    • AmberPoint’s Management Console:
      • Provides a window into the network of Artix Endpoints
      • Extends Artix security capabilities
      • Helps an organization evaluate service level goals over extended periods of time
      • Prioritize shared SOA application resources by relevant business context
    AmberPoint AmberPoint Artix Consumers
  • 47. IONA & AmberPoint: Common Vision
    • Market leaders partnering for the benefit of our customers
    • Driving the adoption of enterprise-wide, mission-critical SOA
    • Shared commitment to delivering enterprise-scale solutions
    • Enterprise SOA requires best of breed approach with clear separation of concerns
    • Artix and AmberPoint Integrated Solutions:
    • AmberPoint’s management console provides a window into the network of Artix Endpoints
    • AmberPoint enables an organization to review and analyze the quality-of-service (QoS) metrics provided by Artix
    • AmberPoint includes policy-based management and monitoring of services across a distributed set of endpoints
    • AmberPoint Security enhances Artix Security
    • Together we enable a graceful transition from current to future state SOA architecture
  • 48. John Emerson VP, Federal Operations [email_address] www.amberpoint.com © 2006 AmberPoint, Inc.
  • 49. Futures –
    • Advances in Standards
      • Ratification of newer versions of standards (SOAP, WSDL, etc.)
      • Emergence of newer standards to support the evolution of WS into enterprise environments
      • Service Component Architecture (SCA)
      • SOA Tools (Eclipse)
    • Advances in deployment support
      • Additional availability of transports/protocols in distributed infrastructures
    • Interoperability advances
      • More shake-out of interoperability issues
  • 50. For More Information
    • New white paper:
    • Integration For The Agile Business –
    • Artix Product Brief
    • www.iona.com/whitepaper
    • Upcoming Webcasts:
      • Extend the value of your existing IT assets with SOA
      • Speeding the Introduction of Telecom Triple Play with SOA
      • www.iona.com/webcasts
    Free download at www.iona.com/artix