The jo-client-platform is a 3 layer CRUD application framework for java with a ui layer based on jo-widgets.

• CRUD Application API

  • Make it more easy to develop 3 tier enterprise CRUD applications

• Single Sourcing

  • Write applications only once for different deployments (WEB-APP, REMOTE-CLIENT, FAT-CLIENT)

• Exchangeable data layer

  • JPA and NEO4J support exists so far

• jo-client-platform-samples
• jo-useradmin
• jo-modeler

The modules of the platform are devided into UI, Service and Common. This makes it possible to deploy 3 Tier Java Desktop Applications or AJAX Webapplications based on the same businesscode.

By using the RWT SPI impl of jo-widgets, JOCAP applications can be deployed as AJAX WEB Applications. The UI and the Service layer will be deployed on the server tier for that.

The UI layer will be deployed on the client tier, e.g. with help of webstart. The client may use one of the supported jo-widgets SPI's like Swing, SWT or JavaFX. The service layer will be deployed on the server tier, and the remoting will be done (transparent) with help of the JOCAP remoting module.

For standalone applications or just for easy testing and debuging during application development, it is possible to deploy the ui layer and the service layer on the client tier.

• Virtual Bean Tables with millions of (virtual) rows
• Sorting and Filtering in the data layer (not in the client table)

• Default controls for the common value types (String, Boolean, Integer, Long, Double, Short, Date, Lookups, ...)
• Different display formats (e.g. long, short, date, date_time, ...)
• Custom control panels for all attributes possible

• Generic bean forms (just attributes must be defined)
• High and low level layouting
• Binding
• Validation

• Visualisation of bean releations
• Modification of bean releations (link, unlink, create and link, ...)
• BeanRelationTree
• BeanReleationGraph (Graph visualization of a bean relation network)

• Bean Validation support (JSR 303)
• Custom validation support
• UI layer validation for convenience purpose
• Service layer validation for security / consistency purpose

• Executable checks (e.g. why is that button / action grey)
  • BeanExecutions
  • BeanDeletion
  • BeanModifications
  • ...

• Provides all informations and services for an entity id
  • CRUD Services
  • BeanDtoDescriptor
  • EntityLinkDescriptor

• EntityComponent (uses EntityService to create a complete master / relation / detail component)
• EntityApplicationFactory (uses EntityApplicationService to create a complete workbench application)

• Asynchronous result callback
• Cancelable services
• UserQuestions to the UI layer
• Progress propagation to the UI layer

• API to provide value sets in the UI layer
• Different display formats
• LookUpComboBox

• Extension of the default functionality with plugins

• Authorizations for all CRUD services by annotations
• Service decoration in the service layer prohibits execution
• Service decoration in the UI layer for better usability
• Expandable by custom security aspects

The data layer for JOCAP applications can be exchanged.

• JPA support
  • Special Hibernate service decorations
  • Special Oracle service decorations
• NEO4J support
• Other data layer supports possible

• No third party dependencies for the core
• Addons that uses third party code are isolated in separate modules

The service API will be used to register and consume any kind of services. While JOCAP provides predefined CRUD services, this API can also be used independently from JOCAP. Features:

• Light weight ServiceRegistry and ServiceProvider
• Service injection with help of JavaServices, Spring, OSGi or other DI Frameworks is possible
• Generic Service ID's for easy service access (no casts needed)
• For each ServiceID there is at most one instance
• Redundant Service Resolvers can be registered
• Multiple service instances for any service interface (not Service ID)
• Injectable service decorators allow powerfull aspect weaving (e.g. remoting aspects, security aspects, ...)

Example:

      IReaderService<Person> readerService = ServiceProvider.getService(ReaderServiceIds.PERSON);

The plugin API will be used to register and consume any kind of plugin. While JOCAP defines a lot of plugins, this API can also be used independently from JOCAP. Features:

• Light weight PluginRegistry and PluginProvider
• Plugin injection with help of JavaServices, Spring, OSGi or other DI Frameworks is possible
• Generic Plugin ID's for easy plugin access (no casts needed)
• Plugin filter with help of typed plugin properties
• Multiple plugin instances for any Plugin ID.

The security API provides a light weight API to provide:

• AuthenticationService
• AuthorizationService
• SecurityContext

The security API can be used independently from JOCAP.

Provides all interfaces that are used by UI and by service layer together.

Services:

• CreatorService
• LinkCreatorService
• ReaderService
• RefreshService
• LookUpService
• UpdaterService
• ExecutorService
• DeleterService
• LinkDeleterService
• EntityService
• EntityApplicationService
• AuthorizationProviderService
• PasswordChangeService

Provides all interfaces that are used by the service layer.

Provides all interfaces that are used by the UI layer.

Widgets:

• BeanTable
• BeanTableSettingsDialog
• BeanForm
• BeanSelectionForm
• BeanRelationTree
• BeanRelationGraph
• BeanLinkPanel
• BeanLinkDialog
• BeanSelectionTable
• BeanSelectionDialog
• BeanDialog
• SingleBeanForm
• AttributeFilterControl
• LookUpComboBox
• LookUpCollectionInputField
• BeanTabFolder
• ExecutionTaskDialog

Workbench:

• EntityComponent
• EntityApplicationFactory

The JOCAP remoting decorates the services of the Service API described above. Even callback parameters of services work fine, if the UI and service layer is deployed on different tiers. The JOCAP remoting can easily be injected. If the developed application only uses default services or default callback interfaces of JOCAP, it is non-essential to know all details about remoting works. Actually the application code normally has no dependencies to the remoting, but the launcher code. Nevertheless, the remoting layer stack and the involved API's will be shortly decribed here:

The message API is a low level API to send and receive messages with an reply channnel.

    public interface IMessageReceiver {

       /**
        * Callback to handle a message.
        * 
        * @param message
        * @param reply channel
        */
        void onMessage(Object message, IMessageChannel replyChannel);

    }

It builds the base layer for the JOCAP remoting. The following implementations are available so far:

• HTTP (based on the javax.servlet API and org.apache.httpcomponents)
• AKKA (uses AKKA for the implementation)
• Socket (uses plain java sockets, not for productive use)

The messaging API can be used independently from JOCAP.

The method invocation API allows to invoke low level methods with callback parameters. The default implementation of the invocation API uses the messaging API.The invocation API can used independently from JOCAP.

The invocation service API provides an method invocation service that has an result callback parameter and interim request and response parameters. The default implementation of the invocation service API uses the invocation API.The invocation service API can used independently from JOCAP.

The JOCAP remoting uses the invocation service API to remote the default JOCAP CRUD services and all custom services that uses the default callback parameters of JOCAP:

• IResultCallback
• IExecutionCallback
• InputStream

The remoting can even be extended for custom callback interfaces.

###User administration based on JO CLIENT PLATFORM with Swing remoting client

###User administration based on JO CLIENT PLATFORM with SWT remoting client

###User administration based on JO CLIENT PLATFORM with RWT web client