Uploaded on

 

More in: Technology , Business
  • 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
171
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
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
  • A fixed set of applications sit on top of a service transport layer that uses technologies such as Microsoft’s .NET or Sun’s J2EE platform,
  • Finding available Vendors through UDDI The Management WSDL is published in a tModel by the Container Co. - this is a WSDL service interface. Does not contain specific service URL Each Vendor would publish bindingTemplate with their WSDL for the Management interface - this is a WSDL service implementation. Includes the service interface, adds the URL where services may be called - the Vendor's bindingTemplate contains a tModelInstanceInfo element that references our WSDL service interface tModel - UDDI Daemon performs searches for bindingTemplates with these references to find available application Vendors

Transcript

  • 1. SaaS Software Container By Brian Moore Paul Kopacz
  • 2. Overview
    • SaaS Issues
    • Interoperability
    • The Container Framework
    • Major Components
    • Interfaces
    • Sample Flow
    • Future Work
  • 3. SaaS Issues
    • Trust
      • Users must trust that provider of the SaaS application is reputable, experienced, will secure and not abuse data, has good support system
    • Interoperability
      • Can SaaS applications communicate and exchange data with each other as seamless as cutting and pasting in windows?
      • Can SaaS applications interact with non SaaS applications in the enterprise or on a desktop?
    • Ownership
      • Who owns the applications? What does this look like on the balance sheet?
  • 4. Interoperability
    • Web Services Interoperability Organization (WS-I)
      • Address the interoperability issues with core web services standards
      • “ Interoperability refers to the ability of software and hardware on multiple machines from multiple vendors to communicate with each other without significant changes on either side.”
    • Web services as a solution
      • The standards for web services are messaging (SOAP), description (WSDL) and discovery and registry (UDDI)
    • Interoperability issues arise when individual vendors (Microsoft, Sun, etc) implement their own custom implementing of these protocols.
    • Realistically a web service implemented using JAVA on a UNIX machine should be able to be used by a client service on .NET technology.
  • 5. Areas of Interoperability
    • Communication
      • Status
      • Negotiations
      • Client preferences
    • Data
      • Exchange data between two applications running on separate machines by different providers
    • Commands
      • Access exposed commands of an application in order to perform some task
  • 6. The Container Framework
    • The container is a one stop shop for managing different SaaS applications from a variety of different vendors all under the same roof. This app will:
      • Manage user preferences
      • Manage user configurations
      • Allow users to find compatible SaaS applications from registered UDDI Servers and register for their service.
      • Monitor the status and health of active SaaS solutions
    • Two possible methods of controlling the interactions between SaaS applications within the container
      • We could create some kind of protocol that would sit on top of the Service Transportation layer to allow services to communication with each other directly.
    Transportation Layer Communication Layer Application Layer Transportation Layer Communication Layer Application Layer SaaS App1 SaaS App2
  • 7. The Container Framework 2. We could create a browser based application to facilitate and monitor communications between applications container Transportation Layer Application Layer SaaS App1 Communication Layer Transportation Layer Application Layer SaaS App2 Communication Layer
  • 8. Container Communication Types
    • Operator method
      • Container would be the initial contact point for both applications.
      • Container would do negotiations, contracting, monitoring
      • If conditions are meet the container would put two apps in touch with each other
    • Broker method
      • The container would not only be the initial contact point for both applications but the only contact point.
      • All requests and responses go through the container.
    • Second method good for
      • security
      • monitoring
      • data transfers ( transfer rates, ensuring connections, quality of data)
  • 9. Container Framework UDDI UDDI : : UDDI SAAS UDDI Browser Clients User Interface Security Engine Customers Data Repository Customer Care SaaS Provider SaaS Provider SaaS Provider : : Monitor Engine SaaS App SaaS App SaaS App : : Data Integration Manager Web Services Manager
  • 10. Major Components
    • Customer management
      • Mangers the customers preferences and habits. Such things like passwords, preferred applications, personal information and financial info for registering and paying for SaaS apps
      • Register once, use many times
      • The container will take care of negotiations with vendors on behalf of the client
      • options for
      • Automatic negotiation, contract time, Etc
      • A recent SearchSecurity.com poll of over 200 people found that 77% of respondents had six or more passwords
  • 11. Major Components
    • User Interface
      • Browser based interface
      • Login to container
      • Search options for SaaS applications based on criteria such as functionality, price, duration, rating, etc
      • Ability to launch all registered SaaS apps
        • SaaS apps open in new browser window controlled by the provider
        • Container will still have reference to browser window to monitor performance and detect problems
      • User can see what data is in “Holding” and where it came from
      • User preferences for automating negotiations, time warnings for usage, connection options, etc
  • 12. Major Components
    • SaaS UDDI Browser
      • Maintain a list of registered SaaS applications
      • Proactively search know UDDI registries for SaaS applications (services) that conform to the container standards for communication
      • SaaS applications would register a conforming services with UDDI for us to find
      • The component will also maintain a rating scale for all registered apps in case a decision need to be made between multiple same function apps
  • 13. Major Components
    • Web Services Manager
      • Manages interactions between exposed web services of the providers as well as requests from the provider to our exposed web services
      • There should also be a “smart service engine” within this component that would detect and convert any abstractions in the providers services that are platform or language dependent
      • Interacts with the Data Integration Manager to retrieve of deposit data.
      • Monitor and control the performance of web services
  • 14. Major Components
    • Data Integration Manager
      • Takes all requests from the Web Services Manager for depositing data or retrieving data.
      • Interacts with the database in order to store the data in the correct form (Tabular, image, text, etc)
      • Makes data available through a “Clipboard” type system that has an ID and description associated with the data so the retrieving app can distinguish from other data
      • Transfer data from one app to the other without compromising the integrity of the data
  • 15. Interfaces – SaaS Apps
    • SaaS apps must implement the following interfaces in order to be compatible with the container system.
      • Signup Service - Container provides the user's name and billing information. An authentication token is returned.
      • Terms Service - get the current terms of service for the vendor's application (price, durations, security)
      • Login Service - the authentication token is sent along with the user's name. A URL to an authenticated session is returned.
      • Authorize Service - sets up a trust between the vendor and the container when the app is first discovered by the container. Ideally would plug into a WS-Security module (e.g. Rampart)
  • 16. Interfaces – Container
    • Provided by the Container for SaaS applications to access.
    • For Data Exchange, status querying, negotiations and contracting
    • Set Formats - An application wants to control which data formats it receives. This allows it to set the formats it accepts. Clipboard items in formats other than these will not be sent.
    • Get Clipboard - returns the contents of the clipboard (restricted by format) of that user.
    • Put Clipboard Item - Add an item of data to the clipboard
    • Automatic Data Exchange would have data "channels" instead of items.
    • Use a publish-subscribe model. Applications would publish data. Whenever this data changed, the application would send the change to the container.
    • Application could subscribe to channels. When the container receives new data, it sends it along to any subscribed applications.
  • 17. Platform and Implementation
    • Two real choices: Java or .NET
    • We chose Java.
      • Familiarity.
      • Microsoft has public specifications for the core components of the framework but will be the only provider of complete .NET development and runtime environments
      • "Freeness" of available tools.
      • Excellent support for Web Services and multiple servlet container vendors.
    • Apache project:
      • Tomcat - Application Server
      • Juddi - UDDI server
        • runs in Tomcat
      • Axis/Axis2 - SOAP services and clients
        • services run in Tomcat
      • OJB - persistence
      • Plus the dozens of dependencies
  • 18. Sample Flow
  • 19. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope The container publishes the Management WSDL as a service interface
  • 20. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope Management WSDL Implementation SaaS vendors publish Management implementation WSDL references
  • 21. Implementation Scope SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL 1) Query for implementors 3) Save data 4) List of available applications 5) Presented to user 2) Establish trust
  • 22. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope 1) Sign up 2) Transfer user information, receive login token 3) Save data
  • 23. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope 1) Login 3) Send user and token, receive URL 2) Get token
  • 24. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope 4) Open URL 5) User interacts with SaaS application
  • 25. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope 2) Request clipboard items for user 3) Fetch items 4) Return items 1) User requests “paste” from SaaS app
  • 26. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope 1) User requests a copy to clipboard from SaaS app 2) Put data to clipboard 3) Store in database
  • 27. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope
  • 28. SaaS Vendors Container UDDI Database UDDI Daemon Management WSDL Data Exchange WSDL Implementation Scope Set acceptable formats Manage clipboard
  • 29. Future Work
    • A more user friendly user interface
      • Windows type look and feel
      • Graphical
      • Configurable
      • Maintain state
    • Implement more data exchange options
      • Base it on conditions
      • Depending on application and size of data an operator type method might work better.
    • More automated features acting on behalf of the user
      • An introduction of an agent type implementation might work well here