SaaS Software Container
By
Brian Moore
Paul Kopacz
Overview
SaaS Issues
Interoperability
The Container Framework
Major Components
Interfaces
Sample Flow
Future Work
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?
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.
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
1. 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.
SaaS App1 SaaS App2
Application Layer Application Layer
Communication Layer Communication Layer
Transportation Layer Transportation Layer
The Container Framework
2. We could create a browser based application to
facilitate and monitor communications between
applications
SaaS App1 SaaS App2
Application Layer container Application Layer
Communica Communica
tion Layer tion Layer
Transportation Layer Transportation Layer
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)
Container Framework
Clients
UDDI User Interface
UDDI
: Security Engine
Web Services Manager
SAAS
: UDDI SaaS App
UDDI Browser SaaS App
Data Integration
Manager :
SaaS
:
Monitor Engine
Provider
SaaS App
SaaS Customer
Provider Care
:
:
SaaS
Provider
Data
Customers
Repository
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
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
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
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
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
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)
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.
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
Sample Flow
SaaS Vendors
Container
The container publishes Management
the Management WSDL as WSDL
a service interface
Data Exchange
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
SaaS Vendors
Management
WSDL
SaaS vendors publish Management Container
implementation WSDL
references
Management
WSDL
Implementation Data Exchange
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
SaaS Vendors
5) Presented to user
Management Container
WSDL
2) Establish trust
Data Exchange
4) List of available applications
WSDL
3) Save data
UDDI Daemon
UDDI Database
1) Query for implementors
Implementation Scope
SaaS Vendors 1) Sign up
2) Transfer user information,
receive login token
Container
Management
WSDL
3) Save data
Data Exchange
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
SaaS Vendors 3) Send user and token, 1) Login
receive URL
Container
Management
WSDL
2) Get token
Data Exchange
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
5) User interacts with SaaS application
SaaS Vendors
4) Open URL
Container
Management
WSDL
Data Exchange
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
1) User requests “paste” from SaaS app
SaaS Vendors
2) Request clipboard items for user
4) Return items
Data Exchange Container
WSDL
3) Fetch items
Management
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
1) User requests a copy to clipboard from SaaS app
SaaS Vendors
2) Put data to clipboard
Data Exchange
WSDL Container
3) Store in database
Management
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
SaaS Vendors
Data Exchange
Container
WSDL
Management
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
SaaS Vendors
Set acceptable formats
Manage clipboard
Data Exchange
Container
WSDL
Management
WSDL
UDDI Daemon
UDDI Database
Implementation Scope
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