Project details

Joty is a purely Java based framework that for the Workstation part is largely based on the javax.swing package of Java SE, Joty Server, in the Core part, is a subclass of the javax.servlet.http.HttpServlet class of Java EE, and the Mobile part is based on the Android Sdk and Java SE

The Joty Workstation classes dedicated to the graphic user interface are typically subclasses of Swing classes, but they makes no use of various flavors of layout management: they adopt almost ever fixed sized windowing and absolute layout. Nevertheless they form a layer specialized in addressing the data access either directly through the Java Database connectivity or by means of the Joty web infrastructure that is described onward. Anyway, as any framework built on another one, Joty Workstation allows the access to the Swing API substantially anywhere.

The visual classes of Joty Workstation are renderable by the Eclipse WindowBuilder environment and the same is for the implementation classes derived by them. A custom toolbox extension is available for the WindowBuilder palette; dragging and dropping the objects or the factory methods, contained in it, over the visual area of rendered objects already under editing is a way to implement a Joty visual resource at its first stage level of development: the code generated by the dropping action must be finalized by actualizing the default value of the parameters there mentioned and this may be the start point for further development. The Joty plug-in for Eclipse, then, helps avoiding naming conflicts.

From the data level to the presentation level, composed by fixed sized dialog populated by Swing descendants visual components, Joty Workstation provides a sort of shortcut for a correspondence between a database table field and a visual component that renders its value and allow the editing of it.

Then, responsibilities were identified for the selection of the data set, for the navigation of the data loaded in memory, for performing an editing session on a record and for saving modifications performed on it, but in this process the duality of the mode of accessing data (shown in the image above) was pursued

The visual classes of Joty Mobile play an analogous role in mapping the database table field to a visual widget but Joty Mobile works only through the web: no dual mode is supported since it makes no sense

The mapping between data and visual objects is made by several methods of a factory class in Joty Workstation while is made by the various visual class constructors in Joty Mobile.

The structure of the framework has been built on a restricted set of data types in respect of those ones of the java.sql package and a mapping obviously has been made: this happens in Joty Core.

Joty packages

The org.joty.workstation.gui and org.joty.mobile.gui packages are composed by the classes that provide visual appearance and behaviors to the user.

Then those classes invokes the services of the org.joty.workstation.data and org.joty.mobile.data packages respectively and/or the ones of the org.joty.workstation.web package in a web scenario for Joty Workstation and of the org.joty.mobile.web package always for Joty Mobile.

The org.joty.workstation.data and the org.joty.mobile.data packages have the roles of main dispatcher of the data access requestes: the WResultSet and the JotyDB classes virtualize the underlying data layer, that is, in web mode, they invoke the contribution of the respective org.joty.<..>.web package. Anyway, in Workstation - web mode or in Mobile, not the whole data access activity flows through the org.joty.<..>.data package, the org.joty.<..>.gui package also invokes directly the help of the org.joty.<..>.web package.

The request of data access, either just querying or disposing changes, either as part of a transaction or as a standalone statement, is packaged in a structure defined in the org.joty.common package (the BasicPostStatement class); then the org.joty.<..>.web.WebClient class builds the xml Joty request using the set of BasicPostStatement objects collected and forwards it through the http channel by means of the org.joty.<..>.web.WebConn class. Joty Server receives the xml request and builds the PostStatement objects, then takes the proper actions for processing them, embracing their execution in a dbms transaction if requested, and composes an appropriate xml Joty response and returns it to the client. This scenario says why the org.joty.common package is deployed to both the sides of the Joty infrastructure. Anyway the package was designed so that its ingredients were useful on both side (meaning that the client side is impersonated either by the Workstation application or by the Mobile app and the server side by Joty Server) as its name lets understand.

The org.joty.workstation.app.Application class has the responsibility of the life of the workstation application object as the user can perceive it.

The class takes care of recognizing the running mode and, if the web mode is the case, to support the Java Web Start standard, so that the implemented Joty application can benefits of the inherent advantages of the associated deployment and launching facilities. In web mode, then, the class manages the server certificate negotiation for ssl connection to be used during the user authentication. Then it manages the authentication presenting the user the visual objects of the org.joty.workstation.authorization package. After that it loads the user preferences possibly previously stored in the workstation environment, furthermore it loads the almost static data in memory, the language vector, the roles vector associated to the authenticated user and all the attributes from the configuration file.

