2.Если работаем со STRUTS и EnterpriseBean, то как бы session beans (facade) не надо делать - они лишние? Разве что только если предполагается использовать и Swing клиента?

нуна, конечно. Struts вызывает бизнес метод фасада, который работает с локальными ентити-бинами.
нуна потому-что, во-первых, для архитектуры, во-вторых, для производительности
(объяснения в книге имеются)

Хотел сказать - в литературе :)

Ну, чтоб не быть голословным - отрывок из "Mastering EJB" (полезная вещь)

Wrap Entity Beans with Session Beans

Consider the following scenarios:
■■ A bank teller component performs the business process of banking operations,
but the data used by the teller is the bank account data.
■■ An order-entry component performs the business process of submitting
new orders for products, such as submitting an order for a new computer
to be delivered to a customer. But the data generated by the order-entry
component is the order itself, which contains a number of order line-items
describing each part ordered.
■■ A stock portfolio manager component performs the business process of
updating a stock portfolio, such as buying and selling shares of stock. But
the data manipulated by the portfolio manager is the portfolio itself,
which might contain other data such as account and stock information.
In each of these scenarios, business process components are manipulating data
in some underlying data storage, such as a relational database. The business
process components map very well to session beans, and the data components
map very well to entity beans. The session beans use entity beans to represent
their data, similar to how a bank teller uses a bank account. Thus, a great EJB
design strategy is to wrap entity beans with session beans.

Another benefit of this approach is performance . Accessing an entity bean
directly over the network is expensive, due to:
■■ The stub
■■ The skeleton
■■ Marshaling/demarshaling
■■ The network call
■■ The EJB object interceptor

You can minimize these expensive calls to entity beans by wrapping them with
session beans. The session beans perform bulk create, read, update, delete
(CRUD) operations on behalf of remote clients. The session bean also serves as a
transactional façade, enforcing that transactions occur on the server, rather than
involving a remote client. This makes entity beans into an implementation detail of
session beans. The entity beans are never seen to the external client; rather, entity
beans just happen to be the way that the session bean performs persistence.


A final benefit of this approach is that your entity beans typically achieve a
high level of reuse. For instance, consider an order entry system, where you
have an order submission session bean that performs operations on an order
entity bean. In the next generation of your application, you may want an order
fulfillment session bean, an order reporting session bean, and so on. That same
order entity bean can be reused for each of these session beans. This approach
allows you to fine-tune and change your session bean business processes over
time as user requirements change.


Thus, in practice you can expect the reuse of entity beans to be high. Session
beans model a current business process, which can be tweaked and tuned with
different algorithms and approaches. Entity beans, on the other hand, define
your core business. Data such as purchase orders, customers, and bank
accounts do not change very much over time.

There are also a few of caveats about this approach:

■■ You can also wrap entity beans with other entity beans, if you have a complex
object model with relationships.
■■ The value of session beans as a network performance optimization goes
away if you do not have remote clients. This could occur, for example, if
you deploy an entire J2EE application into a single process, with servlets
and JSPs calling EJB components in-process. However, the session façade
could still be used for proper design considerations and to isolate your
deployment from any particular multitier configuration. If you’re lazy, an
alternative is to use an entity bean’s home business methods, which are
instance-independent business methods that act effectively as stateless
session bean methods, except they are located on the entity bean.
■■ Note that what we’ve presented here are merely guidelines, not hard-andfast
rules. Indeed, a session bean can contain data-related logic as well,
such as a session bean performing a bulk database read via JDBC. The key
is that session beans never embody permanent data, but merely provide
access to data.