On Tue, Oct 30, 2012 at 12:33 AM, Jiri Jetmar <[email protected]> wrote:
> Thank you for your advice. Not sure what you mean with "cut" away -
What I meant was; You sent a mail that you get a StackOverflow. I
looked at the code and went; "Well, where is everything?". I don't
have it in front of me, so I can't recall the details... Maybe
tomorrow morning I can comment better.
> I also agree with your proposal of the assembly structure with some small/open
> questions like should be the Context Objects also composites ? There
> are a number
> of benefits to do so (injections of structures/uof), but also there
> are some disadvange like e.g.
> performance issues.
Well, if you choose to use objects for some things, that is fine, BUT
you can not expect that any of the Qi4j artifacts will then work.
Since Qi4j owns the call stack for Composites and "Qi4j Objects",
there are a lot of things that are tied together under the covers.
To give you an understanding, let's try an example;
public class MyMixin implements My {
public void doSomething() {
:
}
public void doAnother() {
this.doSomething();
}
}
Now, IF doSomething() is a Composite Type method, then all the
Concerns and Constraints of that method will be invoked, even when the
method call is happening from within the same Java object instance.
Another example;
Let's say that you have an Application Layer and a Domain Layer. In
the Domain Layer you have a module private Entity (My1) and a
application visible Entity (My2).
Now, the Application Layer creates the UnitOfWork, but the Application
Layer doesn't have visibility to My1. So, what happens under the
covers is that; As the methods are invoked and Visibility scope
changes, the UnitOfWork is changing with it, without loosing track of
Visibility scope.
These are example of how involved Qi4j Runtime is in the invocation of
methods on Qi4j artifacts. All parts of the Runtime expects certain
behavior, and creating a UnitOfWork from a stored away
UnitOfWorkFactory is illegal and don't call us when you loose the data
or application doesn't work.
Perhaps we need to spend time documenting the "border" between regular
Java and Qi4j in more precise manner.
> As I understood from the performance test the
> overhead using
> composites versus "naked" objects is about 50:1. But sure, if I can
> benefit from clear
> structures in the code, clear object ownership etc. I;m ready to add
> additional boxed
> to compensate the performance "penalties" using composites everywhere
> (if there are
> really performance issues, what is not clear yet).
Which performance test?
> I;m also thinking on a kind of vertical layering as we have more
> Application here like :
>
> Accounting
> Billing
> ProductManagement
There are many ways to structure that;
* Separate JVMs
* Separate Qi4j Runtime instances in the same JVM
* Separate Layer "columns" in a single Qi4j Runtime.
* Different modules in Domain layer.
Once you analyze correlated applications, you often find that they are
much more complicated than "simple silos", and layers above the domain
layer will in fact be modeled differently than such silos.
> And I would like to "assembly" them togerher (in terms of a Qi4j
> Application) during development
> but later in production they would be seperated - each in his own
> node, therefore separed (J)VMs
> and "synchronized" using the even-sourcing pattern.
That is one possibility. But don't shard the application because you
think you need to run them on different hosts due to performance. That
sounds like a bad architectural choice. I have not studied this domain
well to give useful architecture choices, but I tend to use network
queues (e.g. ZeroMQ) a lot and have all nodes in the cluster
identical.
Cheers
--
Niclas Hedhman, Software Developer
河南南路555弄15号1901室。
http://www.qi4j.org - New Energy for Java
I live here; http://tinyurl.com/3xugrbk
I work here; http://tinyurl.com/6a2pl4j
I relax here; http://tinyurl.com/2cgsug
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev