Which EJB patterns are motivated by minimizing network calls?
Hi, I'm reading a book on EJB patterns, and the motivation for many patterns seem to be minimizing network calls. If my application server and web server which serves as the EJB client are on the same machine, then to what extent should I consider the minimization of network calls as a factor in deciding whether to use that pattern?
Of course, a big factor would be to the extent that you're likely to move to a distributed architecture in the future, and want to build towards that from the start.
But let's say hypothetically you'll be on a non-distributed architecture forever. Which patterns would become far less useful in this case that with the possibility of a distributed architecture?
My basic question is, then, while all patterns that have minimization of network calls as an advantage have other advantages to them as well (ranging from transaction demarcation to cleanliness of code to maintainability and more), which EJB patterns are motivated in very large part by a distributed architecture?
i.e. Which patterns, if you hypothetically knew you'd remain in a non-distributed architecture forever, would you have a large chance of never using. Please don't attack my assumption of non-distributed forever...I've specified that it's purely hypothetical.
Thanks, your insights are appreciated.
> Hi, I'm reading a book on EJB patterns, and the
> motivation for many patterns seem to be minimizing
> network calls. If my application server and web
> server which serves as the EJB client are on the same
> machine, then to what extent should I consider the
> minimization of network calls as a factor in deciding
> whether to use that pattern?
>
> Of course, a big factor would be to the extent that
> you're likely to move to a distributed architecture
> in the future, and want to build towards that from
> the start.
>
> But let's say hypothetically you'll be on a
> non-distributed architecture forever. Which patterns
> would become far less useful in this case that with
> the possibility of a distributed architecture?
>
> My basic question is, then, while all patterns that
> have minimization of network calls as an advantage
> have other advantages to them as well (ranging from
> transaction demarcation to cleanliness of code to
> maintainability and more), which EJB patterns are
> motivated in very large part by a distributed
> architecture?
>
> i.e. Which patterns, if you hypothetically knew you'd
> remain in a non-distributed architecture forever,
> would you have a large chance of never using. Please
> don't attack my assumption of non-distributed
> forever...I've specified that it's purely
> hypothetical.
If you are using a J2EE container to design an application that will only ever run on a single box then your architecture is wrong. So it doesn't matter what patterns you use or don't use.
Other than that on box calls are cheaper (most of the time) than off box calls. But they are still more expensive than direct calls.
And naturally if you know that a pattern exists solely to minimize network calls and you know that you won't be using a network then, at least for me, the conclusion as to whether one should use or not use the pattern would be obvious.
> And naturally if you know that a pattern exists
> solely to minimize network calls and you know that
> you won't be using a network then, at least for me,
> the conclusion as to whether one should use or not
> use the pattern would be obvious.
I don't know which patterns exist solely to minimize network calls. And, in fact, that is not even my question.
My question is as follows: Which patterns exist, in large part, to minimize network calls?
Anybody who could help me out on this, please do.
> My question is as follows: Which patterns exist, in
> large part, to minimize network calls?
As you stated, you are reading a book about EJB patterns and you said you read about a common motivation to be minimizing network calls.
To help answer your question, the patterns are identified in the book you are reading and if you read about them then you will find the ones that exist in large part to minimizing network calls.
It is ok to use a J2EE EJB container or J2EE Web container to create a small application that will one run one a single node.