The org.joty.mobile.app.JotyApp class plays analogous roles in the mobile scenario addressing various dedicated classes of Joty Mobile

Both the classes above implement the org.joty.app.JotyApplication interface and use an instance of the org.joty.app.Common class, belonging to the Joty Core, to behave similarly.

The org.joty.access package, beyond supporting many tasks like the reporting management, giving integration with the BIRT (Business Intelligence and Reporting Tools) technology, it takes great importance since it hosts the Accessor class and, as such, it is deployed either to the server side or into the Workstation application when it runs in local accessor mode (see the definitions given just below in the dedicated paragraph).

Joty artifacts

The artifacts (in italics) and the respectively contained java packages (dotted rows) are the following:

    joty-core-app
  • org.joty.app
  • org.joty.data
  • org.joty.gui
  • org.joty.web
    joty-core-common
  • org.joty.common
    joty-core-mix
  • org.joty.access
  • org.joty.basicaccessor
    joty-server
  • org.joty.server
    joty-workstation
  • org.joty.workstation.app
  • org.joty.workstation.authorization
  • org.joty.workstation.data
  • org.joty.workstation.gui
  • org.joty.workstation.web
    joty-mobile
  • org.joty.mobile.app
  • org.joty.mobile.authorization
  • org.joty.mobile.data
  • org.joty.mobile.gui
  • org.joty.mobile.web

The parameters context

In order to simplify the actualization of the value of the parameters present in the database expression used along the Joty application, the concept of parameters context has been adopted: the context is a container of values where each value is associated to a name; instead of worry about procuring the value of a parameter when a formal parameter must be actualized the developer can store this value when it is easily available, that is on the scene of the development, and he/she has only to choose a convenient name for it. Later, when a formal parameter will have to be actualized, that context, if still valid (there can be more contexts at the same time), can be looked up using the name chosen before. The framework provides the developer with several methods for addressing the convenient parameters context. There exists the concept of current/local context which the framework identifies implicitly addresses equipping JotyDialog class with store/retrieve methods for parameter values for storing and retrieving values at any time.

An very important context is the one associated to each org.joty.workstation.gui.JotyDialog instance: JotyDialog hosts a context instance and initializes it making a copy of the one of the caller (opening) JotyDialog instance if the latter passed its reference in the call; since it is the case for the most part of the opening flow that is depicted by org.joty.workstation.gui.DataAccessDialog instances having dependency relation each other, every JotyDialog instance has its own copy of value for each named parameter directly collected or inherited by the call. Another important parameters context is kept by the org.joty.workstation.gui.Application object and by the org.joty.mobile.gui.JotyApp object.

The Accessor mode

The resulting scenario, derived from the structure of the framework, even if it is the desired conclusion of what was searched for, it resulted in a little insecure asset in respect of the possibility to disassemble the byte-code of the jar file of the downloaded application or of the apk file of the mobile app. This could let know the database name space there contained and this, by self, decreases the security of the technology. However, desirable or undesirable that could be, the duality of the running mode for the Joty workstation application was an original goal and an introduction of an actual layer that can hold this name space and the expressions that rely on it, would be antagonist with the duality because it should be placed on the server side or, at any rate not in the client node and this would make the duality lost because, for example the test of the web application could not be performed in the lite running mode: the desktop standalone workstation application mode.

In order to accommodate these antagonisms an extension of the duality, capable of hosting what should be kept secret, was needed: a class capable of leaving in both sides of the framework (server and workstation client, only) and, beyond collecting any critical statement or database name inherent to the data access, it should be able to recompose the final statements even when living into the remote side.

This class is the org.joty.access.Accessor class: it provides a coordinate system that addresses the data managed by the visual objects of the Workstation application; this system can be used by the Mobile app also, either in order to collaborate with the workstation or to make an independent addressing to database access expression, provided that the hierarchical structure living there, is respected, or, even, the data access expression are collected by name in the embedded collection: the data expressions for all those classes that descend from org.joty.workstation.gui.DataAccessDialog and from org.joty.workstation.gui.DataAccessPanel and that are addressed just by means of the class full name of them (here a simple overall insight is given), for which classes the accessor mode is desired - note that the accessor mode is implemented on DataAccessDialog basis so that the Joty workstation application can be developed at the beginning in the normal mode and later , incrementally that is DataAccessDialog by DataAccessDialog, can be converted in accessor mode transferring the definition of the updatable set and of the query set from every DataAccessPanel of the Dialog to the implementation subclass of the Accessor class developed specifically for the application.

