Spring and Shipka distinguish themselves from the other frameworks by providing comprehensive environment for application development including: presentation, backend services, security, remote services, integration capabilities, etc. While having similar objective, they take different approach to achieving their goal. We will use the following criteria to compare the frameworks:

  • Access to data
  • Access to business logic
  • Implementation of presentation functionality
  • Data transactions
  • Data object implementation
  • Integration of third party products.
  • Data validation and conversion
  • Maturity

1. Access to data.

  • Spring – data access is based on the Inversion of Control (IoC) container. It implements the Factory pattern and enables initialization of created objects with static data or other objects registered with the factory. Single bean is associated with every beanId. The most commonly used feature of the IoC is to store singleton objects (like service layer objects, data access objects (DAOs), etc.) and pass them to other objects through dependency injection. Being a Factory, IoC does not provide access to domain objects. “it is usually the responsibility of DAOs and business logic to create/load domain objects.”. Objects, served by the IoC container are configured with XML files or annotations. Developers interact with custom DAOs to retrieve data objects.
  • Shipka – data access is based on the notion of ObjectFactory and ObjectStore. ObjectFactory implements the Factory pattern supporting singletons and object initialization with static data. ObjectStore is object repository that provides access to all application objects (database, XML, remote, etc.). Objects are organized in groups by objectId. The ObjectStore provides generic interface to access, manipulate and query objects that is as powerful as SQL for DB information. It supports dependency injection of objects during CREATE and GET operations. ObjectFactory is one of the object providers (like DB, XML, etc.) supporting the concept of central object repository. It enables developers to access singleton objects through ObjectStore as well.

