I’m quite new to the EMF concept and have recently worked through the book on model-driven software engineering. Now, I’m eager to implement what I’ve learned in a real project.
I’ve developed a metamodel and incorporated some OCL constraints, essentially forming a semantic schema for my database.
I have a couple of questions:
How should I implement the business logic? Is it feasible to rely solely on OCL constraints and model transformations for this? I think using Henshin exclusively might be overkill.
How can I utilize my model as a backend? I want clients to access certain sections of my model via RESTful services. What are the possible approaches for achieving this?
For business logic, I’ve had great success mixing OCL with generated code. OCL’s perfect for declarative constraints, but you’ll need imperative code for procedural business rules. Generate your base classes from the metamodel, then extend them with custom business methods. You get to keep your model-driven foundation but still have flexibility for complex stuff. For the REST backend issue, try EMF’s native XMI serialization with custom JSON converters. I built something similar using JAX-RS with custom message body writers that transform EMF objects straight to JSON. The big win here is you maintain type safety from your metamodel all the way to the API layer. For database persistence, EMF’s resource framework handles this nicely - it abstracts away storage headaches while keeping your business logic clean and focused on the domain model.
business logic gets messy fast with pure OCL. mix it up - OCL handles validation rules nicely, but use Java/Xtend for anything complex. trust me on this one! for the REST backend, EMF.cloud works well, or just go with basic Jackson serialization. keep it simple at first.
Nice approach! Have you tried ATL or QVT for transformations instead of Henshin? Also, what domain are you modeling? That’ll determine how complex this gets. And for REST APIs - any reason you’re not using GraphQL?
Transitioning from EMF theory to practical application can indeed present challenges. While OCL constraints serve well for validation, more intricate business logic may require additional layers beyond simple transformations. I recommend generating the fundamental code with EMF and supplementing it with custom implementations to maintain the advantages of your metamodel. For backend implementation, using Eclipse EMF in conjunction with frameworks like Jersey or Spring Boot has proven effective. You can generate your model classes from the metamodel, allowing you to establish REST endpoints that convert EMF objects into JSON format seamlessly. EMF’s built-in serialization simplifies this process significantly. For database integration, consider tools like CDO or Teneo to facilitate connections between your EMF models and relational databases, ensuring clean REST APIs while preserving the benefits of your model-driven architecture.