Then, the framework on the basis of a declarative statement that states that a certain dialog is to be processed in Accessor mode, will search the database statements or names in the accessor implementation class instead of in the DataAccessPanel class and the lookup will be performed using the coordinates of the DataAccessPanel (the full DataAccessDialog class name of the container plus the ordinal position of the DataAccessPanel object within the vector associated to the container dialog (actually the model explained here is a little simplified because the Accessor class hosts also the statements of the structured components inside a DataAccessPanel object - in this case the coordinates of the structured component is the ones of the container plus the Term name of the component.

...And when the Accessor runs on the remote side how can it know the environmental context in which originally the statemets were built ? Well, the answer is in the parameters context that is delivered to the Accessor together with the coordinates of the object - the application Accessor object collects not only the expressions but the way to read the parameters context that takes form at every invocation of the accessor contribution.

As it can be seen in the figure aside, where all the possible allowed scenarios are represented, where the Accessor lives on the local side (second and fourth blocks) no gain is got in term of security because the repository of the used database name space is still in the jar of the downloaded application but no change to the code is to be made to reach the scenario of the third block (Accessor in the remote side); only a deployment choice and the setting of a configuration attribute have to be done: the framework adapts the execution flow conveniently.

It can also be seen that (as illustrated in the fifth block) the Accessor can be prepared and kept local during the life of the workstation application in the desktop standalone mode. This is perfectly in harmony with the original mission of the Joty framework: allowing a simple switch for passing from the testing in desktop mode to the testing in web mode.

The Accessor class is equipped with other features that is not convenient treating here but it is evident that, with its attitude to build the representation of the parameters context of the caller environment, is a candidate to host any sort of computing to be placed to the remote processing node, either the processing is for accessing some external system or not. It can be said that, with the introduction of this class, Joty 2.0 acquires an optional improvement on the server side.

A particular note must be pointed about the Accessor mode: the DataAccessDialog classes of the org.joty.authorization package are coded already in Accessor mode for keeping their database context safe and that context is embedded in the org.joty.basicAccessor.BasicAccessor class (an extension of the Accessor class). This class indeed must be the root for deriving the application Accessor object. The BasicAccessor class is located in a package dedicated, even if it descends from a class of the org.joty.common package, because it must be available for autonomous deployment, that is it must be possible not to follow the org.joty.common package that is always present on the client side.

The mobile part of the framework supports the accessor mode only in the remote flavor: that is the Joty Mobile app can be developed relying or not on the accessor mode; in the positive case it will address the data access constructs hosted by the Accessor instance located on the server side - the Joty Mobile app cannot host the Accessor object; in the negative case the data access statements can be written directly in the Joty Mobile app implementation code by means of the primitive of the Joty Mobile part of the framework.

Just a bit of Java Reflection

The instantiation of the extension of the org.joty.access.Accessor class and of the org.joty.access.DbManager class have been made possible through Java Reflection for the following reasons:

  • Their implementation is instantiated also by Joty Server
  • It was desired to avoid (even it is possible specifying the full class name in the org.joty.app.Application) the derivation of the org.joty.server.JotyServlet class (where an hypothetical creator method would be overridden to instantiate the extension).

The instantiations of all the implementations of the org.joty.workstation.gui.JotyDialog class can occur by the use of its static method tryCreate that relies on the Java reflection to provide complete existence checking on any application specific implementation of the visual class 'appended to the visual tree'.

A subscribers-publishers model for data reloading in Joty Workstation

Joty Workstation allows many data dialogs to be opened at the same time and the application design might define that many data access dialogs present the same data, even if from different points of view

The solution adopted to manage the required updating of the displayed information by other data dialogs when a data dialog modifies a "shared" datum, is the following:

  • At application scope it is maintained a subscribers-publishers map each element of which associates a publisher dialog name with a set of subscriber dialog names.
  • A publishersSet list and a reloadBecauseOfPublishing flag are held by each data panel (see org.joty.gui.DataAccessPanel class) and by each data grid (see org.joty.gui.TableTerm class).
  • Each data panel and each grid that wish to be notified by the change in a data dialog makes the 'subscribe(publisher dialog name)' action
  • Each data panel and each data grid that wish to broadcast there modifications mark themselves as publishers
  • The framework makes each object modified and marked as publisher to perform the 'publishThisDialog' action (meaning the data dialog which the object is in)
  • The 'subscribe(publisher dialog name)' action performs the following steps:
    • Let say 'alfa' the name of the data dialog which the subscribing object is in, ad 'beta' the publisher data dialog name:
      • if in the map the element for 'beta' is missing it is created with an empty set of subscribers associated
      • 'alfa' is added to the subscribers set associated to 'beta'
      • 'beta' is added to the publishersSet in the subscribing object
  • The 'publishThisDialog' action performs the following steps (let be 'beta' the name of the publisher):
    • the subscribers-publishers map is looked up for 'beta'
    • for each subscriber 'alfa' found in the associated set (and currently open) do:
        for each data panel and data grid contained in 'alfa'
      • look in its publishersSet and if 'beta' is present set its reloadBecauseOfPublishing flag to true
  • When a data dialog is activated (by any visual event capable of this) the currently selected data panel and all the inner data grid are polled in order to detect any true setting of the reloadBecauseOfPublishing flag: if found the interested object takes the following steps:
    • reloads its data.
    • sets to false the reloadBecauseOfPublishing flag
    The same is done when the user select another data panel (if present)

This asset results in producing an acceptable degree of efficiency because

  • data reloading never happens by involving the entire data dialog and can leave inert also the composing data panels when only an inner data grid is interested
  • data reloading happens on data dialog activation only, when the information are actually searched for by the user.

Joty classes

The complete class diagram of Joty 2.0 can be seen in the next image and the source code documentation is here.

The "Term" class as a wrapper of any visual element

Either Joty Workstation or Joty Mobile have the class Term thought to embrace attributes and more in general the dynamic state of any visual element that hosts a datum or a data set. The difference between the two sub-frameworks is the nature of the delegated object (the inner gui member) managed by the wrapper: in Joty Workstation the member is made by a type belonging to the Joty framework, as it descends from a library class upon which Joty stands; in Joty Mobile the controlled member is picked up as is from the underlying framework, indeed its type is belonging to that framework without no inheritance control.

Joty threads

Joty fulfills the requests of the user in a different way as a matter of threads in the Workstation part and in the Mobile part. In Joty Workstation substantially the main thread (the gui thread) is loaded completely with the responsibility to perform the whole task ( a part from isolated cases in which an auxiliary thread is used ). In Joty Mobile, due to the responsiveness constraint imposed by the Android Os, for all the long time operations a background thread is used to carry on the committed task (see the source code documentation about the org.joty.mobile.app.JotyApp.ResponseHandlersManager class).

Joty communication protocol

The format of the xml exchanged by the two sides of the framework is resumed by the following xml schemas: JotyRequest.xsd and JotyResponse.xsd.

Joty Workstation and Joty Server logging activity

Joty framework has its own Logger that writes four logs:

  • JotyDesignLog.log file: a log located in the user home directory that serves as medium for the contribution that Joty plugin offers to the visual designer used for the development of the workstation application

  • JotyDeskLog_YYYY-MM-DD.log file: a daily log located in the user home directory that traces the workstation application exceptions and, in debug mode, the complete request/response description

  • JotyServerLog_YYYY-MM-DD.log file: a daily log that traces the exceptions on Joty Server

  • JotyDbActionLog_YYYY-MM-DD.log file: a daily log that traces any statement performed by Joty Server that makes some change to the database.

The org.joty.common.JotyMessenger interface guides the availability of the primitives that either on the org.joty.workstation.app.Application, or the org.joty.server.JotyServer perform the logging activity; the implementation of the same interface by the org.joty.mobile.app.JotyApp class behaves a real messaging to the user, in the form of an Android Toast or Dialog.

Note: BIRT engine performs its own logging activity and Joty configuration sets the location for it.

Joty extensibility

The framework can be extended even without modification of the source code because some critical class is loaded by means of the java reflection mechanism and its name is mentioned in the configuration file: so that a new descendant of that class can be written and put in the class path and at last its name must be put in place of that of its ancestor.

Anyway Joty 2.0 is a free software and within the terms of the license under which it is distributed, it can be used and indeed modified.

Joty license

Joty 2.0 is a free software and is distributed under the terms of the GNU Lesser General Public License. License terms are here illustrated.