real time, web 2.0, and grid systems
DESCRIPTION
Discussion of Grid and Web 2.0 technologies and application to collection of real time sensors including audio/video conferencingTRANSCRIPT
11
Real Time, Web 2.0, and Grid Systems
INGRID 2007 - Instrumenting the Grid 2nd International Workshop on Distributed Cooperative Laboratories -
S.Margherita Ligure Portofino, ITALY, April 18 2007
Geoffrey Fox
Computer Science, Informatics, PhysicsPervasive Technology Laboratories
Indiana University Bloomington IN 47401
[email protected]://www.infomall.org
22
Uncontroversial Ideas Distributed software systems are being
“revolutionized” by developments from e-commerce, e-Science and the consumer Internet. There is rapid progress in technology families termed “Web services”, “Grids” and “Web 2.0”
The emerging picture is of distributed services with advertised interfaces but opaque implementations communicating by streams of messages over a variety of protocols• Complete systems are built by combining either services or
predefined/pre-existing collections of services together to achieve new capabilities
We can use the term Grids strictly (Narrow or OGSA Grids) or just call any collections of services as “Broad Grids” which actually is quite often done
33
Why Web 2.0 is Useful Captures the incredible development of interactive
Web sites enabling people to create and collaborate
44
Technology Approaches Web Services have clearly defined protocols (SOAP) and a well
defined mechanism (WSDL) to define service interfaces• There is good .NET and Java support• The so-called WS-* specifications provide a rich sophisticated but
complicated standard set of capabilities for security, fault tolerance, meta-data, discovery, notification etc.
“Narrow Grids” build on Web Services and provide a robust managed environment with growing adoption in Enterprise systems and distributed science (so called e-Science)
Web 2.0 supports a similar architecture to Web services but has developed in a more chaotic but remarkably successful fashion with a service architecture with a variety of protocols including those of Web and Grid services• Over 400 Interfaces defined at http://www.programmableweb.com/apis
Web 2.0 also has many well known capabilities with Google Maps and Amazon Compute/Storage services of clear general relevance
There are also Web 2.0 services supporting novel collaboration modes and user interaction with the web as seen in social networking sites, portals, MySpace, YouTube,
55
Web 2.0 v Grid I Web 2.0 allows people to nurture the Internet Cloud and such
people got Time’s person of year award Whereas Narrow Grids support Internet scale Distributed
Services with similar architecture Maybe Narrow Grids focus on (number of) Services (there
aren’t many scientists) and Web 2.0 focuses on number of People Both agree on service oriented architectures but have different
emphasis Narrow Grids have a strong emphasis on standards and
structure; Web 2.0 lets a 1000 flowers (protocols) and a million developers bloom and focuses on functionality, broad usability and simplicity• Semantic Web/Grid has structure to allow reasoning• Annotation in sites like del.icio.us and uploading to MySpace/YouTube is
unstructured and free text search replaces structured ontologies
Web 2.0 v Grid II Web 2.0 has a set of major services like GoogleMaps or Flickr
but the world is composing Mashups that make new composite services• End-point standards are set by end-point owners• Many different protocols covering a variety of de-facto standards
Narrow Grids have a set of major software systems like Condor and Globus and a different world is extending with custom services and linking with workflow
Popular Web 2.0 technologies are PHP, JavaScript, JSON, AJAX and REST with “Start Page” e.g. (Google Gadgets) interfaces
Popular Narrow Grid technologies are Apache Axis, BPEL WSDL and SOAP with portlet interfaces
Robustness of Grids demanded by the Enterprise? Not so clear that Web 2.0 won’t eventually dominate other
application areas and with Enterprise 2.0 it’s invading GridsThe world does itself in large numbers!
77
APIs/Mashups per Protocol Distribution
REST SOAP XML-RPC REST,XML-RPC
REST,XML-RPC,
SOAP
REST,SOAP
JS Other
google google mapsmaps
netvibesnetvibes
live.comlive.com
virtual virtual earthearth
google google searchsearch
amazon S3amazon S3
amazon amazon ECSECS
flickrflickrebayebay
youtubeyoutube
411sync411syncdel.icio.usdel.icio.us
yahoo! searchyahoo! searchyahoo! geocodingyahoo! geocoding
technoratitechnorati
yahoo! imagesyahoo! imagestrynttrynt
yahoo! localyahoo! local
Number ofMashups
Number ofAPIs
88
Implication for Grids I I once thought Web Services were inevitable but this is
no longer clear to me Web services are complicated, slow and non functional
• WS-Security is unnecessarily slow and pedantic (canonicalization of XML)
• WS-RM (Reliable Messaging) seems to have poor adoption and doesn’t work well in collaboration
• WSDM (distributed management) specifies a lot There are de facto standards like Google Maps and
powerful suppliers like Google which “define the rules” One can easily combine SOAP (Web Service) based
services/systems with HTTP messages but the “lowest common denominator” suggests additional structure/complexity of SOAP will not easily survive
99
Implications for Grids II Should one define e-Infrastructure and Cyberinfrastructure
as core functionality for e-Science, e-Business etc. Then Web 2.0 is one technology and Grid/Web services are
another? Or could define a Broad Grid to be synonymous with e-
Infrastructure and allow it to be implemented with SOAP/Web Services or with HTTP-REST/Web 2.0?• i.e. define a Broad Grid as any collection of services with message
based interfaces of any protocols Or note that Narrowest Grid only adds ability to run jobs
(JSDL, BES) and perhaps build cross-domain virtual organizations to core capabilities of Web?• Data(base) Grid interfaces not so successful?• Google groups etc. also allow virtual organizations for
some key capabilities?• i.e. define a “Narrow Grid” as a standards compliant
collection of Web Services
1010
Implications for Instruments We shouldn’t worry so much about SOAP and Web
services but build small simple collections of services with documented interfaces
Messaging can be SOAP, HTTP, RTP or other binary• Previously I thought one should always use SOAP and if
necessary use “binary XML” to speed up and/or get back to native form
• Not a bad idea but too complicated Build Instrument Grids (Broad Grid definition) that
can be linked to other Broad Grids• Grids of Grids (Systems of Systems is well known Jargon)
This can lead to substantially higher performance, easier construction and allowed high functionality inside a given subgrid
11
Grids of Grids of Simple Services• Link via methods messages streams• Services and Grids are linked by messages• Internally to service, functionalities are linked by methods• A simple service is the smallest Grid• We are familiar with method-linked hierarchy
Lines of Code Methods Objects Programs Packages
Overlayand ComposeGrids of Grids
Methods Services Component Grids
CPUs Clusters ComputeResource Grids
MPPs
DatabasesFederatedDatabases
Sensor Sensor Nets
DataResource Grids
1212
Component Grids? So we build collections of Services which we package as
component Broad Grids• Visualization Grid• YouTube/MySpace Grid• Annotation (Connotea) Grid• Geographic Information System Grid • Sensor Grid• Instrument Grid• Utility Computing Grid• Audio-Video Conferencing Grid• Control Room Grid• Crisis Management Grid• Data-mining Grid
We build bigger Broad Grids by composing component Broad Grids by linking with mediated messages
13Physical Network (monitored by FS16)
7: Discovery 8:Metadata
BioInformatics GridChemical Informatics Grid
…Domain SpecificGrids/Services
…
4: Notification
6: Security 5: Workflow3: Messaging 9: Management
14: Information Instrument/Sensor
12: Computing
Core Low Level Grid Services
9: Management 18: Scheduling 10: Policy
15: Application Services
Screening ToolsQuantum Calculations
15: Application Services Sequencing ToolsBiocomplexity Simulations
11: Portals
17: Collaboration
Ser
vice
s
13: Data Access/Storage
Using the Grid of Grids and Core Services to build multiple application grids re-using common components.
1414
Net Centric and Critical Infrastructure (CI) Grids built as Grids of Grids and re-using subGrids
Flood Servicesand Filters
Physical Network
Registry Metadata
Military Servicesand Filters
Net Centric Grid Flood CIGrid… Electricity CIGrid …
Data Access/Storage
Security WorkflowNotification Messaging
Portals Information Management Grid
Collaboration Grid
Sensor Grid Compute GridGIS Grid
Core Grid Services
15
Mediation and Transformation in a Grid of Grids and Simple Services
Po
rtP
ort
Port PortInternal
Interfaces
Subgrid or service
Po
rtP
ort
Port PortInternal
Interfaces
Subgrid or service
Po
rtP
ort
Port PortInternal
Interfaces
Subgrid or service
Messaging
Mediation andTransformationServices
External facingInterfaces
16
Grid of Grids Builder Tool• This provides a graphical interface to build grids
from existing libraries of Services and Grids• Meta-data (provenance) needs to be specified• Grids (services) need to be linked• This is built by extending an existing workflow
engine which is aimed at a more tightly coupled version of the builder problem– We examined HPSearch (CGL), Taverna (Open source
from UK OMII), BPEL with user interface (OMII or IU LEAD project), Eclipse
– Semantic Grid provenance “add-ons”– We chose BPEL with an Eclipse interface
1717
Grid Builder Features The static properties set up at Grid definition stage are used to
specify initial set up of services and how they are to be restarted – i.e. setting the System Metadata and Policy as on what and how to restart
The Grid Builder will set up and launch a dynamic monitoring framework that provides fault tolerance for services and message brokers
18
Dynamic Service Management Architecture
Resource to Manage
(Managee)
ServiceAdapter
Bootstrap Service
System Health Check Manager
Resource to Manage
(Managee)
ServiceAdapter
Resource to Manage
(Managee)
ServiceAdapter
Manager
MessagingNode
Registry
Manager
Manager
...
...
Connect to Messaging Node for sending and
receiving messagesUser writes system
configuration to registry
Manager processes periodically checks available resources to manage. Also
Read/Write resource specific external state from/to
registry
Always ensure up and runningAlways ensure up
and running
Periodically Spawn
WS Management
Available in latest release of http://www.naradabrokering.org
19
NaradaBrokering
Stream
NB supports messagesand streams
Queues
Website: http://www.naradabrokering.org/
Code base specifics1425 classes 157 packages
300,000 lines of code1000 annual downloads
2020
Scalable Distributed Publish-subscribe Network
• Any number of Cooperating nodes
• P2P or hierarchical Constraint Specifications
• Strings, Regular Expressions, SQL queries, XPath queries, & XQuery
Support for multiple transports• TCP, UDP, Multicast, SSL, HTTP, Parallel-TCP
[1] Building Messaging Substrates for Web and Grid Applications. Philosophical Transactions of the Royal Society: Mathematical, Physical and Engineering Sciences. Vol 363, Num 1833, pp 1757-1773. 2005. [2] On the Matching Of Events in Distributed Brokering Systems. Proc of the IEEE ITCC Conf on Information Technology 2004. [3] NaradaBrokering: A Middleware Framework and Architecture for Enabling Durable Peer-to-Peer Grids. Proceedings of the ACM/IFIP/ USENIX International Middleware Conference, 2003.
NB Features: Data Distribution
2121
End-to-End Security All Interactions Authorized Copes with attack scenarios
• Replay attacks Secure Topics naturally support role-based secure message
subscriptions Transport independence of security implies can use for audio-
video conferences as well as SSL
[1] A Framework for Secure End-to-End Delivery of Messages in Publish/Subscribe Systems. Proceedings of the 7th IEEE/ACM International Conference on Grid Computing. 2006.
[2] On the Secure Creation, Organization and Discovery of Topics in Distributed Publish/Subscribe Systems. International Journal of High Performance Computing and Networking.
NB Features: Security
2222
[1] Fault-Tolerant Reliable Delivery of Messages in Distributed Publish/Subscribe Systems. (To appear) Proceedings of the 4th IEEE International Conference on Autonomic Computing. 2007.[2] A Scalable Approach for the Secure and Authorized Tracking of the Availability of Entities in Distributed Systems. Proc of 21st IEEE International Parallel & Distributed Processing Symposium. 2007.[3] A Scheme for Reliable Delivery of Events in Distributed Middleware Systems. Proceedings of the IEEE International Conference on Autonomic Computing. pp 328-329. 2004.
NB Features: Fault Tolerance Sustain losses of nodes Support for recovery and replays of streams Customize redundancy and replay scheme for storage of messages Guaranteed delivery of data Track availability of all entities
2323
[1] On the Discovery of Brokers in Distributed Messaging Infrastructures. Proc. of the IEEE Cluster 2005 Conference.
[2] On the Secure Creation, Organization and Discovery of Topics in Distributed Publish/Subscribe Systems. International Journal of High Performance Computing and Networking.
[3]A Grid Framework for Visualization Services in the Earth Sciences. Journal of Pure and Applied Geophysics. Volume 163, Numbers 11-12, 2006. pp 2467-2483. Birkhäuser Verlag.
All discovery is Secure and Authorized Discover closest broker
• Assimilate new broker additions Discover topics
• Topic Provenance identifies publisher and allowed subscribers
Load-balance resources
NB Features: Discovery of Brokers and Topics
2424
[1] Message-Based Cellular Peer-to-Peer Grids: Foundations for Secure Federation and Autonomic Services. Journal Of Future Generation Computer Systems. Volume 21, Issue 3, pp 401-415.[2] Worldwide Messaging Support for High Performance Real-time Collaboration. Proc of the UK e-Science Programme AHM 2005 [3] Implementing a NTP-Based Time Service within a Distributed Brokering System. Proc of the ACM International Conference on the Principles and Practice of Programming in Java.
NB Features: Qualities of Service (QoS) Jitter reduction
• Buffering & Time spacing services Global Timestamps
• Network Time Protocol• Time ordering
Coping with large payloads• Compression & Decompression• Fragmentation & Coalescing
2525
[1] Scalable, Fault Tolerant Management in a Service-Oriented Architecture. (To appear) Proc of the 2007 IEEE International Symposium on High-Performance Distributed Computing (HPDC).[2] Deploying the NaradaBrokering Substrate in Aiding Efficient Web & Grid Service Interactions. Proceedings of the IEEE. Vol 93, No 3. pp 564-577. March 2005.[3] On the Costs for Reliable Messaging in Web/Grid Service Environments. Proc. of the IEEE International Conference on e-Science & Grid Computing.
NB Features: Web Services Support WS-Reliable Messaging WS-Reliability WS-Eventing SOAP Not as important as I thought Comes with full WS-Management suite for dynamic broker management
2626
NB Features: Miscellaneous
JMS Compliant C++ bridge
• JNI• Sockets-based
Legacy• Interfaced with JXTA as example of P2P operation
High Performance and tested Java code Open source at http://www.naradabrokering.org
27
0
1
2
3
4
5
100 1000 10000 100000 0
1
2
3
4
5
Mean
tra
nsi
t d
ela
y
(Millise
con
ds)
Sta
nd
ard
Devia
tion
(M
illise
con
ds)
Content Payload Size (Bytes)
Round-trip delays for different payload sizes (100B - 100KB)
Delay Standard Deviation
These measurements are messages from client to broker and back using latest Java 1.6 release that is about twice performance of earlier releases
28
0
10
20
30
40
50
60
70
10 100 1000 10000 0
5
10
15
20
Tran
sit
Dela
y (
Millise
con
ds)
Sta
nd
ard
Devia
tion
(M
illise
con
ds)
Payload Size (Bytes)
End-to-End Secure & Authorized Delivery of Messages with 256-bit AES encryptions and 7PKCS padding
1024-bit RSA and 160-bit SHA-1 digest for signing/verification
Delay: 1 Broker, 1 Sub StdDev: 1 Broker, 1 Sub Delay: 3 Brokers, 200 Sub
StdDev: 3 Brokers, 200 Sub
2 ms per broker in distributed case
29
0
2
4
6
8
10
12
14
16
100 1000 10000
Tim
e (
Mill
iseco
nd
s)
Payload Size (Bytes)
Delivery overheads in different Topologiesfor different message payload sizes
3 Brokers, Best effort 3 Brokers, 1 Repository
3 Brokers, 3 Repositories
30
Average Video Delays (OLD Data) UDP Performance when NaradaBrokering used
for audio-video conferencing
Latency ms
# Receivers
One sessionMultiple sessions
30 frames/sec
3131
GlobalMMCS Service Architecture
SIP H323 Access Grid Native XGSPAdmire
Gateways convert to uniform XGSP Messaging
High Performance (RTP)and XML/SOAP and ..
Media ServersFilters
Session ServerXGSP-based Control
NaradaBrokeringAll Messaging
Use Multiple Media servers to scale to many codecs and manyversions of audio/video mixing
NB Scales asdistributed
WebServices
NaradaBrokering
Key idea: Use of queues in NaradaBrokering to build multipoint MCUThis works well and Naradabrokering is reliable for day long continuous runsMotivated UDP (as well as TCP) support in NaradaBrokeringGlobalMMCS is not very reliable software
3232
Collaboration Grid Improvements:HSD – Hybrid Shared Display
HSD builds on a combination of Classic Shared Display (CSD) and Video Shared Display (VSD)
Sharing an application either uses video VSD (low resolution, copes with rapid change) or exact encoding CSD (as in WebEx or VNC) which can’t keep up with rapidly changing areas
HSD Approach: Use image processing algorithm to find the video or fast changing regions in the shared application window, and encode them using video codec e.g. H.261 and MPEG4 to save network bandwidth while retaining good visual quality on rest of shared frame which uses RLE etc.• Average pixel rate of change in video window > 100 rate of change
in non-video part of shared window Need synchronized UDP and TCP transmissions to
transport both components
Screen capturing
Region finding
Video encoding SD screen data encoding
Network transmission (RTP) Network transmission (TCP)
Video Decoding (H.261) SD screen data decoding
Rendering Rendering
Screen display
HSD Flow
Presenter
Participants
Through UDP NaradaBrokering
VSD CSD
Through TCP NaradaBrokering
34
35
eSports System for Real time multipoint video sharing and annotation Real time Archive and instant replay of NaradaBrokering native
events; 200 ms delay on a replayed video stream across continental USA
Uses NaradaBrokering distributed replicated storage service to save and recall all video stream packets in < 200ms
Uses NaradaBrokering Time service to remove jitter and replay with faithful time intervals between packets
Supports Web Service version of extended RTSP for VCR style video manipulation services As all records stored, one can rewind to any point on a real time
(200 ms delayed) replay stream Utilizing WS-Context Service as standards compliant distributed
fault tolerant high performance metadata service; Transporting all messages through NaradaBrokering messaging
middleware
36
eSports System and Streaming Services
T=NaradaBrokering Topic
37
eSports System Interface (Recording)
38
eSports System Interface (Replay)
39
Explanation of User Interface
Opens an eSports session
Closes the eSports session Session ID
Session Description
GlobalMMCS Video 1
GlobalMMCS Video 2
Whiteboard area(Snapshot annotation
tool area)
Session List
Session Information
Area
Stream Information
Area
Snapshot Button for Video 1
Snapshot Button for Video 2
Timeline
Starting and stopping replay
sessions and streams
40
Performance Tests (WAN – UCSD Results)
Parameter Measured Mean Standard Deviation Standard Error Overall delay 229.3 msec 18.2 0.350 Generic streaming overhead
194.1 msec 18.2 0.350
Jitter 0.0 msec 0.0034 0.00007
41
Cost of Storage
Broker B2
Broker B1
Broker B3
S1P1
Topology C
Broker B2
Broker B1
Broker B3
S1P1
Repository
Topology D
Topology E
Repository 1
Broker B2
Broker B1
Broker B3
S1P1
Repository 2
Broker B2
Broker B1
Broker B3
Repository 2
Repository 3Repository 1
S1P1Topology F
0123 repositories
Old and New (Web 2.0) Community Tools del.icio.us, Connotea, Citeulike, Bibsonomy, Biolicious manage
shared bookmarks MySpace, YouTube, Bebo, Hotornot, Facebook, or similar sites
allow you to create (upload) community resources and share them; Friendster, LinkedIn create networks• http://en.wikipedia.org/wiki/List_of_social_networking_websites • http://www.slideshare.net http://www.gliffy.com
Google documents, Wikis and Blogs are powerful specialized shared document systems
ConferenceXP and WebEx share general applications Google Scholar tells you who has cited your papers while
publisher sites tell you about co-authors• Windows Live Academic Search has similar goals
Kazaa, Instant Messengers, Skype, Napster, BitTorrent for P2P Collaboration – text, audio-video conferencing, files
Note sharing resources creates (implicit) communities• Social network tools study graphs to both define communities
and extract their properties
Connotea Connotea is run
by Nature and is useful for collecting research links
Here is 177 parallel computing links selected on Meeting
Useful extension of del.icio.us
4444
“Best Web 2.0 Sites” -- 2006 Extracted from http://web2.wsj2.com/ Social Networking
Start Pages
Social Bookmarking
Peer Production News
Social Media Sharing
Online Storage (Computing)
4545
Mashups v Workflow? Mashup Tools are reviewed at http://blogs.zdnet.com/Hinchcliffe/?p=63 Workflow Tools are reviewed by Gannon and Fox
http://grids.ucs.indiana.edu/ptliupages/publications/Workflow-overview.pdf Both include
scripting in PHP, Python, sh etc. as both implement distributed programming at level of services
Mashups use all types of service interfaces and do not have the potential robustness (security) of Grid service approach
Typically “pure” HTTP (REST)
Why are Grids replacing scripts (Perl, PHP, Python) with arcane XML (as in BPEL) PHP is much better understood than BPEL and easier to read ….Not quite fair as need to standardize PHP variables
4646
Grid Workflow Datamining in Earth Science Work with Scripps Institute Grid services controlled by workflow process real time
data from ~70 GPS Sensors in Southern California
Streaming DataSupport
TransformationsData Checking
Hidden MarkovDatamining (JPL)
Display (GIS)
NASA GPS
Earthquake
Real Time
Archival
GIS Mashup or Grid consisting of mix of Web 2.0 functionality (Google Maps), Web services for results of Hidden Markov Analysis and our GIS data, Web 2.0 services for Google maps internal dataWorkflow scripted in JavaScript
4747
Web 2.0 uses all types of Services Here a Gadget Mashup uses a 3 service workflow with a
JavaScript Gadget Client and PHP services Web 2.0 is NOT just client side as sometimes claimed
Web 2.0 APIs
http://www.programmableweb.com/apis currently (April 17 2007) 415 Web 2.0 APIs with GoogleMaps the most used in Mashups
This site acts as a “UDDI” for Web 2.0
The List of Web 2.0 API’s Each site has API
and its features Divided into
broad categories Only a few used a
lot (39 API’s used in more than 10 mashups)
RSS feed of new APIs
3 more Mashups each day For a total of 1799
April 17 2007 (3.9 a day over last month)
Note ClearForest runs Semantic Web Services Mashup competitions (not workflow competitions)
Some Mashup types: aggregators, search aggregators, visualizers, mobile, maps, gamesGrowing number of commercial Mashup Tools
51
GIS Grid of “Indiana Map” and ~10 Indiana counties with accessible Map (Feature) Servers from different vendors. Grids federate different data repositories (cf Astronomy VO federating different observatory collections)
Indiana Map Grid (Mashup)
52
Browser +Google Map API
Cass County Map Server
(OGC Web Map Server)
Hamilton County Map Server(AutoDesk)
Marion County Map Server
(ESRI ArcIMS)
Browser client fetches image tiles for the bounding box using Google Map API. Tile Server
Cache Server
Adapter Adapter Adapter
Tile Server requests map tiles at all zoom levels with all layers. These are converted to uniform projection, indexed, and stored. Overlapping images are combined.
Must provide adapters for each Map Server type .
The cache server fulfills Google map calls with cached tiles at the requested bounding box that fill the bounding box.
Google Maps Server
53
Mash Planet
Web 2.0 Architecture
http://www.imagine-it.org/mashplanetDisplay too large to be a Gadget
54
Searched on Transit/TransportationSearched on Transit/Transportation
5555
Grid-style portal as used in Earthquake GridThe Portal is built from portlets
– providing user interface fragments for each service that are composed into the full interface – uses OGCE technology as does planetary science VLAB portal with University of Minnesota
5656
Portlets v. Google Gadgets Portals for Grid Systems are built using portlets with
software like GridSphere integrating these on the server-side into a single web-page
Google (at least) offers the Google sidebar and Google home page which support Web 2.0 services and do not use a server side aggregator
Google is more user friendly! The many Web 2.0 competitions is an interesting model
for promoting development in the world-wide distributed collection of Web 2.0 developers
I guess Web 2.0 model will win!
Note the many competitions powering Web 2.0 Mashup Development
Typical Google Gadget Structure
… Lots of HTML and JavaScript </Content> </Module>Portlets build User Interfaces by combining fragments in a standalone Java ServerGoogle Gadgets build User Interfaces by combining fragments with JavaScript on the client
Google Gadgets are an example of Start Page technologySee http://blogs.zdnet.com/Hinchcliffe/?p=8
HTTP v SOAP v WS-* v Grid Quote from user trying to use ClearForest SOAP API
when first released:• “How about a REST interface or at least a simpler web
interface with a GET or POST form (minus the frames). This would be a preferable option for many mashup environments, compared to SOAP.”
• ClearForest offered a REST API within the week. Microsoft DSS is an interesting high performance
service infrastructure supporting SOAP and HTTP http://msdn.microsoft.com/robotics/. • Runs well on multicore as well as distributed systems
Mashups can support multiple protocols but “equilibrium” is an evolution to simplest protocols as advantage of complicated protocols gets thrown away
0
50
100
150
200
250
300
350
1 10 100 1000 10000
Round trips
Av
era
ge
ru
n t
ime
(m
icro
se
co
nd
s)
Timing of HP Opteron Multicore as a function of number of simultaneous two-way service messages processed (November 2006 DSS Release) Measurements of Axis 2 shows about 500 microseconds – DSS is substantially faster
DSS Service Measurements
6060
So there is more or less no architecture difference between Narrow Grids and Web 2.0 and we can build e-infrastructure or Cyberinfrastructure with either architecture (or mix and match)
We should bring Web 2.0 People capabilities to Grids (eScience, Enterprises)
We should use most convenient services for a given problem
See Enterprise 2.0 discussion at http://blogs.zdnet.com/Hinchcliffe/
Mashups are workflow (and vice versa)
Portals are start pages and portlets could be gadgets