1. The Inverse World of the FOREST Object Web Duncan Cragg Part 1 - Overview

2. FOREST is an architecture that resonates with stuff like this: Clojure Agents / Scala & Erlang Actors Dataflow / Reactive Programming Declarative / Functional Programming Concurrency, Map-Reduce NoSQL, Eventual Consistency REST, Resource-Oriented Architectures

3. FOREST describes a new kind of Object...

4. FOREST Objects are Happy Objects

5. They are happy because no-one tells them what to do

6. Normal Objects are covered with methods

7. ..which other Objects can call whenever they want

8. ..as long as they happen to know the particular interface ?

9. Normal Objects keep their state hidden under wraps

10. FOREST Objects show their state to everyone

11. and that state is in a standard form that everyone understands

12. FOREST Objects are internally-animated

13. All the methods are on the inside

14. FOREST Objects are Inverse Objects

15. FOREST Objects are Inverse Objects Tell Don't AskAsk Don't Tell

16. Another reason FOREST Objects are so happy is that they have lots of friends

17. Which are kept through links or URLs in their public state

18. FOREST Objects link up into a single Web - "hyperdata" - a s emantic Web!

19. A Global Object Web

20. FOREST Objects interact with their friends

21. An Object affects another through its public state

22. "An object's state evolves

23. An Object affects another through its public state "An object's state evolves as a function of

24. An Object affects another through its public state "An object's state evolves as a function of its own state and

25. An Object affects another through its public state "An object's state evolves as a function of its own state and the state of other objects, local and remote,

26. An Object affects another through its public state "An object's state evolves as a function of its own state and the state of other objects, local and remote, that it observes directly or indirectly through links"

27. A Global Interacting Object Web

28. Now for a simple example - an Object whose state is a function of a couple of sub- Objects.. it joins their text up

29. joiner Hello World Hello World

30. joiner Hello World Greetings World

31. joiner Greetings World Greetings World

32. Let's see that again... it's your first FOREST program!

33. joiner Hello World Hello World

34. joiner Hello World Greetings World

35. joiner Greetings World Greetings World

36. "An object's state evolves as a function of its own state and the state of other objects, local and remote, that it observes directly or indirectly through links"

37. An Object's state will be much more complex than that example: it's an arbitrary JSON structure

38. State update notification is propagated to observing Objects asynchronously - through queues

39. An Object can read a linked Object's state at any time; FOREST supports eager and lazy modes

40. So FOREST is easy to program: look at current and linked states, then set new state accordingly

41. You can still use traditional Objects for this animation on the inside

42. FOREST Objects can still be animated in any language Java Scala Python Erlang Clojure C# Ruby F# Javascript C Haskell

43. But more naturally, FOREST Objects can be programmed Declaratively

44. Which is a lot like... Rules Programming HTML CSS Spreadsheet Formulae

45. Another reason FOREST Objects are so happy, is that they're free!

46. Not just free of being told what to do by other objects, but free of a bounding application

47. FOREST is a Global Interacting Object Web

48. Application Traditional Objects can only work in an application context Application

49. And you have to do all the co-ordination, threads and remote calls yourself, Imperatively

50. A FOREST Object only has itself to co-ordinate.. it doesn't need an application

51. All it needs is its animation rules, a thread to run on, a URL and the observed state of peer Objects

52. Thus FOREST Objects are inherently Concurrent

53. Objects manage their own state in a naturally parallel way without programming locks and threads

54. Implementation of data-driven and concurrency patterns such as map-reduce is easy in FOREST

55. FOREST Objects are also inherently RESTful HTTP

56. Thus you easily get all of the REST benefits: interoperable, scalable, evolvable, etc. HTTP

57. The symmetry between Objects is reflected in client-server HTTP symmetry HTTP

58. Local and remote Objects look the same, easing the partitioning of Objects across servers HTTP

59. The state-reaction programming model maps naturally to eventual consistency approaches HTTP

60. FOREST Objects are usually persisted - after a state change

61. That would probably be in JSON, perhaps in a NoSQL DB

62. In Part 2.. Looking into FOREST Objects