This work considers process orchestration for software development on ServiceO-riented Architectures (SOA). In this rese arch the concept of FLIPP explainers are introduced to the web service community. The FLIPP explainer is a conceptual structure providing mass simplification to otherwise complex logic without the use of text or symbols. In this research the FLIPP explainer has been transformed into a workable tool to develop composite applications alongside SOAs as a direct alternative to some of the current products being offered by SAP and Oracle. Tests indicate that the tool has potential to assist in the development of applications but offers more real promise for the visualization of complex systems and processes. Also, the work highlights the fundamental issues that the FLIPP has for software development, including the initial complexity of designing the diagrams. Finally, guidelines for future enhancements and potential work are provided.
diagrams achieve this by creating ‘scenarios’ which portray the unambiguous
options to the user. Sowa [
The most convenient way to describe FLIPP Explainers is through example
and Figure 1 shows a sample FLIPP diagram by Sowa[
A ∧ ((B ∧ ((D ∧ G) ∧ (E ∧ H))) ∧ (C ∧ F ∧ (I ∧ J ))) ∧ K (1) In English the above diagram can be read as follows: “Start with A, if you proceed to B as opposed to C then use D followed by G or E then followed by H. If you follow A with C then use F followed by either I or J. Regardless of route, finally finish with K.”
It is by this reasoning that it seems that web services can be modelled through
these diagrams in order to improve user understanding and also to provide a
logical framework for semi-automated decision making. Although the concept
of FLIPP diagrams in relation to user interfaces has not been investigated yet,
Sowa[
When comparing FLIPP explainers with SAP Visual Composer some of the claims made by Cox regarding FLIPP explainer appear to be subjective. Analyst 1 found that lines were easier to decipher than the box system whereas Analyst 2, although understanding the methodology, failed to see a real advantage at this stage. However, Analyst 3 found that reading the processes was much easier on the FLIPP interface than on VC. Therefore it appears that there are two distinct phases of using the FLIPP diagram in process orchestration; software composition, creating a FLIPP, and software modification, reading from a FLIPP.
Cox’s[
However, Analyst 1 had plenty of knowledge of reading diagrams from UML and other experience but failed to see the benefit of the holistic view. However, when it came to developing the interfaces all the users had at least some initial problems. There appear to be two obvious explanations for this trend. Firstly it could be down to the lack of a finalised interface that caused the user frustration with simple problems such as limitations with the colours or deleting items. However it is more likely that it is harder to plan a system in ones’ head prior to expressing it on a FLIPP interface. The development process of a FLIPP explainer is not covered in detail in Cox’s material yet it is a fundamental part of the process. Therefore with this part of the process proving challenging it may deter other users as well.
A common criticism of the interface in the results is the inability for the user
to create a series of loops or to use iteration to reach a particular goal. Analyst
3’s suggestion of using bolder borders, seems like a particularly interesting idea,
especially when compared to the idea of having linking arrows, thus effectively
detracting much of the simplification from the diagram. However even this leads
to some questions regarding usability as Cox[
Analyst 2 raised the point that between cells in the process there is no method
for identifying the condition that is met to trigger a certain path through the
system. Inside the SAP interface there is generally either a description on a
connecting line or the inputs/outputs to be connected are clearly shown.
However, inside the FLIPP interface at present this information isnt’ availabl e which
causes uncertainty. Pautusso and Alonso[
In order to read the FLIPP explainers the creator has derived a top to bottom methodology as standard. However it was commented on by Analysts 2 and 3 that processes are traditionally expressed from left to right and Analyst 1 automatically began developing in the left hand corner. Analyst 2, in particular, found that the processes should be expressed this way to promote usability amongst differing sets of people. Many of the results taken from the analysts appear to represent the FLIPP interface in a bad light. However the analysts didnt’ report that the interface contained any fundamental problems. All the analysts agreed that the interface was easy to read from and many of the points mentioned above are purely improvements that would be necessary to use the interface for on a full scale implementation.
One major problem that has become apparent with the FLIPP explainer when used in this context is related to the connection of inputs and outputs. Each of the analysts liked the simple method of connection that the interface utilised by combining the inputs via a single screen. However the problems become apparent in the modification of the grid layout. When the grid is moved with the web services attached it can effectively disconnect any connections that have been made when the web services were placed in the grid. 3
Conclusions The principle contribution is that the FLIPP explainer appears to have a future role in the composition of web services, assuming that some of the initial limitations can be resolved. In response to the original question, of whether it is possible to portray more information through a simpler visualization, the results indicate that it is possible to convey more information through a FLIPP based interface than through the current implementations. This is substantiated as follows: – Although the results suggest that it is easier to read data from FLIPP diagrams, it is not clear whether it is a tangible effort or time saving approach for the user; – Being able to compile FLIPP diagrams quickly and accurately appears to be an ability that requires some degree of skill; – The benefit of process visualization via FLIPP diagrams also depends on the person involved to a certain extent. However it appears to be less important than when creating systems.
It is apparent that the FLIPP explainers original claim by Cox[
One of the limitations of the FLIPP interface is that it still fails to provide an adequate method in assisting users to select the correct services for their applications. In its current form it serves simply as a tool in the armory of the Visual Composer user, and would best be used as an optional construct dependent upon the developer’s preferences.
However, the tool still has a much greater potential when assisting
information visualization. Ultimately, this is the strength of the FLIPP explainer, and
by implementing a system where the grid is used to assist in modifying
previous composite applications, or for identifying useful components from other
processes, its potential will be maximised.
This work represents the first stages of a topic that could potentially lead in many
disparate directions. Firstly, the immediate future would be to create an interface
with sufficient functionality that it could be used inside an SOA environment
to provide genuine ‘like for like’ tests. This, followed by more detailed a nalysis
of user behaviour in the environment would provide a detailed insight into the
real benefits of FLIPP diagrams for a variety of users. Another possible use
of the FLIPP diagram is to combine the interface with other Common Logic
tools. This would enable users to quickly and easily search for a process that
would meet their exact needs whilst communicating the relevant output via
the FLIPP interface. Sowa[