[qrcodetag size="150" link="false"/]Sometimes, stunts go wrong. Why is that so? Apparent reasons are a lack of preparation and a poor performance during the actual stunt.

Our own ICSE stunt did go wrong and our paper was rejected. Which, and that we have to admit, was absolutely justified. The reviewer pointed out the weak points in our paper:

*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=–=*=

First reviewer’s review:

Summary of the submission < <<

The paper presents an approach in which the SOA principles are employed to
build App-based application on mobile platforms. The paper describes the
differences between traditional SOA and market-based APP stores on modern
mobile platforms, such as Android. Finally, the implementation of the ideas and
the overall architecture realizing the approach is presented.

Evaluation <<<

This paper has many problems:

(1) The paper sounds like a detailed description of numerous hacks performed to
make App stores on mobile platforms do something that they were never
designed/intended to do. It is not clear what are the underlying research
hypotheses and what are the technical contributions.
(2) The hacks are ridiculously simple. Clearly using the proposed approach one
cannot build very interesting applications. The grammar presented in Figure 3
could potentially result in a very awkward way of passing data between
applications, and that's about it. It cannot replace BPEL and cannot be used to
compose any useful elaborate applications. Therefore, I see the contributions
of this work as a very unwieldy method of achieving copy-paste between mobile
applications.
(3) The paper is poorly written and there are many typos and grammatical
errors.
(4) The paper has absolutely no evaluation whatsoever!
(5) Many of the screenshots are too small to be readable.

Points in favour or against <<<

- No research contribution, mostly description of hacks
- No evaluation whatsoever
- Badly presented, including typos, grammatical problems, and unreadable figures

*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*

Second reviewer's review:

Summary of the submission <<<

This paper proposes the idea of using application markets such as the iTunes
store and the Android marketplace as service-like registries for a SOA-like
programming model for mobile systems built around composition of applications.
The composition mechanism chosen for the approach is URL linking defined
through custom URI schemata, with data passing performed during application
invocation.

Evaluation <<<

At the very beginning of the paper the idea of using the Android marketplace as
a kind of service registry seemed like an interesting idea, but the paper
quickly convinced me that it isn't. In particular, Sections 2 and 3, with their
accompanying Tables 1 and 2, did such a thorough job of showing how
incompatibly different services and applications are that the paper could have
ended right there.

Nevertheless, the authors gamely pushed forward and came up with an
implementation approach anyways. I can believe that they got something to work
(even though I don't believe the paper actually says so), but to the extent
that I understood the details of the approach (which are not described very
well), I find it hard to believe that it constitutes a pragmatic, workable
solution. At any rate, the basic idea of linking application invocations via
URLs is essentially the idea behind RESTful Web services, yet the authors fail
to make this connection. If nothing else, this suggests that the novelty of the
approach is very low.

With respect to details, Section 4 quickly rolls out various snippets of XML
plus some code in some unnamed language (Listing 2) without giving the reader
an overview of what languages and frameworks and technologies the approach
employs. The fact that data linking is done via the phone's clipboard suggests
that a composition of applications must be single-threaded and must be deployed
completely on a single device, but this is never stated explicitly. The end of
Section 4 says that an application composition is presented to the user as a
snippet of XML, but it's unclear what the user is supposed to do with it (even
if they were clued-in enough to recognize it as XML).

The use of URIs to bind applications is poorly explained. The first paragraph
of Section 5 implies that compositions are static, which makes the approach
seem un-SOA-like. And I'm afraid I simply did not understand how data are
transferred between applications. The binding process described in Section 5
seems extremely cumbersome, with the user being asked to download and install
applications in the middle of the execution of a composition, further removing
the approach from the world of SOAs where bindings are meant to happen
automatically.

Finally, the idea of making applications available via QR barcodes stamped on
physical objects like taxi signs seems potentially interesting, but again the
details are unclear. Is the barcode meant to embody the application binary, or
is it a link to an application to be downloaded?

What might have saved this paper is a thorough discussion of the tradeoffs,
pros and cons, and issues underlying this style of application composition. For
instance, if users are constantly downloading and installing and linking and
invoking applications willy-nilly, I suspect device memories will fill up very
quickly. Sadly, the paper doesn't even try to give us insights like this.

Points in favour or against <<<

In favor:

+ The basic idea is cute and worth some consideration.

Against:

- The paper demonstrates that the idea isn't so great after all, both through
the comparison of SOAs and apps and through the description of how it was
achieved.
- The paper presents no evaluation of the approach (not even a qualitative
discussion), despite having extensive amounts of space leftover in the page
count.
- The discussion of related work fails to compare the referenced approaches
with the approach described in the paper, and fails to carefully critique the
extensive amount of work that already has investigated the use of services on
mobile devices.
- The paper is poorly written, being full of grammatical errors, obvious
misspellings (like "Remove" instead of "Remote" in row 2 of Table 1), random
noun capitalizations, and malapropisms (such as the use of "respectively" in
several places). It seems that nobody bothered to proofread the paper prior to
submission.

*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*=--=*

We’d like to thank them for their time and effort. Our next stunt will be better planned and we will start with the training today .

your icse stunt ikangai team

Tags: ICSE 2011, Sevices, SOA, Using URL schemata to bind and invoke Services on mobile devices