Date: Tue, 16 Jul 2013 19:52:55 +0100
Hi all
I agree with the approach of moving administration object to declarative
notations. Java EE security absolutely requires rethinking. As for the EJB
vs CDI container, I think this is one for the implementors. Can EJBs be
built entirely from CDI APIs ? Probably. Then there is the question of
Cloud: I think in 2013 it is still very much immature still. It may be
worth getting some buy-in from today's Java cloud providers, who are in the
business: Heroku, CloudFoundry, JElastic, Red Hat and Cloudbees.
I would be interested in Java EE 8 discussion at JavaOne. On the other
hand, as somebody who sees Java EE 6 issues, WebSphere 7 today, JAX-RPC
incompatible development libraries with Xerces, and other stuff. We still
have a long way to go in industry. Getting to people to look at Java EE 7
is still path to be conquered.
On 16 July 2013 13:13, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
>
> On Monday, July 15, 2013, Werner Keil wrote:
>
>> Markus/all,
>>
>> Thanks for the link. There are indeed a few JSRs that either didn't make
>> it into EE 7 (like the 2 Cache-related ones) or were never intended for it
>> from a schedule perspective (though some "widely respected IT magazine
>> thought otherwise[?]) but should play a vital role under the hood and
>> between other JSRs for EE 8.
>>
>> 350, 351 (it may not have the answer to all Security questions, but tries
>> to address some, especially authentication, Single Sign-On, etc.)
>>
>>
> Thanks for pointing out JSR 351 (Identity API) which I forgot to mention
> on my blog. This has been in the works for some time, and it started to use
> CDI relatively early on. So this one is surely a good example of security
> infrastructure building on modern APIs.
>
> Ron is probably the one most suited to answer this question, but I wonder
> if the Identity API is going to be that overal "general" security framework
> in Java EE that will replace/unify things like
> HttpServetRequest#isUserInRole. I read through the available API a while
> back but couldn't yet fully wrap my head around it. I'll make sure to take
> another look soon though.
>
> If it is however not intended to be that overal general security
> framework, then having it around may actually complicate the situation
> for the end user. There will then be JAAS, JACC, JASPIC, JIAPI (Java
> Identity API) and portions of Servlet, EJB and JAX-RS all dealing with
> security. On top of that if vendors (mainly) keep emphasizing their own
> technology for authentication modules instead of JASPIC, then the end user
> has to deal with that as well. Depending on the situation this will thus be
> a maximum of 8 different technologies to deal with. In practice it's
> probably less, but it's still a lot.
>
> Kind regards,
> Arjan Tijms
>
-- Peter Pilgrim, **Java Champion**, Java EE Software Development / Design / Architect for `BlueChip' enterprises, London, UK Author of ``The Java EE 7 Developer Handbook'' to be published by Packt Pub (September 2013) JavaFX ++ Scala ++ Groovy ++ Android ++ Java :: http://www.xenonique.co.uk/blog/ :: :: http://twitter.com/peter_pilgrim :: :: http://java-champions.java.net/ :: :: Skype Call peter_pilgrim :: :: http://audio.fm/profile/peter_pilgrim ::
(image/gif attachment: 338.gif)