Skip to content
logoBack to home screen

tribefire 2.0 - 27/09/2018

With Tribefire 2.0 release, two big paradigm shifts took place.

In 1.1, there was a strong focus on persistence, with accesses providing fully fledged integration of third-party data sources. Although accesses are still around, we recommend a much more lightweight way of integrating data sources via DDSA-based services, allowing quick, normalized implementations not only for integration purposes, but for any computing functionality.

Another important addition to Tribefire 2.0 are the Platform Assets, taking the everything-is-a-model approach one step further, and acting as reusable building blocks for tribefire runtimes.

See the rest of this document for an overview of the highlights.

On this page

  1. DDSA
  2. Wire IOC
  3. REST 2.0
  4. Swagger Integration
  5. tribefire.js
  6. Improved Metamodel
  7. Platform Assets
  8. Jinni CLI
  9. Docker and Cloud
  10. Health Checks
  11. About Page
  12. Collaborative SMOOD Access
  13. Model Element Overrides
  14. Metadata Editor
  15. Cartridges
  16. Training
  17. Migration
    1. Known Issues
    2. Maintenance Release Oct 24th 2018
      1. Known Issues
    3. Maintenance Release Dec 15th 2018
      1. Changes

DDSA

DDSA stands for Denotation-driven Service Architecture. Via DDSA, you can implement and (re-)use modeled services, bound to the executing expert at calltime. You can also send, retrieve, and process structured and unstructured data. Services allow to apply aspects to realize cross cutting concerns, thus providing context sensitive dynamic behavior. They are described and triggered by polymorphic, evaluable entity types, and therefore provide Function-as-a-Service (FaaS) in a consistent, normalized way.

Wire IOC

Wire is Braintribe's tool for inversion of control (IOC). Built on a very small footprint, it uses Java as a flexible and direct way of coding dependency injection. Therefore, it allows a level of complexity enabling the use of loops and if-conditions using normal Java code.

REST 2.0

With the REST API 2.0 we introduced three new REST endpoints. Two endpoints provide out-of-the-box CRUD calls for Entities and Properties and a third one a service API for DDSA-based services. All endpoints are provided in a standard-conform way, so Tribefire-specific knowledge is not required anymore for UI developers.

Swagger Integration

Based on the new REST API, Tribefire now comes with automatically created Swagger-UIs for each Access or service domain, which can directly be accessed from the Tribefire Landing page. Furthermore, we now support now the automated model creation based on a given Swagger file or URL.

tribefire.js

With tribefire.js, Tribefire provides a library allowing you to use tribefire functionality through JavaScript in a native way. Using tribefire.js, you can easily implement HTML5 applications with active tribefire objects, and consume the tribefire core Java API.

Improved Metamodel

With Tribefire 2.0, we introduce a new Metamodel, which improves the model re-use by declaring dependencies to other models, instead of merging them. This provides a separation of concerns, providing more flexibility and better version handling.

Platform Assets

Platform Assets are the building blocks for your Tribefire runtime instance. They allow the provision and assembly of tribefire models, functionality, configuration, documentation, and more. With Platform Assets, you wire all required elements for a Tribefire runtime installation by declared dependencies among them. This way, they allow you to set up Tribefire in an incremental and reproducible way for different target environments.

Jinni CLI

Tribefire now comes with a new command line tool Jinni, providing a convenient way to create Tribefire setups based on Platform Assets.

Docker and Cloud

Tribefire deployment has been simplified and standardized, and is now based on Docker and Kubernetes. This is now the recommended way to deploy and run Tribefire, both on-premise and in the cloud. Docker images are built using Jinni.

Health Checks

The newly introduced health checks are an important system operation tool. They provide service calls, performing sanity checks for Tribefire itself, as well as the attached cartridges. Cartridge developers can implement this service type to perform any specific call providing specific sanity information.

About Page

In addition to the health-checks, Tribefire now comes with an About page, providing system information about a Tribefire runtime environment (single instance or a cluster). It shows all running processes and those threads that consume the most processing power. It also provides the creation and download of diagnostic reports.

Collaborative SMOOD Access

With the Collaborative SMOOD Access, we created an additional method for our in-memory SMOOD database to persist its data. Instead of writing an XML file representing the whole data assembly, the Collaborative SMOOD Access persists data in an incremental way by writing manipulation instructions in the newly introduced GMML (Generic Model Manipulation Language). The Access works with stages, which can be added, combined, removed, and exchanged, thus providing reproducibility and re-use, which is the basis for the Platform Assets approach. It is also provided as a distributed Access, designed for a clustered environment.

Model Element Overrides

