Grid computing promises the potential to coordinate vastly distributed computational resources into a coherent whole. In doing so it poses qualitatively novel challenges to the field of technology. The socio-political structure among Grid participants is far from obvious; the software communication protocols are complex; and the actual deployment of a ready service onto a grid is exceptionally non-trivial. 

• Introduction - The Grid.
• What is the project? Being a service made easy
• Why is it a good project? Anything is only as useful as it's used.
• What exactly? The Deliverables
• Technology to be used - Languages, libraries, toolkits etc.
• Development Timeline
• Why me? Good timing, Good skills, Good faith.
• My relevant experience - What I've worked on before

Assuming that we have a working grid at our hands, the development, deployment and maintenance of a service is still difficult. At the moment, the participation threshold for anyone but the technology wiz is simply too high. Thus we aim to create a browser-based user interface with the goal to bridge the gap between the highly domain specific complexities of WSDL/WSRF/etc and a seamless user experience. Imagine a South American student on an XO laptop successfully deploying a Grid service - that's our dream.

Conceptual design: After discovering services by search 

and by browsing the service archives, a service flow is 

easily created by connecting services to each other.  

In short: Grid computing has huge potentials but is still a young technology and extremely difficult to use. In order to leverage its fullest potential the participation threshold has to be lowered, and the user experience made more pleasant. 

Our particular choice of a browser-based GUI has the obvious benefit of easy distribution and minimal client requirements.

Ravi delivers a deployable war file for Apache servers, complete with XML configuration files and necessary java classes. This makes it manageable to deploy a web service for a novice terminal user. However, implementing the actual service still requires e.g. advanced knowledge of domain specific java libraries, not to mention manually editing the service XML specification files. The missing component is an enhanced xhtml/javascript UI for easily building services at multiple layers of detail (from drag and drop to actual code editing). The critical sub-components will be:

• Foundation
• The Portal - An encompassing and familiar UI theme and framework. ExtJS is the primary candidate javascript/css library for this.
• RESTful API - Greater interactivity calls for asynchronous client/serve communication, which in turn demands an http API.  
• UI Components
• Source File Tree - At the finest level of control, we want to be able to manually view and edit some of the service's individual files. They should be accessible through an ordinary file tree structure.
• Code Editor - Similarly, we need a way to view and edit raw ASCII text in a user friendly and reliably manner. A Notepad clone at a minimum - TextMate would be nice.
• Searchable Component Library - In order to kick start development and get the novice going, we need a library of basic functionalities that can be incorporated into one's service. If we imagine the possibility to publish services, there could over time be a publicly built archive of incorporable functionality. 
• Drag and Drop service construction - See the Conceptual Design figure above. Dragging building blocks from the Component Library of the public archives, the user could connect functionalities into a customized service. JsViz supplies some of the required UI functionality, and a first step towards this UI component will be to do some minor improvements and customizations to JsViz to allow for greater display and event handling control. 

Server side: REST - As GT4 and gRavi is implemented in Java, I expect to work strictly with Java on the server side. The major server-side component should be the implementation of a RESTful HTTP API, which should amount to a minor module extension to the servlet created by gRavi.

Client side: UI - The two primary goals for the UI is accessibility/ease of use and ease of distribution. People with computers and Internet access pretty much universally have a web browser on their system and experience using it. Thus the browser platform is the perfect platform for distribution. Dynamic user interfaces can be created in browsers using javascript, html and css. Combined with fluent/asynchronous server communication with xml or json, we get what people call ajax. 

Ajax is difficult for two reasons

1. You have to use at least 4 distinct technologies (html, css, javascript and a server implementation of your choice).
2. Two of them vary significantly across platforms (css and the javascript DOM api)

