As far as transaction control is concerned, everything depends on the application needs.
In the majority of the cases, container-managed transactions should be chosen, since the
container takes care for a lot of things instead of you. If you use bean-managed transactions,
it is supposed that the developer understands well the JTA API and can achieve his needs
without the help of the container. In some books the authors even go further stating that
only very-experienced developers should use bean-managed transactions.
However, BMT is inevitable if you want, for instance, to trigger a transaction from the
web tier. CMT is only for EJBs. So there are scenarios when the developer to use a BMT
is the only possible way.
If you want an advice, please explain me exactly what you are trying to achieve.
(c) You can achieve a persistence context that will outlive the JTA transactions by two approaches:
using EXTENDED persistence context with a stateful session bean;
using application-managed persistence context (in JavaEE environment you can obtain such a one
through a @PersistenceUnit annotation).
(d) There is no problem not to start a transaction from the client. But you will have to explain your goals if you want to be advised which approach is more suitable.
(f) The deploy of the app client is complaining that most probably you have messed up the business interface types. Check them once again.
(If your app client lives in a separate JVM, then you must use remote interfaces only)
Take a look at this: http://stackoverflow.com/questions/848675/ejb-annotation-in-clients
Are you sure that you have declared correctly your client code as a valid application client ? (maybe this is done through some deployment descriptors, i don't know ) If the container does not recognize it as an app client, then dependency injection is forbidden and you must use look up instead.
Why don't you try to look up the remote interface in the client anyways, instead of having it injected ?
Something to add about the IDENTITY strategy:
Another difference, hinted at earlier, between using IDENTITY and other id generation
strategies is that the identifier will not be accessible until after the insert has occurred. While no
guarantee is made as to the accessibility of the identifier before the transaction has completed,
it is at least possible for other types of generation to eagerly allocate the identifier, but when
using identity, it is the action of inserting that causes the identifier to be generated. It would be
impossible for the identifier to be available before the entity is inserted into the database, and
because insertion of entities is most often deferred until commit time, the identifier would not
be available until after the transaction has been committed.
This is from "Pro EJB 3: Java Persistence API" book.