Monday, August 26, 2013

reviewing liferfay service builder for minuteproject integration

This article carries a study on Liferay service builder tooling and check the matching in minuteproject ecosystem.

The input from this article comes from:

Service builder principles

Service builder relies on forward engineering and a descriptive format of the model that complies with a dtd. So the user needs to create a valid xml file called service.xml.
Service xml main nodes are 'entity' node.
Entity node describe a persistence entity (i.e. table) for a RDBMS.
The entity description covers columns and relationships (parents and children via collection) as well as primary key strategy.
This file serves as input to an ant task that carries on the generation process. Some 20 different artifacts are generated. All of those artifacts are service-builder 'entity' node centric.

Service builder from a generation perspective


Is a approach domain centric as some advantages:
  • density of the information (a simple file to describe)

Service builder from minuteproject perspective

Minuteproject is evolving from smart reverse-engineering to a development methodology platform focusing on 4 Weapons of Mass Productivity:
  • smart reverse-engineering
  • virtualization
  • statement driven development (SDD)
  • transient definition

Service builder / Minuteproject matching

Although the philosophies (forward-engineering vs. reverse-engineering) are different there is a mapping between the both approach.

The question is are all the information in service builder available by minuteproject reverse-engineering?


Let's have a element review of service builder nodes

Service builder 

ATTLIST service-builder
    package-path CDATA #REQUIRED
    auto-namespace-tables CDATA #IMPLIED
<!ELEMENT author (#PCDATA)>
<!ELEMENT namespace (#PCDATA)

package-path, author, namespace can be deduced by minuteproject model node


ATTLIST entity
    human-name CDATA #IMPLIED
    table CDATA #IMPLIED
    uuid-accessor CDATA #IMPLIED
    local-service CDATA #IMPLIED
    remote-service CDATA #IMPLIED
    persistence-class CDATA #IMPLIED
    data-source CDATA #IMPLIED
    session-factory CDATA #IMPLIED
    tx-manager CDATA #IMPLIED
    cache-enabled CDATA #IMPLIED
    json-enabled CDATA #IMPLIED

Entity name can be deduced from table name (or view name)
Human name can be deduce by table alias name
All the other boolean field can be deduce by so convention or some parameters to set on the mp4liferay track
Datasource can be deduced by convention (related to the namespace) (and also generated by MP)


<!ATTLIST column
    db-name CDATA #IMPLIED
    primary CDATA #IMPLIED
    accessor CDATA #IMPLIED
    filter-primary CDATA #IMPLIED
    entity CDATA #IMPLIED
    mapping-key CDATA #IMPLIED
    mapping-table CDATA #IMPLIED
    id-type CDATA #IMPLIED
    id-param CDATA #IMPLIED
    convert-null CDATA #IMPLIED
    localized CDATA #IMPLIED
    json-enabled CDATA #IMPLIED
Column info can be found by reverse-engineering name (via alias), db-name, type, primary, entity, mapping-key, mapping-table.
Id-type and id-param can be deduced from the PK strategy associated to the database type.
MP covers those described in service.xml (uuid, sequence, autoincrement, identity)

Finder and finder-column
can be deduce from defaulting (pk, fk) or with the semantic reference of the table.

References correspond to DB relationships.

Review conclusion

This means that the main information can be deduced from the smart reverse-engineering.
What is missing can be added by convention a liferay configuration for defaulting (such as companyId, groupId, finder extra info) and parametrization of the liferay track.
In all the case the configuration of service.xml (generated by MP) can be manually changed and at the next generation from the DB your alterations are kept!! Thank to updatable code feature of MP.

Can minuteproject even extend service-builder facility?



This is the strong point of reverse-engineering: you can work with Views. In forward-engineering it is impossible since you cannot guess the implementation whereas in reverse-engineering, you take it as is!
So your view can be set as entity in service.xml (with readonly access)
But what is the identity field of this view. Minuteproject enrichment or convention enable to grant one to a field acting as a unique key.
Even better, minuteproject provides you the ability to grant relationships between view like parent-child foreign key and this can also be used in service.xml


Example: detect relationship between entity when no foreign key present.

Can minuteproject do more for service builder?


Validation - mandatory and type are not enough

You should have stereotype such as email, url, password. A stereotype is an abstraction between presentation and validation aspects.


Limit the column value to a enumeration.

Updatable code

The code you generate can be updated via some extension points. The next time you generate your modification are kept!


Minuteproject can generate the datasource code

Semantic reference

Sometimes you do not want to display the entire entity fields but just the more important. This is the semantic reference.

Work with Statement only

Sometimes you can go back to the fundamentals of your UCs (I/O + function).
Ex a jdbc call to a stored procedure.

DTO oriented service

The input is not mapped to a persistence entity.


After this feasability review, minuteproject can have the capabilities to generate service.xml of liferay from the DB. But also to extend it.
A sample generation is foreseen for MP release 0.8.5.

The first approach is to generate the SB input configuration. But nearly all generated artifacts SB generate can also be generated by MP.