Pomodoro Project

Hello again.

It's time for an update from the web framework team. We've come a bit further now in our evaluation and it feels like it is time to give everyone better insight into how we are evaluating the frameworks and what criteria we are focusing on.

As you might already know the goal is to find a framework which facilitates smaller projects developed with rapid development. Although knowing this, it might still not be clear what the criteria are or should be so that is why we will explain the criteria we have set up for evaluating these frameworks. As you might see later we will not test every aspect of a framework as we are testing quite a few frameworks in a limited time frame, that is why we are not doing any speed tests as we have to go through a lot of frameworks and might not have acquire enough experience with every framework to be able to utilize the strength of every framework in a correct way. For that reason such critters are not being evaluated, but less about what we aren't doing and more about what we in fact are doing. So let’s go through the criteria one by one.

Convention over Configuration
Frameworks which do not need a lot of configuration to get started, but instead focus on correct naming and placing of files to work properly will be favored as apart from actually learning the convention rules it will free up more time for the programmer, than having to edit a xml file when something is added or changed.

Documentation and Learning
The first part of this criteria is quite obvious, how is the documentation for the framework, this includes API, tutorials, screencasts etc. Is there enough on the framework website to get started properly or will Google be your friend when it comes to getting started. So the first part of this criterion is closely coupled with the second one. How easy is it to actually learn to use the framework? This may vary from person to person although we try to look at how intuitive it is to work with the framework combined with the documentation provided.

Integrated Development Environment
To facilitate development a framework should have support for an IDE. Having the extra functionality that an IDE usually supplies, such as code completion, will cut down on the development time, instead of having an endless amount of notepad windows opened and tabbing back and forth.

So far we've talked about non functional criteria so let’s move on to the more functional ones now.

Internationalization (Localization)
With a more global market the having a multilingual application is almost a must, which is why we will look at the internationalization support provided by the frameworks. How good it works and how easy it is to make alterations to it.

Testing
To be able to ensure the integrity of the application during development the frameworks have to support automated testing. Preferably they should support several kinds of testing such as testing a form or unit testing.

Validation
Something quite common to web applications is the use of forms for input from the user. This is why easy validation of input has to be supported by the frameworks along with error messages. To be more precise, length, pattern matching, range etc. and customizable error messages for every specific input field.

Now you've seen all the evaluation criteria, so how do we actually test all of this you might wonder. Well to begin with the framework is installed and a first "Hello World" application is made, just to see how fast and easy it is. When that is done we begin to develop some functionality to actually explore the framework more. All the functional criteria are tested while the rest are evaluated during the time the functional ones are being implemented and tested.

So that was all of it. Certainly there are more criteria that can be considered and if you feel we've missed something critical feel free to leave a comment.

That was everything for now. We hope you've enjoyed it.

 Hello!

Cloud is becoming more and more popular within the IT industry, the cloud can provide different type of service and in reality almost all of the cloud service is provided through web service.

So what is web service? Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services. In common usage the term refers to clients and servers that communicate over the Hypertext Transfer Protocol (HTTP) used on the web.

When we design the modern web services’ architecture, Roy fielding said, “The modern Web architecture emphasizes scalability of component interactions, generality of interfaces, independent deployment of components, and intermediary components to reduce interaction latency, enforce security, and encapsulate legacy systems.”, according to his idea, we should focus on how the different components of different services interact , how efficient add new component to the system and how to improve the system’s performance. So the problems fall into the integration.

Integration styles
There are four application integration styles:

1. shared database
2. File transfer
3. remote procedure call
4. message bus.

The first is shared database, it is commonly used in an enterprise has multiple applications that are being built independently, with different languages and platforms. The enterprise needs information to be shared rapidly and consistently. But in the Internet environment, it has some issues about performance and security.

Second is file transfer, it uses some application level protocol such as FTP or SMTP to transfer files to both agreed location. The file can be consumed by service providers then the serve will generate the results to the designated location and then the file can be fetched back by client. It used in the 80’s~90’s before the web became popular and mature.

The other two styles are dominating in today’s web services area, for example, SOAP, XML-RPC and REST*. Depend on these styles, in the Internet or Intranet environment, Paul Prescod concludes three strategies in his paper Roots of the REST/SOAP Debate for doing integrations: first, custom protocols. It means you can design you own protocol based upon some existing protocol by study the problem domain. This method is natural but expensive and it is also hard to be reused and have the problem of interoperable. Second, protocol framework, this is what SOAP does. It creates new protocols constantly and can be used in lots of area because it has common features. But it also suffers the interoperable problem, because both the end-point need to agree on how to use the protocol (all right, there is WSDL). Another weakness is all software will inherit the problem made in the protocol. Third, horizontal protocol approach, instead of developing domain-specific protocols, we just use general-purpose protocols to transfer domain-specific data. REST (representational state transfer) is an example. The most obvious weakness is that it will inherit the problems of the general-purpose protocols. But in fact the general-purpose protocol must be designed and tested carefully. But the advantage is more obvious than the weakness because it solve the interoperable problem which is very important in the modern web architecture.

Introduction to REST
This article will have a short introduction about the REST (representational state transfer) and the resource oriented architecture based on it.

Representational State Transfer is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The term Representational State Transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation.

It has following properties:

• Client-server based
  this allows for system needs to be demarcated across client and server subsystems. This can separate the user interface from data-storage issues, yielding greater interface portability. Another benefit is that the resulting server needs are not complicated by user interfaces, and this greater simplicity can lead to easier scalability and performance enhancement.
