Hi Antonio,
Antonio Goncalves wrote:
> Hi
>
> On Wed, Jul 6, 2011 at 01:02, Marina Vatkina
> <marina.vatkina_at_oracle.com <mailto:marina.vatkina_at_oracle.com>> wrote:
>
> Dear Experts,
>
> Before we go any further on the discussions of the spec
> improvements, we need to close on several issues with the current
> version:
>
> 1. Vote on the optionality of the Entity Beans and JAX-RPC based
> Web Service Endpoints (and the split of the spec into 2 parts, but
> the split is the secondary issue). I have only 3 votes (positive)
> so far.
>
>
> You have my +1
thanks.
>
>
>
> 2. Close on the items marked by Linda as XXX in the drafts.
>
>
> I've been following the XXX marks threads and agreed on most of them
Which ones you do not agree on?
>
> 3. Define *deterministic* rules in the EJB spec about EJB Lite vs.
> EJB Full list of features in regards to the EJB support in a Web
> Profile container. In addition to be very flexible (contrary to
> the regular Java EE approach, and the expectations of the EJB
> TCK), the current wording in the spec does not make it clear a)
> what is expected and what is not in the Web Profile, and b) if we
> keep it flexible, how a user (at deployment and/or runtime) can
> determine if a specific feature outside EJB Lite is
> available/supported.
>
>
> This is a bit tricky. Let me go a bit further. Let's say (and I
> emphasis my 'let's day') PAAS/SAAS features in Java EE 7 are put into
> a seperate profile (not into EE 7 itself), this would mean that we
> would have 3 different flavours of EJBs : EJB Full, EJB Lite and EJB
> Cloud (BTW, EJB Full doesn't seam a good name to me). What are the
> differences between a EJB Full vs EJB Lite vs EJB Cloud ? How to make
> it clear to the reader and implementor what to use when ?
>
> Two posisble approaches :
>
> * we define everything (all the services) in the EJB spec and in
> the same spec have a chapter defining what services apply to EJB
> Full, EJB Lite, EJB Cloud
> * we define everything (all the services) in the EJB spec. In
> fact, we could even rename it to Enterprise Java Services
> (instead of Enterprise Java Bean). Then, in the EE spec we
> define what services are available in EE, in the Web Profil
> spec we define what services are available in the Web Profile,
> and in the Cloud Profile spec we define what services are
> available in the Cloud Profile
>
> I have a preference with the second approach
EJB spec can't change to be something completely different than what it
is today and services described in other specs can't become part of the
EJB spec 3.2 (at least for backward compatibility). What can be done, is
extract (or at least start on that path) common services and either
create separate docs or create a common Java EE services doc (under the
Platform spec or under the EJB spec - most probably the platform EG
needs to decide on that).
That said, it will still leave a question of if say, services A and B
that are not required to be supported in the EJB Lite (or Web Profile),
can a provider Z still support only A in their EJB Lite implementation?
If the answer is yes, we have a problem. Besides explaining how to
detect that, we need to describe how can it be tested that such service
behaves correctly as expected in the EJB Full set? Current CTS suite is
not available in a la carte mode, and it's not an easy task to create
one out of existing tests (where the assumption always was that you can
test either all or none).
Best,
-marina
>
> Antonio
>
>
>
>
> The same applies to the Embeddable EJB Container.
>
> Thank you,
> -marina
>
>
>
>
>
> --
> Antonio Goncalves
> Software architect and Java Champion
>
> Web site <http://www.antoniogoncalves.org> | Twitter
> <http://twitter.com/agoncal> | Blog
> <http://feeds.feedburner.com/AntonioGoncalves> | LinkedIn
> <http://www.linkedin.com/in/agoncal> | Paris JUG <http://www.parisjug.org>