Comparison – Shipka provides simpler and more comprehensive solution for data access by adding advanced capabilities for manipulation of domain objects.

  • Eliminate the application reliance upon DAO and business objects to serve domain data. The dependency injection is needed only when the application architecture consists of many layers. For example the consumer of domain objects is injected with DAO bean(s) and then each DAO object is injected with the Hibernate SessionFactory, JDBC Data Source, etc. Shipka allows the consumer to access/manipulate domain objects directly through the ObjectStore without any dependency injections.
  • Eliminate the need to code data access functionality using solution specific APIs (for DB access – Hibernate, JPA, IBATIS, JDO; for XML data – JAXB; for remote objects – REST, WebServices, EJB, etc. Shipka requires developers to populate provider specific data object configuration only. Given that, the object providers are capable of handling any data object request, just like databases are capable of processing any SQL queries.
  • Make it easier to run unit tests. Developers can easily stub DB, remote, etc. objects using XML file.

2. Access to business logic.

  • Spring – uses the same approach to access domain objects and business logic. The consumer is injected with the object implementing business logic from the IoC container and invokes methods on it.
  • Shipka – defines the concept of operation as standalone entity of programming logic. Just like data objects are stored within object repository, Shipka organizes all operations within operation repository (OperationStore). Developers access operations by passing operationId and input parameters. They receive back the result and any output parameters. Developers may register different implementations of the same operationId for different locales. Operation expressions enable developers to combine operations together and invoke them from configuration files for purposes like – data validation, conversion, initialization, etc.

Comparison – Shipka challenges the traditional way of accessing business functionality by allowing direct access to operations. Some dynamic languages like Groovy also provide the capability to detach an operation and pass it around.

  • Eliminate the application reliance upon business interfaces.
  • Make it easier to internationalize or change the implementation of business functionality. Developers can do it one operation at a time, instead of providing new implementation of the entire interface.
  • Makes it easier to run unit tests. The code does not require interface implementations and operations can be easily stubbed at the Operation Repository.

3. Implementation of presentation functionality

  • Spring – focuses on providing flexible MVC and Portlet solutions for development of web applications. It is based on the concept of controllers, models and views. The same view may send commands to multiple controllers.
  • Shipka – focuses on building reusable presentation functionality as deployable units. Presentation components are application-independent. Deployed instances are customized and wired to the application context. Presentation components are responsible for rendering the view and processing the commands generated by the view. Developers may create components with different granularity – from single screen (or part of screen) to complete workflow. Shipka provides an architecture where every application may be deployed and integrated within other applications as single presentation component.

Comparison – Spring implementation is based on the notion that presentation functionality is specific to each application (only data and business logic are shared). Shipka on the other hand considers the presentation functionality reusable resource just like the data and business logic. Developers may reuse presentation components in multiple projects. They can also leverage presentation functionality implemented by other applications as remote presentation components. Shipka establishes single user session across all collaborating applications to enable coordination of state (like transaction context) and sharing of data objects. It advocates the sharing of large chunks of presentation functionality between applications as the biggest cost saving opportunity for companies.

4. Data Transaction implementation

  • Spring – offers programmatic and declarative transaction capabilities for local transactions as well as integration with global transactions running on the application server through JTA. Developers need to know which operations require transactions and handle them either programmatically or declaratively. Spring cannot determine the need of transaction on its own, since the data access is implemented through DAOs. Remote objects are not included in data transaction.
  • Shipka – makes data transactions completely transparent for the developers. It can figure out when transaction is necessary and start it automatically, since all data objects are manipulated through the ObjectStore interface. The determination is made using requested operation (insert, update or delete) and whether the respective object provider supports transactions. The transaction is committed if the current command completes without unchecked exception and rolled back otherwise. Shipka maintains transaction context for all object providers involved in the current command. It propagates the context to remote applications maintaining transactionable objects. For example application-1 access database information through application-2 instead of going directly to the database. The final commit or rollback operation is applied to all object providers involved in the current transaction.

Comparison – Shipka implementation has several advantages over Spring

  • Saves developers the time to design and implement transaction management and prevents them from making mistakes. With Spring, if developers forget to add transaction support for certain operation, it may go unnoticed for some time.
  • Remote objects are included in current transaction.

5. Data Object Implementation

  • Spring – recommends POJO objects that are persisted transparently using solutions like Hibernate and JPA.
  • Shipka – provides access to data objects through interfaces (there is no need of POJO objects). Shipka defines standard data object interface (including metadata) that is implemented by object providers. In object configuration file developers specify which interface they want to use for data access – custom interface, standard data object interface or combination of both (custom data interface + standard data object methods). Combined interface gives them access to features like change tracking, expression evaluation, etc. in addition to the custom data interface. Interface files are generated from the configuration files. The framework generates data object instances at runtime.

Comparison – while POJO objects are simple and easy to understand, the interface-based data access supported by Shipka has many appeals:

  • There is no need to create data interfaces or POJO by hand (time saving).
  • There is no need of DAO code to persist POJO objects through Hibernate, JPA, etc.
  • Developers get access to functionality they may need to code otherwise – like change tracking, object validation, etc.

6. Integration of third party tools

  • Spring – focuses on helping developers to integrate specific technologies like – EJB, JMS, Hibernate, TopLink and JDBC within their applications. It provides integration guidelines and sometimes value-added services. In many cases developers work directly with integrated technology like Hibernate, TopLink, etc.
  • Shipka -hides the technologies from developers. It focuses on what developers want to do (access data objects, business operation or presentation functionality) rather than what technology they want to use. Shipka defines façade interfaces for each category and relies on provider implementations for different technologies. It comes with providers for most commonly used technologies for data access, operation invocation and presentation functionality. Shipka makes it easy for third parties to create new providers and add them to respective repository (ObjectStore, OperationStore or PresentationStore). The extendibility allows developers to take advantage of the new features (for example access to LDAP) without having to learn new APIs. The only difference is that they need to create LDAP data object configuration file instead of relational database configuration file.

Comparison – Shipka supports transparent integration of third party products. Provider implementations play similar role to the JDBC drivers in JDBC. Once the driver is registered, developers can access the database through JDBC interface without knowing how the driver was created or the native DB API. By adding provider implementations the vendors enable access to their products through Shipka interfaces.

7. Data validation and conversion

  • Spring – defines special interfaces for data validators, property editor classes. Developers create custom implementations of those interfaces to validate objects or convert object values.
  • Shipka – does not need special interfaces for data validation and conversion. Data object validation is part of the object configuration. It is defined through operation expressions. Any operation (from the OperationStore) may be used within the operation expression. The only requirement is that the top level operation returns Boolean value. The configuration assigns error code to each operation expression. Validation expressions are executed automatically by the object provider during object retrieval, insert and update to ensure data integrity. If any expression returns false the object provider adds the error code to the list of errors. Data validation of request parameters is defined declaratively (in similar way) for each command of the presentation component. Validations are executed automatically prior to invoking command handling code. If errors are found the framework repaints current screen to show the error messages.

Comparison – Shipka provides declarative solution for data validation and conversion. It leverages operation expressions and the existing operations at the OperationStore. Shipka comes with comprehensive library of pre-defined operations. Developers can use their custom operations within operation expressions as well. The approach eliminates the need of custom validation and conversion classes.

8. Maturity

  • Spring – has been around for a long time and is very mature. It teaches developers how write quality code and master the traditional application development (craftsmanship).
  • Shipka – is a new entrant that brings new ideas and better ways of doing things. It approaches application development with the assumption that it is difficult and expensive to train everybody to be a craftsman. Shipka favors “configure more, code less” principle. It promotes the industrialization of software development through: reusable presentation functionality, data access without coding, shared repositories of business logic and declarative configuration of application functionality.

More information:
Spring: http://www.springsource.org
Shipka: http://shipka.com

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s