The first is simply a matter of experience - I consider myself to have that experience. The second is dealt with by leveraging various javascript libraries that abstract cross platform incompatibilities, such as ExtJS, jQuery, mootools, prototype, yui, (or any of the by now 100's of open source libraries out there) and create a smooth, solid development foundation.

I believe the following libraries will be of significant help and importance:

1. ExtJS for the overarching UI style and framework
2. JsViz for the service connectivity flowchart UI
3. jQuery or Mootools if there are any small pages not belonging inside the main UI framework

My intention would be to work on the project part time, ca 2-3 hours per day for a 10-15 hour work-week. The outlined timeline give milestones - naturally, much of the work will be done more in parallel (and obvious things like test case development and documentation are omitted) but the timeline milestones offer a good outline of the development process. Assuming 10 weeks of active development, I imagine the process to go something like this:

• Part I - UI Design and server REST API 
• Week 1: Explore the code created by gRavi, understand what is gRavi and what is GT4, and implement the servlet module through which the http/ajax calls will be made.
• Week 2: Figure out what the main UI components will be, and start implementing them, e.g. a tabbed navigation layout, a code editor, a service component drag and drop canvas, a service component filetree, and a searchable service component archive
• Week 3: Wire together the UI, i.e. have UI interaction manipulate server state through AJAX calls to the REST API. Make an "execute" button.
• First developmental Prototype - Have mentor and GT4 familiar users test and comment. Open a bugzilla forum for bug reports.
• Part II - Service deployment and composition with component drag and drop
• Week 4: Create a UI for the gRavi creation process, effectively allowing the user to create a scaffold service that can then be interacted with through the code editor and the drag and drop canvas.
• Week 5: Create a UI for "service components" that can be wired together on the client side, and create corresponding java classes on the server side.
• Week 6: Wire together the service component client-side UI and server-side implementations.
• Second developmental Prototype - Have friends and family use and comment on the UI framework. See what obvious things I overlooked.
• Part III - Components made editable and publishable
• Week 7: Figure out a way to make the service functionality storable in a database. Implement an AJAX code editor to enable editing these components.
• Week 8: Implement the service archive and make it searchable. Create an archive UI component to browse and search published components, and allow for publishing your own service components.
• Third developmental Prototype - Public release? Allow for people to test drive and comment.
• Part IV - Testing and evaluation
• Week 9: Testing, testing, testing. Break the code and fix it. Then do it again. And again.
• Week 10: Evaluation and documentation.
• Alpha version release
• Week 11: Padding - because software developers are optimistic and always underestimate time requirements.
• Week 12: Padding

Most importantly, I believe in the potential of the Grid and find it a natural next step in the development of technology and communication in a global society. In addition, I have a fitting combination of 

• 4 years theoretical experience within computer as an undergrad CS student at the University of Chicago,
• 2 years practical experience with ajax both within industry and the open source community,
• A lifelong interest in usability and a sincere dedication to the mantra Form Follows Function,
• A passionate drive for development of Good Code,
• The belief that Open Source is the question that leads to the answer 42.

Relevant academic CS classes, taken at the University of Chicago 

• Grid Computing - CMSC 23340
• Networks and Distributed Systems - CMSC 23300
• Software Construction - CMSC 22001

Relevant software experience

• Significant experience with the ExtJS javascript user interface framework, a good candidate for creating the gRavi UI.
• Significant experience and open source contributions to the JsViz graph display toolkit
• 8 months of experience with web applications written in Java

Here is a Resume of other "real world" work I've had experience with.

Example products created

---

Implior database user interface

User interface created for Swedish company Implior, summer of 2007

   Click for full size image

 

---

ShareWithMe - Spare time project: online user interface for document/image/video management

                          

Video demo  - system overview        Video demo  - Cut and paste videos into documents by drag and drop

---

Showcase for Implior: Javascript/XHTML/CSS UI for an implementation of the Miss Manners benchmark written for the company's in-house Rule Engine:

http://www.marcuswestin.com/Demos/MissManners/

---

Fingerprint - A Javascript tool for fingerprinting password keystroke timing, and passing it back to the server along with the username and password

Blogged about on Ajaxian