With Metadata, you can adapt the behavior of a model that's specific to certain use cases. To keep your models generic and reusable, Tribefire 2.0 comes with Overrides for entity types, enum types, properties and enum constants. Overrides allow to configure Metadata only for specific (depending) Models without changing the original, thus assuring their reusability.

Metadata Editor

The Metadata Editor is an expressive UI component for the Tribefire Control Center designed for Metadata configuration. It provides a list view of types and properties and their Metadata configuration. Furthermore, it supports the Overrides feature, so that Overrides are created automatically for the case the configured element comes from, from a model dependency.

Cartridges

The implementation of custom functionality via Cartridges was rebuilt fundamentally. Architectural changes increase stability and performance, while optimizing the communication between Cartridges and tribefire-services. Spring IOC was replaced by the light-weight Wire IOC library. Developers can implement DDSA-based services and introduce their own custom extension points. Instead of synchronizing with tribefire-services, the Cartridge is now initialized and optionally set up via Platform Asset.

Training

We understand how important it is to ramp up your knowledge quickly. This is why tribefire 2.0 has a dedicated self-service training portal where you can find all the resources you need to start working with tribefire. The trainings are aimed at everyone, be it someone who is just starting their journey with tribefire or seasoned front- or back-end developers who know the basics and want to see the latest tribefire features in action. Apart from the self-service portal, we provide comprehensive documentation and JavaDocs to further assist your learning.

Migration

If you want to reuse your 1.1 cartridges in tribefire 2.0, you must migrate them to platform assets.

Known Issues

  • REST calls expect a long value when you pass an id as part of the URL path. If you use a custom collaborative SMOOD access, for example in simulation mode, the id will be of type String. To notify the REST endpoint to expect a String, add the TypeSpecification metadata with the value string to the id property of the GenericEntity type in your model.
  • The property externalId of Accesses has the metadata unique, which prevents the setting of identical IDs on Accesses. Currently, this applies only for the same type of Accesses but not for different ones. E.g. potentially there could be a Hibernate Accesses and a SMOOD Access with the same external ID, which causes problems when querying. Please make sure, to use different values for the external ID.
  • If you create a custom DDRA mapping in Control Center some of the default values might not be reflected in the Swagger UI. This does not affect the actual REST endpoint. -fixed with maintenance release Oct 24th 2018
  • The Metadata Editor sometimes displays properties or types twice or not at all. Via refresh-button the list is displayed normally again. -fixed with maintenance release Oct 24th 2018
  • If MS SQL database schemas are not specified as default schema ("dbo") the database synchronization fails.
  • The @Initializer annotation, which allows to specify an initial property value for the instantiation, won't be inherited to sub-types. If this behavior is required on a specific sub-type within the type hierarchy it has to be declared on that type.
  • Currently, the RegistryBoundConnectionPool cannot be deployed. All other connection pools work as expected.
  • If the environment variable TRIBEFIRE_MANIPULATION_PRIMING is defined in the file tribefire.properties it won't be recognized. If the environment variables are set via database (e.g. in cloud-scenarios) the variable TRIBEFIRE_MANIPULATION_PRIMING is read in normally.
  • If you are using Maven and Eclipse, then (dependent on your setup and Maven repository settings) the Maven Eclipse plugin may show two errors saying that the libraries com.sencha.gxt:gxt:4.0.2 and com.xedge:gwt-jquery:2.0 are missing. These libraries are not needed for the Maven build though. On the command line Maven should just show warnings. Please just ignore these messages for now.
  • The Tribefire Demo Cartridge hasn't been 100% migrated to Platform Assets yet. For example, the workbench still has some issues.

Maintenance Release Oct 24th 2018

Known Issues

  • Known issues above not marked with Fixed with maintenance release Oct 24th 2018.
  • The Simple Properties panel in the graphical Modeler shows a checkbox for marking a type as abstract on Enum Types. Clicking this checkbox throws an error.
  • In the Process Designer, the indicator for selection or connection mode does not always display the right mode.
  • In Modeler, the overlays for creating relations sometimes disappear.
  • When deployment of an asset from Control Center fails, no error message is displayed.
  • The standalone Modeler displays collections of simple properties as both simple properties and relations.
  • The action bar in Control Center is too wide.

Maintenance Release Dec 15th 2018

Changes

  • MIME type and MD5 can now be transported during resource upload
  • Merge and Transfer and Close and Transfer asset transfer operations in GME now have the default value deploy
  • LDAP cartridge is now an asset
  • Password encryption support in LDAP initializer
  • Deployables and Resource POST calls error message improvements
  • Multiple JDBC driver version support in JDBC plugins