Your SlideShare is downloading. ×
0
AJAX WORLD March 2008
Jeff Haynie Co-founder & CEO   [email_address] blog.jeffhaynie.us twitter.com/jhaynie linkedin.com/in/jhaynie
how did we get here?
1991
Dave Litwack Mitchell Kertzman
Powersoft
Powerbuilder
client / server
proprietary
rapid app dev
database integration
$5.2M (6 months from 1.0)
Profitable: year one
IPO  Feb. 1993 (~3 years)
$57M 1993
suits came knocking
 
$900M - 1995
Oops (sybase fabricated sales figures)
revolutionized the way we built apps
focus on the app (and ultimately, our business requirements)
 
1991
Comdex (Atlanta)
 
 
client / server
easy to build apps
event driven
integration to DB
last release: 1996 (vb6)
 
March 31, 2005 (extended to March 2008 - better hurry up and replace)
focus on the app
2-tier architecture
client = application
<ul><li>rapid app creation </li></ul>
<ul><li>productivity </li></ul>
<ul><li>ease of use </li></ul>
distribution
security
programming model
client/server was proliferating, something else was happening
1989
 
tim berners-lee
CERN (europe)
world wide web
www
web
hyper text transfer protocol
http
http://www.example.com (if you don’t know this you’re in the wrong presentation)
directory (browsing)
sharing content (research)
primary display was text
network of connected computers
killer app = information
1992
 
marc andreessen
student at  univ of illinois
mosaic “web browser”
 
 
1994
 
Mosaic Communications Corporation
Netscape Communications
Netscape Communicator
 
IPO 1995
browser wars (1995)
massive adoption
web sites were slow internet was slow
almost all initial web sites were content-based
the “web” initially competed with consumer info services like AOL, Compuserve and Prodigy
primarily still web content you “browsed”
 
distributed  free (brilliant and bold move)
bundled win95  (plus! pack)
(isn’t it great being a monopoly?)
based on spyglass mosaic (remember Netscape?)
MASSIVE ADOPTION
January 1998
mozilla open source
(kick butt release party)
 

microsoft had 2 primary killer advantages:
Operating System platform
Developer Community
May 1998
DOJ ruled MSFT  violated anti-trust
(too late, game was pretty much over)
November 1998
$4.2 BILLION
 
web browser changed the way we think about apps
distribution of apps
programming model
development of software
web 1.0
three-tier architecture
server is the brain
client is for display (doesn’t that sound like the mainframe architecture?)
the way we built apps changed based on “the web”
common gateway interface (CGI)
netscape API (nsapi)
web servers
app servers
database servers
caching servers
web pages
web apps
massive new way of thinking about the web and apps (a lot was fueled by dot.com bubble)
1995
 
James Gosling
 
Java
Write once, Run anywhere
Browser
Applets
Java Web Start (some years later after applets failed)
slow
big
UI differences
web app?
native app? (sure  didn’t look like one)
programming model
browser plugin
java language was great!
but … apparent java would not be deployed in browser environment
java did change the way we built web sites (and it still continues today)
why the web?
web programming model
distributed
easy to program
UI simple to layout
cross-browser differences
open source emerging rapidly with Internet
standards-based
1994
 
