Service Component design: structure recipe comparison?
I've recently been asked to evaluate a "recipe" for Service Component design/impl provided by a group of contractors that involves model-driven design with heavy code generation, with some key components defined as below.
By "Service Component" here, I don't mean specifically SCA, but more the basic structure of a collection of java (or whatever) classes/interfaces working together to provide a service in the SOA sense.
An example "Entity Service Component" (in SOA terms) under this recipe would be composed of :
Entity Contract -- interface wrapping the parameters of an entity operation request
Entity Mediator Specification -- the interface specifying the operations available for entities
Lifecycle Contract -- interface wrapping the parameters of a lifecyle change operation request (kept separate from CRUD operations for some reason)
Lifecycle Mediator Specification -- operation(s) to transition lifecycle states
Lifecycle Validator -- validates state transitions
Domain Factory -- an interface which actually describes "Repository" or "Entity Manager" , or even DAO pattern, for CRUD operations on the fine grained domain objects (which could be composed to form an entity)
Domain Object(s) -- the persistable entities
Immutable Domain Object Interface(s) -- getters for domain object
Mutable Domain Object Interface(s) -- setters for domain object
Service Result -- describes a result provided by a given service
On the surface, these seem like reasonable (for the most part) categorizations, but some of the specific parts that worry me are:
1. Every service interface method (in the Lifecycle Mediator Specification, and Entity Mediator Specification) takes in a specific interface wrapping the method prarameters (so you'd need to instantiate a new object every time you wanted to call one of these methods, above and beyond the objects already instantiated by whatever API that was translating the individual items within the parameters, JAX-RS, JAX-WS, etc)
2. All of the components listed are generated, even in the simplest cases, such that in an implementation case involving 10 domain entities and 5 operations resulted in 300+ java classes and interfaces; the sheer amount of code is daunting, and I'm wondering what happens when there's actually some complexity in the domain/business logic itself
3. The programming model is very procedural (the domain objects are basically just a bunch of structs being passed around with getters and setters)
4. The generation doesn't seem to consider the various places where Spring could provide built-in handling/implementation for some of the modeled objects (like helping adapt your service interface to different wirings, SOAP, REST, JMS, and creating proxies for other exposed services) are included in the model classes and specifically implemented
Finally (at long last), my questions:
Are these valid concerns? Are there others I should consider?
Do you have experience with similar code generation + model-driven techniques for service components?
Have they worked well for you? What was value added? lost?
Do you know of good alternatives for simpler/leaner service component (and service interface) design that provides well-defined patterns/recipes to address the same concerns mentioned above?
Thanks.