• Stateless
  this simplifies storage needs as compared to stateful architectures. It means that each request must possess all of the necessary information. Clients must keep track of any state information. This again simplifies the server needs, which can result in easier scalability and performance enhancements. One disadvantage of stateless architectures is that there can be an increase in the information that is repeatedly sent in requests.
• Cache-enabled
  the concept of a cache is the use of large banks of memory to store data. Compared to database retrievals, cache retrievals are significantly faster. The REST architecture calls for the inclusion of cache response constraints, which means that the response data must be labeled as either cacheable or non-cacheable. When the response data is labeled cacheable, the client may cache this and use it as a response for future requests. Advantages here are that future requests can be served directly from the client cache. The potential problem is that the cache data may be outdated.
• Uniform interface
  this constrains all interfaces to be uniform between system components. This improves understandability and separates implementations from interfaces.
  

In general, REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while at the same time maximizing the independence and scalability of component implementations.

Because of these advantages mentioned above and REST is responsible for the success of the Web (HTTP 1.1). Sum Ruby named the resource oriented architecture which follows the REST constraints. HTTP1.1 naturally has these advantages so the ROA (resource oriented architecture) uses the HTTP protocol followed by the third integration strategy mentioned above.

Resource Oriented Architecture
The ROA is a way of turning a problem into a RESTful web service: an arrangement of URIs, HTTP, and XML that works like the rest of the Web.

The ROA has some characteristics:

• Addressability
  an application is addressable if it exposes the interesting aspects of its data set as resources.(1.bookmark is very efficient way in the surf life, so if we can bookmark all the resource include text, pictures, files even methods, it will be amazing. 2. If every resource has a URL, it will easy to use even as another URL's input, for example, it can be used in the translation service)
• Stateless
  when the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. The server never relies on information from previous requests. If that information was important, the client would have sent it again in this request. I think it is the most important feature in ROA, reasons: state would make individual HTTP requests simpler, but it would make the HTTP protocol much more complicated. With stateless, the server never has to worry about the client timing out, because no interaction lasts longer than a single request. The server never loses track of “where” each client is in the application, because the client sends all necessary information with each request. The client never ends up performing an action in the wrong “working directory” due to the server keeping some state around without telling the client.
• With stateless, it is much easier to distribute an application across load-balanced servers.
• With stateless, it is easy to cache.
• With stateless, the users can be bookmarking whatever they want. But it is also hard to be achieved by the developers.
• Connectedness
  a web service is connected to the extent that you can put the service in different states just by following links and filling out forms.
• Uniform Interface
  the service uses the HTTP method as the interface for communication. GET, POST, DELETE, PUT and another two uncommon method HEADER and OPTION.

/Changbin Wang and Yuan Xu

Okey – so we staring to get a lot of attention for this project and that is great. But what is the deal really, what’s all the fuzz about?

This project is about combining ambitious students and corporate interest to create something brilliant.

• Students that participate in the Pomodoro project will get valuable experience, good marketing of their performance and a valuable reference before leaving school.
• From the business side we have interests in evaluating new technologies and draw lessons form application development with these technologies.
• The project will also produce a product that users like you and I can get great benefit from.
• And best of all - we will release it for free to private users and support the Web2Aid project, simply give something back through aid organizations.

So what are we really going to do? The Pomodoro project is a group with several teams that will develop the same product on different platforms. We will use mobile platforms like Android and iPhone. We will also develop a web site using web frameworks for rapid development. Each product will integrate to a central service provider using a web oriented architecture. The service provider will carry the master data so the user can switch between different platforms without any data loss, more popular called the cloud.

This project was launched in the beginning of 2010 and in the early summer the same year we will have a seminar to share our experience and the result. During the project we will keep you updated here on our blog and on our web site. So stay tuned!

Hello!

Hello.

My name is Predrag and together with Martin we form the Web Framework team of the Pomodoro project. We wanted to give all you that are interested an introduction to what we are doing and what you can expect from us in the coming months.

Our focus is on exploring the different web frameworks available to find one or several good ones that facilitate smaller projects developed with rapid development. To be a bit more clear, we want to find frameworks that help the developer by removing some of the coding by offering easier solution to common used functions in web applications, such as support for i18n (multilingual applications), form validation and testing. With features like that the development time should decrease, thus lowering the time to market.

At the moment we are testing the different frameworks by trying out the functionality we are going to evaluate and we are going to continue going through the frameworks for a few more weeks. When that period is over we will begin to implement the Pomodoro web application with the framework that was found to be the best fitting for the project. As we are a bit into the project already we have been able to test a few frameworks already, the ones we've tested are Grails, Stripes, Spring Roo and we are currently testing Ruby on Rails. As you might see there is a mix of different programming languages as we've wanted to test several different and not have a limitation as only test Java based frameworks.

We hope you've enjoyed this small introduction and that you'll follow our work.

If you are interested in development of mobile applications, Android and iPhone, this projects is something for you! We will also explore web frameworks for rapid development and find the best way to integrate it all and store the master data in one central service provider.

Best of all – we will share this information with you at our website www.pomodoroproject.net and at this blog – so drop by to learn more! In the beginning of June we will have a seminar in Gothenburg.

This project is a collaboration between Chalmers, Logica and Jesper Forslund together with 8 students. Stay updated to learn more.