tim berners-lee (remember, he created the web?)
preserve, promote web standards
“ ensure compatibility among vendors”
(are we there yet?)
HTML
CSS
XML
DOM
CGI
VoiceXML / CCXML
(too many more to list)
HTML 1.0 – 1993 (IETF WD)
HTML 2.0 – 1995 (IETF RFC)
HTML 3.0/3.2 (W3C)
HTML 4.0 (1997)
(XHTML came along the way)
HTML 5.0 (Jan 2008 - WD) 11 years!
Client-side data storage
video
cross document messaging
remoting
(continuing to expand idea of what a web app is)
XHTML or HTML?
most innovation has been on the server
servlets
JSP pages
ASP pages
tag libaries
PHP pages
(and lots of embedded sql)
cold fusion (so many other great server-side web frameworks)
server-driven UI
model-view-controller  (MVC)
(server-assisted  MVC)
server generates UI
UI is a template page
same HTML (almost always)
not very environmentally friendly  
age of server-side infrastructure
application servers
“ middleware”
new app complexities on the server side
cache business objects
cache page templates
cache SQL queries
session state
stored application state
(we used to call it application state)
session clustering
sticky sessions (optimize load balancing)
clustering not linear
middleware wars
hundreds of app servers
lots of server-side frameworks
lots of big companies rolled their own initially
IBM
Sun
BEA (weblogic)
organized around J2EE specification
community-based (Sun JCP)
heavy weight
overly complex
too many specs to keep up with
widely adopted
clustering
fail-over
high-availability
Microsoft .NET
wasn’t J2EE (not necessarily a bad thing)
wasn’t even java (of course not)
2000 – Microsoft C# (feels a lot like Java)
part of Microsoft .NET
web-programming model
(for Microsoft platform)
1999
 
(not flavor flav)
 
(marc fleury)
JBoss
Java application server (and eventually J2EE)
FREE! (well, almost)
open source
J2EE programming model (and it almost made J2EE fun)
2001 (JBoss, LLC)
innovation primarily driven by server-side infrastructure
apps not much different (1999)
server-assisted MVC
service oriented architecture
middleware = SOA
service federations
distributed registries
service composition
service orchestration
portals
ESB
$60B Market (at least they say it was)
But business applications still function the same
Jesse James Garrett “AJAX” 2005
Microsoft & Netscape
early inter-applet techniques
applets to slow to start
IE5 – MSFT created XHR
Microsoft Outlook Web (Microsoft was innovating!)
Web 1.5
MVC + Ajax
round peg square hole
page driven paradigm with async behavior
look Ma – no page refresh
cool, but. . .
it’s only “pimp my web 1.0”
 
but lots of startups and innovative web companies thinking big
web 2.0
starting to think about apps again
networks are faster
hardware is cheap
software is moving to open source
and everyone is wired and on the web
user experience
 
 
richer apps
dynamic info
web is the platform
 
 
 
(you can do that?)
 
 
 
(my enterprise apps need that)
(but, how?)
<ul><li>different solutions </li></ul>(we’re innovating again)
different approaches (and some feel like déjà vu)
Sun doing something similar as before (as best we can tell)
 
(yawn…)
MSFT doing something similar as before (it’s great being on top)
 
(surprise!)
Adobe has an innovative approach that leverages Flash
 
wonderful product
open source (kind of)
“ Web 2.0” is  overloaded
Web 2.0 = rich client
rich client = client programming
rich client != UI code in server
okay, but how?
Javascript
(and lots of it)
simple login form example
<html> <head> <title>Simple Ajax Login Example</title> <script language=&quot;Javascript&quot;> function xmlhttpPost(strUR...
(Yikes!!!)
25+ lines of Javascript
for one simple login form
rich client = mountains of JS?
mountains of JS = nightmare
(crap.  now what?)
open standards + open source   (to the rescue)
Javascript libraries
and lots of them
<ul><li>widget libraries </li></ul>
<ul><li>Ajax libraries </li></ul>
<ul><li>effect libraries </li></ul>
(here’s just a few)
Prototype
Scriptaculous
JQuery
Dojo
ExtJS
Yahoo YUI
Mootools
Open Rico
Qooxdoo
MochiKit
Lightbox
Greybox
Lightbox Plus
Nifty Corners
(okay to breathe)
(you get the point)
all great libraries!
how do I keep up with them all?
multiple versions, bug fixes
integration issues, glue code namespace issues
(but I thought that was the platform vendor’s job!)
with chaos comes opportunity
<ul><li>open standards </li></ul>
<ul><li>open source (the entire bits) </li></ul>
<ul><li>open developer community </li></ul>
<ul><li>integrated RIA programming model  (HTML, CSS and Javascript) </li></ul>
what does that mean?
well, what does an RIA programmer do?
event handling, Ajax, DHTML
(Got it!)
login form revisited
<html>   <head> <title>Hello World 2.0</title>   <script src=&quot;javascripts/appcelerator.js&quot;  type=&quot;text/java...
on=“r:login.request then show”
(what is that?)
event handling + Ajax + DHTML  one simple expression language
it’s an integrated RIA programming model
that leverages standards  (like HTML, CSS and Javascript)
it codes Javascript so you don’t have to
(Web Expression Language)
cool, but what about widgets?
(good question)
<ul><li>I want to be able to create new widgets </li></ul>
<ul><li>leverage all of the  great existing widgets </li></ul>
<ul><li>I want one single integrated way to use them ALL </li></ul>
 
how about this:
<!– ExtJS Grid --> <app:ext_grid on=&quot;l:show.user.response then execute&quot;  property=&quot;rows&quot;  width=&quot;...
ExtJS and YUI in one widget framework?
(yes, and any others you want)
including Flex widgets!
(and you can easily create your own)
 
okay, calm down Sally
let’s recap
Web Expression Language + Unified Widget Framework + Open Standards + Open Source =
fully integrated RIA platform
 
RIA is good but what about my services?
(and that $60B investment in SOA?)
you want to mix your RIA with your SOA
RIA + SOA
full decoupling of the rich client from its services
they share only one thing
a lightweight message contract (aren’t they services?)
(need a picture?)
Rich Client Service r:login.request {‘username’:’joe’, ‘password’:’****’} r:login.response {‘success’:true}
Contract = message name
login.request  and  login.response
plus input and output data
(that’s it!)
if the contract is message-based
why does the service programming language matter?
good question.
(it doesn’t)
with a message-based contract you can create services in any programming language!
we call these SOA Integration Points
and we have them for Java, Ruby, PHP, .NET, Python and Perl
how does that work?
let’s look at Java
take a plain Java object (POJO)
and add a single annotation
@Service(request = ”my.request&quot;, response = ”my.response&quot;)
to a Java method – like so:
package org.appcelerator.service; import org.appcelerator.annotation.Service; import org.appcelerator.messaging.Message; p...
(that’s it!) really….
each SOA Integration Point
<ul><li>service routing </li></ul>
<ul><li>data marshalling </li></ul>
(what does that mean?)
it means you can place a native object or array of objects into the response
and we’ll take care of the rest.
the result is:
you focus on what you do best: BUILD APPLICATIONS!
instead of playing the role of platform vendor
that’s our job!
 
we are the RIA + SOA company
RIA + SOA – that’s good but what about prototyping?
(glad you asked)
remember our message-based contract?
it enables location independence for services
meaning mock services can reside in the RIA
meaning you can build fully functional RIA prototypes
without a single line of service code (or even web server)
with 100% reusability!
we call them  Interactive Use Cases
build your application while you build your requirements
no more server-focused development
no more 100-page requirements documents (that never matches the end application)
it’s technology-enabled Agile development
<ul><li>quick iterations  </li></ul>
<ul><li>fully functional  (at every point) </li></ul>
<ul><li>makes it easy to gather feedback from key stakeholders </li></ul>
product managers
service developers
documentation team
QA
sales team
and even customers
after incorporating feedback
you have two key deliverables:
<ul><li>fully functional  RIA prototype (100% reusable)  </li></ul>
2.  fully defined  message contracts
(makes service development and integration a snap)
 
fully integrated  RIA+SOA platform
an entirely new and better way to build the next generation of web applications
help us build the best RIA+SOA open source developer community www.appcelerator.org
 
Upcoming SlideShare
Loading in...5
×

Ajaxworld March 2008 - Jeff Haynie Keynote - Appcelerator

6,609

Published on

This was my opening keynote presentation for Ajaxworld March 2008 in NYC.

Published in: Economy & Finance, Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,609
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
110
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Transcript of "Ajaxworld March 2008 - Jeff Haynie Keynote - Appcelerator"

  1. 1. AJAX WORLD March 2008
  2. 2. Jeff Haynie Co-founder & CEO [email_address] blog.jeffhaynie.us twitter.com/jhaynie linkedin.com/in/jhaynie
  3. 3. how did we get here?
  4. 4. 1991
  5. 5. Dave Litwack Mitchell Kertzman
  6. 6. Powersoft
  7. 7. Powerbuilder
  8. 8. client / server
  9. 9. proprietary
  10. 10. rapid app dev
  11. 11. database integration
  12. 12. $5.2M (6 months from 1.0)
  13. 13. Profitable: year one
  14. 14. IPO Feb. 1993 (~3 years)
  15. 15. $57M 1993
  16. 16. suits came knocking
  17. 18. $900M - 1995
  18. 19. Oops (sybase fabricated sales figures)
  19. 20. revolutionized the way we built apps
  20. 21. focus on the app (and ultimately, our business requirements)
  21. 23. 1991
  22. 24. Comdex (Atlanta)
  23. 27. client / server
  24. 28. easy to build apps
  25. 29. event driven
  26. 30. integration to DB
  27. 31. last release: 1996 (vb6)
  28. 33. March 31, 2005 (extended to March 2008 - better hurry up and replace)
  29. 34. focus on the app
  30. 35. 2-tier architecture
  31. 36. client = application
  32. 37. <ul><li>rapid app creation </li></ul>
  33. 38. <ul><li>productivity </li></ul>
  34. 39. <ul><li>ease of use </li></ul>
  35. 40. distribution
  36. 41. security
  37. 42. programming model
  38. 43. client/server was proliferating, something else was happening
  39. 44. 1989
  40. 46. tim berners-lee
  41. 47. CERN (europe)
  42. 48. world wide web
  43. 49. www
  44. 50. web
  45. 51. hyper text transfer protocol
  46. 52. http
  47. 53. http://www.example.com (if you don’t know this you’re in the wrong presentation)
  48. 54. directory (browsing)
  49. 55. sharing content (research)
  50. 56. primary display was text
  51. 57. network of connected computers
  52. 58. killer app = information
  53. 59. 1992
  54. 61. marc andreessen
  55. 62. student at univ of illinois
  56. 63. mosaic “web browser”
  57. 66. 1994
  58. 68. Mosaic Communications Corporation
  59. 69. Netscape Communications
  60. 70. Netscape Communicator
  61. 72. IPO 1995
  62. 73. browser wars (1995)
  63. 74. massive adoption
  64. 75. web sites were slow internet was slow
  65. 76. almost all initial web sites were content-based
  66. 77. the “web” initially competed with consumer info services like AOL, Compuserve and Prodigy
  67. 78. primarily still web content you “browsed”
  68. 80. distributed free (brilliant and bold move)
  69. 81. bundled win95 (plus! pack)
  70. 82. (isn’t it great being a monopoly?)
  71. 83. based on spyglass mosaic (remember Netscape?)
  72. 84. MASSIVE ADOPTION
  73. 85. January 1998
  74. 86. mozilla open source
  75. 87. (kick butt release party)
  76. 89.
  77. 90. microsoft had 2 primary killer advantages:
  78. 91. Operating System platform
  79. 92. Developer Community
  80. 93. May 1998
  81. 94. DOJ ruled MSFT violated anti-trust
  82. 95. (too late, game was pretty much over)
  83. 96. November 1998
  84. 97. $4.2 BILLION
  85. 99. web browser changed the way we think about apps
  86. 100. distribution of apps
  87. 101. programming model
  88. 102. development of software
  89. 103. web 1.0
  90. 104. three-tier architecture
  91. 105. server is the brain
  92. 106. client is for display (doesn’t that sound like the mainframe architecture?)
  93. 107. the way we built apps changed based on “the web”
  94. 108. common gateway interface (CGI)
  95. 109. netscape API (nsapi)
  96. 110. web servers
  97. 111. app servers
  98. 112. database servers
  99. 113. caching servers
  100. 114. web pages
  101. 115. web apps
  102. 116. massive new way of thinking about the web and apps (a lot was fueled by dot.com bubble)
  103. 117. 1995
  104. 119. James Gosling
  105. 121. Java
  106. 122. Write once, Run anywhere
  107. 123. Browser
  108. 124. Applets
  109. 125. Java Web Start (some years later after applets failed)
  110. 126. slow
  111. 127. big
  112. 128. UI differences
  113. 129. web app?
  114. 130. native app? (sure didn’t look like one)
  115. 131. programming model
  116. 132. browser plugin
  117. 133. java language was great!
  118. 134. but … apparent java would not be deployed in browser environment
  119. 135. java did change the way we built web sites (and it still continues today)
  120. 136. why the web?
  121. 137. web programming model
  122. 138. distributed
  123. 139. easy to program
  124. 140. UI simple to layout
  125. 141. cross-browser differences
  126. 142. open source emerging rapidly with Internet
  127. 143. standards-based
  128. 144. 1994
  129. 146. tim berners-lee (remember, he created the web?)
  130. 147. preserve, promote web standards
  131. 148. “ ensure compatibility among vendors”
  132. 149. (are we there yet?)
  133. 150. HTML
  134. 151. CSS
  135. 152. XML
  136. 153. DOM
  137. 154. CGI
  138. 155. VoiceXML / CCXML
  139. 156. (too many more to list)
  140. 157. HTML 1.0 – 1993 (IETF WD)
  141. 158. HTML 2.0 – 1995 (IETF RFC)
  142. 159. HTML 3.0/3.2 (W3C)
  143. 160. HTML 4.0 (1997)
  144. 161. (XHTML came along the way)
  145. 162. HTML 5.0 (Jan 2008 - WD) 11 years!
  146. 163. Client-side data storage
  147. 164. video
  148. 165. cross document messaging
  149. 166. remoting
  150. 167. (continuing to expand idea of what a web app is)
  151. 168. XHTML or HTML?
  152. 169. most innovation has been on the server
  153. 170. servlets
  154. 171. JSP pages
  155. 172. ASP pages
  156. 173. tag libaries
  157. 174. PHP pages
  158. 175. (and lots of embedded sql)
  159. 176. cold fusion (so many other great server-side web frameworks)
  160. 177. server-driven UI
  161. 178. model-view-controller (MVC)
  162. 179. (server-assisted MVC)
  163. 180. server generates UI
  164. 181. UI is a template page
  165. 182. same HTML (almost always)
  166. 183. not very environmentally friendly 
  167. 184. age of server-side infrastructure
  168. 185. application servers
  169. 186. “ middleware”
  170. 187. new app complexities on the server side
  171. 188. cache business objects
  172. 189. cache page templates
  173. 190. cache SQL queries
  174. 191. session state
  175. 192. stored application state
  176. 193. (we used to call it application state)
  177. 194. session clustering
  178. 195. sticky sessions (optimize load balancing)
  179. 196. clustering not linear
  180. 197. middleware wars
  181. 198. hundreds of app servers
  182. 199. lots of server-side frameworks
  183. 200. lots of big companies rolled their own initially
  184. 201. IBM
  185. 202. Sun
  186. 203. BEA (weblogic)
  187. 204. organized around J2EE specification
  188. 205. community-based (Sun JCP)
  189. 206. heavy weight
  190. 207. overly complex
  191. 208. too many specs to keep up with
  192. 209. widely adopted
  193. 210. clustering
  194. 211. fail-over
  195. 212. high-availability
  196. 213. Microsoft .NET
  197. 214. wasn’t J2EE (not necessarily a bad thing)
  198. 215. wasn’t even java (of course not)
  199. 216. 2000 – Microsoft C# (feels a lot like Java)
  200. 217. part of Microsoft .NET
  201. 218. web-programming model
  202. 219. (for Microsoft platform)
  203. 220. 1999
  204. 222. (not flavor flav)
  205. 224. (marc fleury)
  206. 225. JBoss
  207. 226. Java application server (and eventually J2EE)
  208. 227. FREE! (well, almost)
  209. 228. open source
  210. 229. J2EE programming model (and it almost made J2EE fun)
  211. 230. 2001 (JBoss, LLC)
  212. 231. innovation primarily driven by server-side infrastructure
  213. 232. apps not much different (1999)
  214. 233. server-assisted MVC
  215. 234. service oriented architecture
  216. 235. middleware = SOA
  217. 236. service federations
  218. 237. distributed registries
  219. 238. service composition
  220. 239. service orchestration
  221. 240. portals
  222. 241. ESB
  223. 242. $60B Market (at least they say it was)
  224. 243. But business applications still function the same
  225. 244. Jesse James Garrett “AJAX” 2005
  226. 245. Microsoft & Netscape
  227. 246. early inter-applet techniques
  228. 247. applets to slow to start
  229. 248. IE5 – MSFT created XHR
  230. 249. Microsoft Outlook Web (Microsoft was innovating!)
  231. 250. Web 1.5
  232. 251. MVC + Ajax
  233. 252. round peg square hole
  234. 253. page driven paradigm with async behavior
  235. 254. look Ma – no page refresh
  236. 255. cool, but. . .
  237. 256. it’s only “pimp my web 1.0”
  238. 258. but lots of startups and innovative web companies thinking big
  239. 259. web 2.0
  240. 260. starting to think about apps again
  241. 261. networks are faster
  242. 262. hardware is cheap
  243. 263. software is moving to open source
  244. 264. and everyone is wired and on the web
  245. 265. user experience
  246. 268. richer apps
  247. 269. dynamic info
  248. 270. web is the platform
  249. 274. (you can do that?)
  250. 278. (my enterprise apps need that)
  251. 279. (but, how?)
  252. 280. <ul><li>different solutions </li></ul>(we’re innovating again)
  253. 281. different approaches (and some feel like déjà vu)
  254. 282. Sun doing something similar as before (as best we can tell)
  255. 284. (yawn…)
  256. 285. MSFT doing something similar as before (it’s great being on top)
  257. 287. (surprise!)
  258. 288. Adobe has an innovative approach that leverages Flash
  259. 290. wonderful product
  260. 291. open source (kind of)
  261. 292. “ Web 2.0” is overloaded
  262. 293. Web 2.0 = rich client
  263. 294. rich client = client programming
  264. 295. rich client != UI code in server
  265. 296. okay, but how?
  266. 297. Javascript
  267. 298. (and lots of it)
  268. 299. simple login form example
  269. 300. <html> <head> <title>Simple Ajax Login Example</title> <script language=&quot;Javascript&quot;> function xmlhttpPost(strURL) { var xmlHttpReq = false; var self = this; // Mozilla/Safari if (window.XMLHttpRequest) { self.xmlHttpReq = new XMLHttpRequest(); } // IE else if (window.ActiveXObject) { self.xmlHttpReq = new ActiveXObject(&quot;Microsoft.XMLHTTP&quot;); } self.xmlHttpReq.open('POST', strURL, true); self.xmlHttpReq.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded'); self.xmlHttpReq.onreadystatechange = function() { if (self.xmlHttpReq.readyState == 4) { updatepage(self.xmlHttpReq.responseText); } } self.xmlHttpReq.send(getquerystring()); } function getquerystring() { var form = document.forms['f1']; var username = form.username.value; var password = form.password.value; qstr = ‘username=' + escape(username) + ‘&password=‘ + password; return qstr; } function updatepage(str){ document.getElementById(&quot;result&quot;).innerHTML = str; } </script> </head> <body> <form name=&quot;f1&quot;> <p>username: </p> <input name=”username&quot; type=&quot;text”/> <p>password: </p> <input name=”password&quot; type=&quot;text”/> <input value=”login&quot; type=&quot;button&quot; onclick='JavaScript:xmlhttpPost(&quot;/cgi-bin/simple-ajax-example.cgi&quot;)'></p> <div id=&quot;result&quot;></div> </form> </body> </html>
  270. 301. (Yikes!!!)
  271. 302. 25+ lines of Javascript
  272. 303. for one simple login form
  273. 304. rich client = mountains of JS?
  274. 305. mountains of JS = nightmare
  275. 306. (crap. now what?)
  276. 307. open standards + open source (to the rescue)
  277. 308. Javascript libraries
  278. 309. and lots of them
  279. 310. <ul><li>widget libraries </li></ul>
  280. 311. <ul><li>Ajax libraries </li></ul>
  281. 312. <ul><li>effect libraries </li></ul>
  282. 313. (here’s just a few)
  283. 314. Prototype
  284. 315. Scriptaculous
  285. 316. JQuery
  286. 317. Dojo
  287. 318. ExtJS
  288. 319. Yahoo YUI
  289. 320. Mootools
  290. 321. Open Rico
  291. 322. Qooxdoo
  292. 323. MochiKit
  293. 324. Lightbox
  294. 325. Greybox
  295. 326. Lightbox Plus
  296. 327. Nifty Corners
  297. 328. (okay to breathe)
  298. 329. (you get the point)
  299. 330. all great libraries!
  300. 331. how do I keep up with them all?
  301. 332. multiple versions, bug fixes
  302. 333. integration issues, glue code namespace issues
  303. 334. (but I thought that was the platform vendor’s job!)
  304. 335. with chaos comes opportunity
  305. 336. <ul><li>open standards </li></ul>
  306. 337. <ul><li>open source (the entire bits) </li></ul>
  307. 338. <ul><li>open developer community </li></ul>
  308. 339. <ul><li>integrated RIA programming model (HTML, CSS and Javascript) </li></ul>
  309. 340. what does that mean?
  310. 341. well, what does an RIA programmer do?
  311. 342. event handling, Ajax, DHTML
  312. 343. (Got it!)
  313. 344. login form revisited
  314. 345. <html> <head> <title>Hello World 2.0</title> <script src=&quot;javascripts/appcelerator.js&quot; type=&quot;text/javascript&quot;></script> </head> <body> <div on=“r:login.request then show or r:login.response then hide” style=“display:none”> <img src=“images/indicator.gif” /> processing login… </div> Username: <input type=“text id=“username” fieldset=“login”/> Password: <input type=“password id=“password fieldset=“login”/> <input type=“button” value=“login” fieldset=“login” on=“click then r:login.request” /> </body> </html>
  315. 346. on=“r:login.request then show”
  316. 347. (what is that?)
  317. 348. event handling + Ajax + DHTML one simple expression language
  318. 349. it’s an integrated RIA programming model
  319. 350. that leverages standards (like HTML, CSS and Javascript)
  320. 351. it codes Javascript so you don’t have to
  321. 352. (Web Expression Language)
  322. 353. cool, but what about widgets?
  323. 354. (good question)
  324. 355. <ul><li>I want to be able to create new widgets </li></ul>
  325. 356. <ul><li>leverage all of the great existing widgets </li></ul>
  326. 357. <ul><li>I want one single integrated way to use them ALL </li></ul>
  327. 359. how about this:
  328. 360. <!– ExtJS Grid --> <app:ext_grid on=&quot;l:show.user.response then execute&quot; property=&quot;rows&quot; width=&quot;390&quot; title=”Users”> <column property=”first” >First Name</column> <column property=”last”>Last Name</column> <column property=”phone”>Phone</column> </app:ext_grid> <!– Yahoo Calendar --> <app:calendar on=&quot;l:show.calendar then execute&quot; title=”My Calendar&quot; inputId=”date”> </app:calendar> <input type=“text” id=“date”/> <img src=“images/calendar.png” on=“click then l:show.calendar”/>
  329. 361. ExtJS and YUI in one widget framework?
  330. 362. (yes, and any others you want)
  331. 363. including Flex widgets!
  332. 364. (and you can easily create your own)
  333. 366. okay, calm down Sally
  334. 367. let’s recap
  335. 368. Web Expression Language + Unified Widget Framework + Open Standards + Open Source =
  336. 369. fully integrated RIA platform
  337. 371. RIA is good but what about my services?
  338. 372. (and that $60B investment in SOA?)
  339. 373. you want to mix your RIA with your SOA
  340. 374. RIA + SOA
  341. 375. full decoupling of the rich client from its services
  342. 376. they share only one thing
  343. 377. a lightweight message contract (aren’t they services?)
  344. 378. (need a picture?)
  345. 379. Rich Client Service r:login.request {‘username’:’joe’, ‘password’:’****’} r:login.response {‘success’:true}
  346. 380. Contract = message name
  347. 381. login.request and login.response
  348. 382. plus input and output data
  349. 383. (that’s it!)
  350. 384. if the contract is message-based
  351. 385. why does the service programming language matter?
  352. 386. good question.
  353. 387. (it doesn’t)
  354. 388. with a message-based contract you can create services in any programming language!
  355. 389. we call these SOA Integration Points
  356. 390. and we have them for Java, Ruby, PHP, .NET, Python and Perl
  357. 391. how does that work?
  358. 392. let’s look at Java
  359. 393. take a plain Java object (POJO)
  360. 394. and add a single annotation
  361. 395. @Service(request = ”my.request&quot;, response = ”my.response&quot;)
  362. 396. to a Java method – like so:
  363. 397. package org.appcelerator.service; import org.appcelerator.annotation.Service; import org.appcelerator.messaging.Message; public class MyService { @Service(request = ”my.request&quot;, response = ”my.response&quot;) protected void myRequest(Message request, Message response) throws Exception { // service logic here } }
  364. 398. (that’s it!) really….
  365. 399. each SOA Integration Point
  366. 400. <ul><li>service routing </li></ul>
  367. 401. <ul><li>data marshalling </li></ul>
  368. 402. (what does that mean?)
  369. 403. it means you can place a native object or array of objects into the response
  370. 404. and we’ll take care of the rest.
  371. 405. the result is:
  372. 406. you focus on what you do best: BUILD APPLICATIONS!
  373. 407. instead of playing the role of platform vendor
  374. 408. that’s our job!
  375. 410. we are the RIA + SOA company
  376. 411. RIA + SOA – that’s good but what about prototyping?
  377. 412. (glad you asked)
  378. 413. remember our message-based contract?
  379. 414. it enables location independence for services
  380. 415. meaning mock services can reside in the RIA
  381. 416. meaning you can build fully functional RIA prototypes
  382. 417. without a single line of service code (or even web server)
  383. 418. with 100% reusability!
  384. 419. we call them Interactive Use Cases
  385. 420. build your application while you build your requirements
  386. 421. no more server-focused development
  387. 422. no more 100-page requirements documents (that never matches the end application)
  388. 423. it’s technology-enabled Agile development
  389. 424. <ul><li>quick iterations </li></ul>
  390. 425. <ul><li>fully functional (at every point) </li></ul>
  391. 426. <ul><li>makes it easy to gather feedback from key stakeholders </li></ul>
  392. 427. product managers
  393. 428. service developers
  394. 429. documentation team
  395. 430. QA
  396. 431. sales team
  397. 432. and even customers
  398. 433. after incorporating feedback
  399. 434. you have two key deliverables:
  400. 435. <ul><li>fully functional RIA prototype (100% reusable) </li></ul>
  401. 436. 2. fully defined message contracts
  402. 437. (makes service development and integration a snap)
  403. 439. fully integrated RIA+SOA platform
  404. 440. an entirely new and better way to build the next generation of web applications
  405. 441. help us build the best RIA+SOA open source developer community www.appcelerator.org
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×