You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by "Trenton D. Adams" <tr...@gmail.com> on 2016/05/29 18:57:58 UTC
EJB vs REST
Good day,
I've had discussions with people that think JAX-RS should be used as a
replacement for technologies like EJB, for making n-tier solutions. Some
of my main concerns about that would be...
- JAX-RS is mainly a structured approach to solving the problem, and does
not use OOD very well.
- Having stateless remote calls is fine for certain types of data, but I've
found stateful technologies remove a lot of boilerplate stuff. Combined
with good OOD, the savings are even better. JAX-RS is intended to be
stateless, so you'd be required to pass all of the state information on
each call. That requires a lot more thought, planning, and I think it's
more prone to development errors, etc.
I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB is
better for enterprise software, I'd like to be able to articulate it. Or,
perhaps JAX-RS is best, and I'd like to be able to articulate that.
What sorts of other criteria would you use, in choosing a solution?
Thanks.
Re: EJB vs REST
Posted by Romain Manni-Bucau <rm...@gmail.com>.
CXF supports session state:
https://github.com/apache/cxf/blob/ac9b9b1898bbe0cc911b34cc3d32664ac59fdc34/systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/oauth2/grants/AuthorizationGrantTest.java#L57
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-05-30 10:02 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> That is very interesting. Apparently Jersey has a proxy client API as
> well.
>
> There has to be some sort of state, even if it's as simple as maintaining
> that your user is authenticated. With this proxy client api, is it
> possible to have cookies automatically kept, and sent during each request?
>
> On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com>
> wrote:
>
> > 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> >
> > > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
> > rmannibucau@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hello
> > > >
> > > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <
> trenton.d.adams@gmail.com
> > >:
> > > >
> > > > > Good day,
> > > > >
> > > > > I've had discussions with people that think JAX-RS should be used
> as
> > a
> > > > > replacement for technologies like EJB, for making n-tier solutions.
> > > Some
> > > > > of my main concerns about that would be...
> > > > >
> > > > > - JAX-RS is mainly a structured approach to solving the problem,
> and
> > > does
> > > > > not use OOD very well.
> > > > >
> > > >
> > > > Assuming you don't mix local EJB and JAX-RS which are very different
> > and
> > > > that EJB means there remote EJB.
> > > >
> > > > Since it does serialize the payload it is 1-1 with EJB(d), you have
> > more
> > > or
> > > > less the exact same constraints there. Then you can use different
> > format
> > > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd
> too,
> > > and
> > > > more advanced formats too)
> > > >
> > >
> > > Yeah, I'm referring to remotable EJBs.
> > >
> > >
> > > >
> > > >
> > > > > - Having stateless remote calls is fine for certain types of data,
> > but
> > > > I've
> > > > > found stateful technologies remove a lot of boilerplate stuff.
> > > Combined
> > > > > with good OOD, the savings are even better. JAX-RS is intended to
> be
> > > > > stateless, so you'd be required to pass all of the state
> information
> > on
> > > > > each call. That requires a lot more thought, planning, and I think
> > > it's
> > > > > more prone to development errors, etc.
> > > > >
> > > >
> > > > Nothing prevents you to have a stateful JAX-RS endpoint, you just
> need
> > to
> > > > ensure your client maintains the session properly.
> > > >
> > >
> > > Yes, I know nothing prevents you, but the whole point of REST, is to
> be
> > > stateless, is it not?
> > >
> > >
> > >
> > Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet layer.
> > Then you do what you want. Stateless architectures are super nice for a
> lot
> > of reasons
> > but it is not bound to JAX-RS or EJB where the recommanded practise can
> be
> > to be stateless as well.
> >
> >
> > >
> > > >
> > > > >
> > > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if
> > EJB
> > > is
> > > > > better for enterprise software, I'd like to be able to articulate
> it.
> > > > Or,
> > > > > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> > > > >
> > > > >
> > > > Technically both (remote EJB and JAX-RS) are globally the same in
> term
> > of
> > > > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger
> and
> > > > more standard (you will find clients for all languages in 5mn, not
> for
> > > > EJBd).
> > > >
> > >
> > > I'm curious, how do you see EJB and JAX-RS as being the same
> > architecture?
> > > EJB has the capability of maintaining state, and obfuscates the remote
> > call
> > > entirely, while JAX-RS does not. As far as I've ever seen, it's up to
> > you
> > > to develop the boilerplate code to make the call, even when you're
> using
> > > JAX-RS 2 with the client api. I mean you could use something like
> > retrofit
> > > to make it sort of like EJB.
> > >
> > >
> >
> > Use CXF client factory then you will create a proxy from your JAX-RS
> > contract => you hide the JAX-RS calls behind an interface. It makes it
> more
> > or less the same as EJB excepted you replaced EJBException by
> > WebApplicationException:
> >
> >
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> >
>
Re: EJB vs REST
Posted by Romain Manni-Bucau <rm...@gmail.com>.
It doesn't and is not related actually if you expose ejbd endpoints/any not
configured RMI endpoint. Point was more RMI will imply a verbose
configuration you will likely not like or want to maintain (whitelist) vs
JAX-RS.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-05-30 18:36 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> Wouldn't SELinux take care of the serialization exploit? I mean exploits
> come along all the time, which is why SELinux should be in use; assuming
> the use of Linux.
>
> On Mon, May 30, 2016 at 2:47 AM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > you can also see the 0-day vulnerability as another step requiring
> > configuration with RMI and not with JAX-RS/JSON default usage. Also
> another
> > thing to justify if you get an audit ;)
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <http://rmannibucau.wordpress.com> | Github <
> > https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> > <http://www.tomitribe.com> | JavaEE Factory
> > <https://javaeefactory-rmannibucau.rhcloud.com>
> >
> > 2016-05-30 10:14 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> >
> > > Also, another aspect to all of this, is that we have a moderately sized
> > > application, which uses RMI for the business logic. Converting that to
> > > @Stateful EJB, would be a breeze, and we could really be confident it
> > would
> > > continue working once we've gone through our testing cycle. I'm
> guessing
> > > that converting it to JAX-RS, could be very painful, error prone, and
> > > consume a lot of develop, test, fix, test, fix, test, fix, before we
> > could
> > > even go live. Essentially, @Stateful EJB can literally have no code
> > > changes to the RMI code, except annotations, and it would work almost
> > > identically, except the authentication part of it.
> > >
> > > Also, OpenEJB certainly adds some nice multicast distributed server
> > > capabilities.
> > >
> > > On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams <
> > > trenton.d.adams@gmail.com
> > > > wrote:
> > >
> > > > That is very interesting. Apparently Jersey has a proxy client API
> as
> > > > well.
> > > >
> > > > There has to be some sort of state, even if it's as simple as
> > maintaining
> > > > that your user is authenticated. With this proxy client api, is it
> > > > possible to have cookies automatically kept, and sent during each
> > > request?
> > > >
> > > > On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <
> > > > rmannibucau@gmail.com> wrote:
> > > >
> > > >> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <
> trenton.d.adams@gmail.com
> > >:
> > > >>
> > > >> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
> > > >> rmannibucau@gmail.com
> > > >> > >
> > > >> > wrote:
> > > >> >
> > > >> > > Hello
> > > >> > >
> > > >> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <
> > > >> trenton.d.adams@gmail.com>:
> > > >> > >
> > > >> > > > Good day,
> > > >> > > >
> > > >> > > > I've had discussions with people that think JAX-RS should be
> > used
> > > >> as a
> > > >> > > > replacement for technologies like EJB, for making n-tier
> > > solutions.
> > > >> > Some
> > > >> > > > of my main concerns about that would be...
> > > >> > > >
> > > >> > > > - JAX-RS is mainly a structured approach to solving the
> problem,
> > > and
> > > >> > does
> > > >> > > > not use OOD very well.
> > > >> > > >
> > > >> > >
> > > >> > > Assuming you don't mix local EJB and JAX-RS which are very
> > different
> > > >> and
> > > >> > > that EJB means there remote EJB.
> > > >> > >
> > > >> > > Since it does serialize the payload it is 1-1 with EJB(d), you
> > have
> > > >> more
> > > >> > or
> > > >> > > less the exact same constraints there. Then you can use
> different
> > > >> format
> > > >> > > over JAX-RS (JSON/XML obviously, but java serialization like
> EJBd
> > > too,
> > > >> > and
> > > >> > > more advanced formats too)
> > > >> > >
> > > >> >
> > > >> > Yeah, I'm referring to remotable EJBs.
> > > >> >
> > > >> >
> > > >> > >
> > > >> > >
> > > >> > > > - Having stateless remote calls is fine for certain types of
> > data,
> > > >> but
> > > >> > > I've
> > > >> > > > found stateful technologies remove a lot of boilerplate stuff.
> > > >> > Combined
> > > >> > > > with good OOD, the savings are even better. JAX-RS is
> intended
> > to
> > > >> be
> > > >> > > > stateless, so you'd be required to pass all of the state
> > > >> information on
> > > >> > > > each call. That requires a lot more thought, planning, and I
> > > think
> > > >> > it's
> > > >> > > > more prone to development errors, etc.
> > > >> > > >
> > > >> > >
> > > >> > > Nothing prevents you to have a stateful JAX-RS endpoint, you
> just
> > > >> need to
> > > >> > > ensure your client maintains the session properly.
> > > >> > >
> > > >> >
> > > >> > Yes, I know nothing prevents you, but the whole point of REST, is
> > to
> > > be
> > > >> > stateless, is it not?
> > > >> >
> > > >> >
> > > >> >
> > > >> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet
> > > layer.
> > > >> Then you do what you want. Stateless architectures are super nice
> for
> > a
> > > >> lot
> > > >> of reasons
> > > >> but it is not bound to JAX-RS or EJB where the recommanded practise
> > can
> > > be
> > > >> to be stateless as well.
> > > >>
> > > >>
> > > >> >
> > > >> > >
> > > >> > > >
> > > >> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc.
> But,
> > if
> > > >> EJB
> > > >> > is
> > > >> > > > better for enterprise software, I'd like to be able to
> > articulate
> > > >> it.
> > > >> > > Or,
> > > >> > > > perhaps JAX-RS is best, and I'd like to be able to articulate
> > > that.
> > > >> > > >
> > > >> > > >
> > > >> > > Technically both (remote EJB and JAX-RS) are globally the same
> in
> > > >> term of
> > > >> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really
> > bigger
> > > >> and
> > > >> > > more standard (you will find clients for all languages in 5mn,
> not
> > > for
> > > >> > > EJBd).
> > > >> > >
> > > >> >
> > > >> > I'm curious, how do you see EJB and JAX-RS as being the same
> > > >> architecture?
> > > >> > EJB has the capability of maintaining state, and obfuscates the
> > remote
> > > >> call
> > > >> > entirely, while JAX-RS does not. As far as I've ever seen, it's
> up
> > to
> > > >> you
> > > >> > to develop the boilerplate code to make the call, even when you're
> > > using
> > > >> > JAX-RS 2 with the client api. I mean you could use something like
> > > >> retrofit
> > > >> > to make it sort of like EJB.
> > > >> >
> > > >> >
> > > >>
> > > >> Use CXF client factory then you will create a proxy from your JAX-RS
> > > >> contract => you hide the JAX-RS calls behind an interface. It makes
> it
> > > >> more
> > > >> or less the same as EJB excepted you replaced EJBException by
> > > >> WebApplicationException:
> > > >>
> > > >>
> > >
> >
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> > > >>
> > > >
> > > >
> > >
> >
>
Re: EJB vs REST
Posted by "Trenton D. Adams" <tr...@gmail.com>.
Wouldn't SELinux take care of the serialization exploit? I mean exploits
come along all the time, which is why SELinux should be in use; assuming
the use of Linux.
On Mon, May 30, 2016 at 2:47 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> you can also see the 0-day vulnerability as another step requiring
> configuration with RMI and not with JAX-RS/JSON default usage. Also another
> thing to justify if you get an audit ;)
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
> <http://www.tomitribe.com> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2016-05-30 10:14 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
>
> > Also, another aspect to all of this, is that we have a moderately sized
> > application, which uses RMI for the business logic. Converting that to
> > @Stateful EJB, would be a breeze, and we could really be confident it
> would
> > continue working once we've gone through our testing cycle. I'm guessing
> > that converting it to JAX-RS, could be very painful, error prone, and
> > consume a lot of develop, test, fix, test, fix, test, fix, before we
> could
> > even go live. Essentially, @Stateful EJB can literally have no code
> > changes to the RMI code, except annotations, and it would work almost
> > identically, except the authentication part of it.
> >
> > Also, OpenEJB certainly adds some nice multicast distributed server
> > capabilities.
> >
> > On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams <
> > trenton.d.adams@gmail.com
> > > wrote:
> >
> > > That is very interesting. Apparently Jersey has a proxy client API as
> > > well.
> > >
> > > There has to be some sort of state, even if it's as simple as
> maintaining
> > > that your user is authenticated. With this proxy client api, is it
> > > possible to have cookies automatically kept, and sent during each
> > request?
> > >
> > > On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <
> > > rmannibucau@gmail.com> wrote:
> > >
> > >> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <trenton.d.adams@gmail.com
> >:
> > >>
> > >> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
> > >> rmannibucau@gmail.com
> > >> > >
> > >> > wrote:
> > >> >
> > >> > > Hello
> > >> > >
> > >> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <
> > >> trenton.d.adams@gmail.com>:
> > >> > >
> > >> > > > Good day,
> > >> > > >
> > >> > > > I've had discussions with people that think JAX-RS should be
> used
> > >> as a
> > >> > > > replacement for technologies like EJB, for making n-tier
> > solutions.
> > >> > Some
> > >> > > > of my main concerns about that would be...
> > >> > > >
> > >> > > > - JAX-RS is mainly a structured approach to solving the problem,
> > and
> > >> > does
> > >> > > > not use OOD very well.
> > >> > > >
> > >> > >
> > >> > > Assuming you don't mix local EJB and JAX-RS which are very
> different
> > >> and
> > >> > > that EJB means there remote EJB.
> > >> > >
> > >> > > Since it does serialize the payload it is 1-1 with EJB(d), you
> have
> > >> more
> > >> > or
> > >> > > less the exact same constraints there. Then you can use different
> > >> format
> > >> > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd
> > too,
> > >> > and
> > >> > > more advanced formats too)
> > >> > >
> > >> >
> > >> > Yeah, I'm referring to remotable EJBs.
> > >> >
> > >> >
> > >> > >
> > >> > >
> > >> > > > - Having stateless remote calls is fine for certain types of
> data,
> > >> but
> > >> > > I've
> > >> > > > found stateful technologies remove a lot of boilerplate stuff.
> > >> > Combined
> > >> > > > with good OOD, the savings are even better. JAX-RS is intended
> to
> > >> be
> > >> > > > stateless, so you'd be required to pass all of the state
> > >> information on
> > >> > > > each call. That requires a lot more thought, planning, and I
> > think
> > >> > it's
> > >> > > > more prone to development errors, etc.
> > >> > > >
> > >> > >
> > >> > > Nothing prevents you to have a stateful JAX-RS endpoint, you just
> > >> need to
> > >> > > ensure your client maintains the session properly.
> > >> > >
> > >> >
> > >> > Yes, I know nothing prevents you, but the whole point of REST, is
> to
> > be
> > >> > stateless, is it not?
> > >> >
> > >> >
> > >> >
> > >> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet
> > layer.
> > >> Then you do what you want. Stateless architectures are super nice for
> a
> > >> lot
> > >> of reasons
> > >> but it is not bound to JAX-RS or EJB where the recommanded practise
> can
> > be
> > >> to be stateless as well.
> > >>
> > >>
> > >> >
> > >> > >
> > >> > > >
> > >> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But,
> if
> > >> EJB
> > >> > is
> > >> > > > better for enterprise software, I'd like to be able to
> articulate
> > >> it.
> > >> > > Or,
> > >> > > > perhaps JAX-RS is best, and I'd like to be able to articulate
> > that.
> > >> > > >
> > >> > > >
> > >> > > Technically both (remote EJB and JAX-RS) are globally the same in
> > >> term of
> > >> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really
> bigger
> > >> and
> > >> > > more standard (you will find clients for all languages in 5mn, not
> > for
> > >> > > EJBd).
> > >> > >
> > >> >
> > >> > I'm curious, how do you see EJB and JAX-RS as being the same
> > >> architecture?
> > >> > EJB has the capability of maintaining state, and obfuscates the
> remote
> > >> call
> > >> > entirely, while JAX-RS does not. As far as I've ever seen, it's up
> to
> > >> you
> > >> > to develop the boilerplate code to make the call, even when you're
> > using
> > >> > JAX-RS 2 with the client api. I mean you could use something like
> > >> retrofit
> > >> > to make it sort of like EJB.
> > >> >
> > >> >
> > >>
> > >> Use CXF client factory then you will create a proxy from your JAX-RS
> > >> contract => you hide the JAX-RS calls behind an interface. It makes it
> > >> more
> > >> or less the same as EJB excepted you replaced EJBException by
> > >> WebApplicationException:
> > >>
> > >>
> >
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> > >>
> > >
> > >
> >
>
Re: EJB vs REST
Posted by Romain Manni-Bucau <rm...@gmail.com>.
you can also see the 0-day vulnerability as another step requiring
configuration with RMI and not with JAX-RS/JSON default usage. Also another
thing to justify if you get an audit ;)
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com> | JavaEE Factory
<https://javaeefactory-rmannibucau.rhcloud.com>
2016-05-30 10:14 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> Also, another aspect to all of this, is that we have a moderately sized
> application, which uses RMI for the business logic. Converting that to
> @Stateful EJB, would be a breeze, and we could really be confident it would
> continue working once we've gone through our testing cycle. I'm guessing
> that converting it to JAX-RS, could be very painful, error prone, and
> consume a lot of develop, test, fix, test, fix, test, fix, before we could
> even go live. Essentially, @Stateful EJB can literally have no code
> changes to the RMI code, except annotations, and it would work almost
> identically, except the authentication part of it.
>
> Also, OpenEJB certainly adds some nice multicast distributed server
> capabilities.
>
> On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams <
> trenton.d.adams@gmail.com
> > wrote:
>
> > That is very interesting. Apparently Jersey has a proxy client API as
> > well.
> >
> > There has to be some sort of state, even if it's as simple as maintaining
> > that your user is authenticated. With this proxy client api, is it
> > possible to have cookies automatically kept, and sent during each
> request?
> >
> > On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <
> > rmannibucau@gmail.com> wrote:
> >
> >> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> >>
> >> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
> >> rmannibucau@gmail.com
> >> > >
> >> > wrote:
> >> >
> >> > > Hello
> >> > >
> >> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <
> >> trenton.d.adams@gmail.com>:
> >> > >
> >> > > > Good day,
> >> > > >
> >> > > > I've had discussions with people that think JAX-RS should be used
> >> as a
> >> > > > replacement for technologies like EJB, for making n-tier
> solutions.
> >> > Some
> >> > > > of my main concerns about that would be...
> >> > > >
> >> > > > - JAX-RS is mainly a structured approach to solving the problem,
> and
> >> > does
> >> > > > not use OOD very well.
> >> > > >
> >> > >
> >> > > Assuming you don't mix local EJB and JAX-RS which are very different
> >> and
> >> > > that EJB means there remote EJB.
> >> > >
> >> > > Since it does serialize the payload it is 1-1 with EJB(d), you have
> >> more
> >> > or
> >> > > less the exact same constraints there. Then you can use different
> >> format
> >> > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd
> too,
> >> > and
> >> > > more advanced formats too)
> >> > >
> >> >
> >> > Yeah, I'm referring to remotable EJBs.
> >> >
> >> >
> >> > >
> >> > >
> >> > > > - Having stateless remote calls is fine for certain types of data,
> >> but
> >> > > I've
> >> > > > found stateful technologies remove a lot of boilerplate stuff.
> >> > Combined
> >> > > > with good OOD, the savings are even better. JAX-RS is intended to
> >> be
> >> > > > stateless, so you'd be required to pass all of the state
> >> information on
> >> > > > each call. That requires a lot more thought, planning, and I
> think
> >> > it's
> >> > > > more prone to development errors, etc.
> >> > > >
> >> > >
> >> > > Nothing prevents you to have a stateful JAX-RS endpoint, you just
> >> need to
> >> > > ensure your client maintains the session properly.
> >> > >
> >> >
> >> > Yes, I know nothing prevents you, but the whole point of REST, is to
> be
> >> > stateless, is it not?
> >> >
> >> >
> >> >
> >> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet
> layer.
> >> Then you do what you want. Stateless architectures are super nice for a
> >> lot
> >> of reasons
> >> but it is not bound to JAX-RS or EJB where the recommanded practise can
> be
> >> to be stateless as well.
> >>
> >>
> >> >
> >> > >
> >> > > >
> >> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if
> >> EJB
> >> > is
> >> > > > better for enterprise software, I'd like to be able to articulate
> >> it.
> >> > > Or,
> >> > > > perhaps JAX-RS is best, and I'd like to be able to articulate
> that.
> >> > > >
> >> > > >
> >> > > Technically both (remote EJB and JAX-RS) are globally the same in
> >> term of
> >> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger
> >> and
> >> > > more standard (you will find clients for all languages in 5mn, not
> for
> >> > > EJBd).
> >> > >
> >> >
> >> > I'm curious, how do you see EJB and JAX-RS as being the same
> >> architecture?
> >> > EJB has the capability of maintaining state, and obfuscates the remote
> >> call
> >> > entirely, while JAX-RS does not. As far as I've ever seen, it's up to
> >> you
> >> > to develop the boilerplate code to make the call, even when you're
> using
> >> > JAX-RS 2 with the client api. I mean you could use something like
> >> retrofit
> >> > to make it sort of like EJB.
> >> >
> >> >
> >>
> >> Use CXF client factory then you will create a proxy from your JAX-RS
> >> contract => you hide the JAX-RS calls behind an interface. It makes it
> >> more
> >> or less the same as EJB excepted you replaced EJBException by
> >> WebApplicationException:
> >>
> >>
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
> >>
> >
> >
>
Re: EJB vs REST
Posted by "Trenton D. Adams" <tr...@gmail.com>.
Also, another aspect to all of this, is that we have a moderately sized
application, which uses RMI for the business logic. Converting that to
@Stateful EJB, would be a breeze, and we could really be confident it would
continue working once we've gone through our testing cycle. I'm guessing
that converting it to JAX-RS, could be very painful, error prone, and
consume a lot of develop, test, fix, test, fix, test, fix, before we could
even go live. Essentially, @Stateful EJB can literally have no code
changes to the RMI code, except annotations, and it would work almost
identically, except the authentication part of it.
Also, OpenEJB certainly adds some nice multicast distributed server
capabilities.
On Mon, May 30, 2016 at 2:02 AM, Trenton D. Adams <trenton.d.adams@gmail.com
> wrote:
> That is very interesting. Apparently Jersey has a proxy client API as
> well.
>
> There has to be some sort of state, even if it's as simple as maintaining
> that your user is authenticated. With this proxy client api, is it
> possible to have cookies automatically kept, and sent during each request?
>
> On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <
> rmannibucau@gmail.com> wrote:
>
>> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
>>
>> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
>> rmannibucau@gmail.com
>> > >
>> > wrote:
>> >
>> > > Hello
>> > >
>> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <
>> trenton.d.adams@gmail.com>:
>> > >
>> > > > Good day,
>> > > >
>> > > > I've had discussions with people that think JAX-RS should be used
>> as a
>> > > > replacement for technologies like EJB, for making n-tier solutions.
>> > Some
>> > > > of my main concerns about that would be...
>> > > >
>> > > > - JAX-RS is mainly a structured approach to solving the problem, and
>> > does
>> > > > not use OOD very well.
>> > > >
>> > >
>> > > Assuming you don't mix local EJB and JAX-RS which are very different
>> and
>> > > that EJB means there remote EJB.
>> > >
>> > > Since it does serialize the payload it is 1-1 with EJB(d), you have
>> more
>> > or
>> > > less the exact same constraints there. Then you can use different
>> format
>> > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd too,
>> > and
>> > > more advanced formats too)
>> > >
>> >
>> > Yeah, I'm referring to remotable EJBs.
>> >
>> >
>> > >
>> > >
>> > > > - Having stateless remote calls is fine for certain types of data,
>> but
>> > > I've
>> > > > found stateful technologies remove a lot of boilerplate stuff.
>> > Combined
>> > > > with good OOD, the savings are even better. JAX-RS is intended to
>> be
>> > > > stateless, so you'd be required to pass all of the state
>> information on
>> > > > each call. That requires a lot more thought, planning, and I think
>> > it's
>> > > > more prone to development errors, etc.
>> > > >
>> > >
>> > > Nothing prevents you to have a stateful JAX-RS endpoint, you just
>> need to
>> > > ensure your client maintains the session properly.
>> > >
>> >
>> > Yes, I know nothing prevents you, but the whole point of REST, is to be
>> > stateless, is it not?
>> >
>> >
>> >
>> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet layer.
>> Then you do what you want. Stateless architectures are super nice for a
>> lot
>> of reasons
>> but it is not bound to JAX-RS or EJB where the recommanded practise can be
>> to be stateless as well.
>>
>>
>> >
>> > >
>> > > >
>> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if
>> EJB
>> > is
>> > > > better for enterprise software, I'd like to be able to articulate
>> it.
>> > > Or,
>> > > > perhaps JAX-RS is best, and I'd like to be able to articulate that.
>> > > >
>> > > >
>> > > Technically both (remote EJB and JAX-RS) are globally the same in
>> term of
>> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger
>> and
>> > > more standard (you will find clients for all languages in 5mn, not for
>> > > EJBd).
>> > >
>> >
>> > I'm curious, how do you see EJB and JAX-RS as being the same
>> architecture?
>> > EJB has the capability of maintaining state, and obfuscates the remote
>> call
>> > entirely, while JAX-RS does not. As far as I've ever seen, it's up to
>> you
>> > to develop the boilerplate code to make the call, even when you're using
>> > JAX-RS 2 with the client api. I mean you could use something like
>> retrofit
>> > to make it sort of like EJB.
>> >
>> >
>>
>> Use CXF client factory then you will create a proxy from your JAX-RS
>> contract => you hide the JAX-RS calls behind an interface. It makes it
>> more
>> or less the same as EJB excepted you replaced EJBException by
>> WebApplicationException:
>>
>> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
>>
>
>
Re: EJB vs REST
Posted by "Trenton D. Adams" <tr...@gmail.com>.
That is very interesting. Apparently Jersey has a proxy client API as well.
There has to be some sort of state, even if it's as simple as maintaining
that your user is authenticated. With this proxy client api, is it
possible to have cookies automatically kept, and sent during each request?
On Mon, May 30, 2016 at 12:23 AM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> 2016-05-30 7:52 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
>
> > On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <
> rmannibucau@gmail.com
> > >
> > wrote:
> >
> > > Hello
> > >
> > > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <trenton.d.adams@gmail.com
> >:
> > >
> > > > Good day,
> > > >
> > > > I've had discussions with people that think JAX-RS should be used as
> a
> > > > replacement for technologies like EJB, for making n-tier solutions.
> > Some
> > > > of my main concerns about that would be...
> > > >
> > > > - JAX-RS is mainly a structured approach to solving the problem, and
> > does
> > > > not use OOD very well.
> > > >
> > >
> > > Assuming you don't mix local EJB and JAX-RS which are very different
> and
> > > that EJB means there remote EJB.
> > >
> > > Since it does serialize the payload it is 1-1 with EJB(d), you have
> more
> > or
> > > less the exact same constraints there. Then you can use different
> format
> > > over JAX-RS (JSON/XML obviously, but java serialization like EJBd too,
> > and
> > > more advanced formats too)
> > >
> >
> > Yeah, I'm referring to remotable EJBs.
> >
> >
> > >
> > >
> > > > - Having stateless remote calls is fine for certain types of data,
> but
> > > I've
> > > > found stateful technologies remove a lot of boilerplate stuff.
> > Combined
> > > > with good OOD, the savings are even better. JAX-RS is intended to be
> > > > stateless, so you'd be required to pass all of the state information
> on
> > > > each call. That requires a lot more thought, planning, and I think
> > it's
> > > > more prone to development errors, etc.
> > > >
> > >
> > > Nothing prevents you to have a stateful JAX-RS endpoint, you just need
> to
> > > ensure your client maintains the session properly.
> > >
> >
> > Yes, I know nothing prevents you, but the whole point of REST, is to be
> > stateless, is it not?
> >
> >
> >
> Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet layer.
> Then you do what you want. Stateless architectures are super nice for a lot
> of reasons
> but it is not bound to JAX-RS or EJB where the recommanded practise can be
> to be stateless as well.
>
>
> >
> > >
> > > >
> > > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if
> EJB
> > is
> > > > better for enterprise software, I'd like to be able to articulate it.
> > > Or,
> > > > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> > > >
> > > >
> > > Technically both (remote EJB and JAX-RS) are globally the same in term
> of
> > > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger and
> > > more standard (you will find clients for all languages in 5mn, not for
> > > EJBd).
> > >
> >
> > I'm curious, how do you see EJB and JAX-RS as being the same
> architecture?
> > EJB has the capability of maintaining state, and obfuscates the remote
> call
> > entirely, while JAX-RS does not. As far as I've ever seen, it's up to
> you
> > to develop the boilerplate code to make the call, even when you're using
> > JAX-RS 2 with the client api. I mean you could use something like
> retrofit
> > to make it sort of like EJB.
> >
> >
>
> Use CXF client factory then you will create a proxy from your JAX-RS
> contract => you hide the JAX-RS calls behind an interface. It makes it more
> or less the same as EJB excepted you replaced EJBException by
> WebApplicationException:
>
> http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
>
Re: EJB vs REST
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2016-05-30 7:52 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <rmannibucau@gmail.com
> >
> wrote:
>
> > Hello
> >
> > 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> >
> > > Good day,
> > >
> > > I've had discussions with people that think JAX-RS should be used as a
> > > replacement for technologies like EJB, for making n-tier solutions.
> Some
> > > of my main concerns about that would be...
> > >
> > > - JAX-RS is mainly a structured approach to solving the problem, and
> does
> > > not use OOD very well.
> > >
> >
> > Assuming you don't mix local EJB and JAX-RS which are very different and
> > that EJB means there remote EJB.
> >
> > Since it does serialize the payload it is 1-1 with EJB(d), you have more
> or
> > less the exact same constraints there. Then you can use different format
> > over JAX-RS (JSON/XML obviously, but java serialization like EJBd too,
> and
> > more advanced formats too)
> >
>
> Yeah, I'm referring to remotable EJBs.
>
>
> >
> >
> > > - Having stateless remote calls is fine for certain types of data, but
> > I've
> > > found stateful technologies remove a lot of boilerplate stuff.
> Combined
> > > with good OOD, the savings are even better. JAX-RS is intended to be
> > > stateless, so you'd be required to pass all of the state information on
> > > each call. That requires a lot more thought, planning, and I think
> it's
> > > more prone to development errors, etc.
> > >
> >
> > Nothing prevents you to have a stateful JAX-RS endpoint, you just need to
> > ensure your client maintains the session properly.
> >
>
> Yes, I know nothing prevents you, but the whole point of REST, is to be
> stateless, is it not?
>
>
>
Well actually no. JAX-RS is just a nice API on top of HTTP/Servlet layer.
Then you do what you want. Stateless architectures are super nice for a lot
of reasons
but it is not bound to JAX-RS or EJB where the recommanded practise can be
to be stateless as well.
>
> >
> > >
> > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB
> is
> > > better for enterprise software, I'd like to be able to articulate it.
> > Or,
> > > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> > >
> > >
> > Technically both (remote EJB and JAX-RS) are globally the same in term of
> > architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger and
> > more standard (you will find clients for all languages in 5mn, not for
> > EJBd).
> >
>
> I'm curious, how do you see EJB and JAX-RS as being the same architecture?
> EJB has the capability of maintaining state, and obfuscates the remote call
> entirely, while JAX-RS does not. As far as I've ever seen, it's up to you
> to develop the boilerplate code to make the call, even when you're using
> JAX-RS 2 with the client api. I mean you could use something like retrofit
> to make it sort of like EJB.
>
>
Use CXF client factory then you will create a proxy from your JAX-RS
contract => you hide the JAX-RS calls behind an interface. It makes it more
or less the same as EJB excepted you replaced EJBException by
WebApplicationException:
http://cxf.apache.org/docs/jax-rs-client-api.html#JAX-RSClientAPI-Proxy-basedAPI
Re: EJB vs REST
Posted by "Trenton D. Adams" <tr...@gmail.com>.
On Sun, May 29, 2016 at 1:05 PM, Romain Manni-Bucau <rm...@gmail.com>
wrote:
> Hello
>
> 2016-05-29 20:57 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
>
> > Good day,
> >
> > I've had discussions with people that think JAX-RS should be used as a
> > replacement for technologies like EJB, for making n-tier solutions. Some
> > of my main concerns about that would be...
> >
> > - JAX-RS is mainly a structured approach to solving the problem, and does
> > not use OOD very well.
> >
>
> Assuming you don't mix local EJB and JAX-RS which are very different and
> that EJB means there remote EJB.
>
> Since it does serialize the payload it is 1-1 with EJB(d), you have more or
> less the exact same constraints there. Then you can use different format
> over JAX-RS (JSON/XML obviously, but java serialization like EJBd too, and
> more advanced formats too)
>
Yeah, I'm referring to remotable EJBs.
>
>
> > - Having stateless remote calls is fine for certain types of data, but
> I've
> > found stateful technologies remove a lot of boilerplate stuff. Combined
> > with good OOD, the savings are even better. JAX-RS is intended to be
> > stateless, so you'd be required to pass all of the state information on
> > each call. That requires a lot more thought, planning, and I think it's
> > more prone to development errors, etc.
> >
>
> Nothing prevents you to have a stateful JAX-RS endpoint, you just need to
> ensure your client maintains the session properly.
>
Yes, I know nothing prevents you, but the whole point of REST, is to be
stateless, is it not?
>
> >
> > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB is
> > better for enterprise software, I'd like to be able to articulate it.
> Or,
> > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> >
> >
> Technically both (remote EJB and JAX-RS) are globally the same in term of
> architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger and
> more standard (you will find clients for all languages in 5mn, not for
> EJBd).
>
I'm curious, how do you see EJB and JAX-RS as being the same architecture?
EJB has the capability of maintaining state, and obfuscates the remote call
entirely, while JAX-RS does not. As far as I've ever seen, it's up to you
to develop the boilerplate code to make the call, even when you're using
JAX-RS 2 with the client api. I mean you could use something like retrofit
to make it sort of like EJB.
Re: EJB vs REST
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hello
2016-05-29 20:57 GMT+02:00 Trenton D. Adams <tr...@gmail.com>:
> Good day,
>
> I've had discussions with people that think JAX-RS should be used as a
> replacement for technologies like EJB, for making n-tier solutions. Some
> of my main concerns about that would be...
>
> - JAX-RS is mainly a structured approach to solving the problem, and does
> not use OOD very well.
>
Assuming you don't mix local EJB and JAX-RS which are very different and
that EJB means there remote EJB.
Since it does serialize the payload it is 1-1 with EJB(d), you have more or
less the exact same constraints there. Then you can use different format
over JAX-RS (JSON/XML obviously, but java serialization like EJBd too, and
more advanced formats too)
> - Having stateless remote calls is fine for certain types of data, but I've
> found stateful technologies remove a lot of boilerplate stuff. Combined
> with good OOD, the savings are even better. JAX-RS is intended to be
> stateless, so you'd be required to pass all of the state information on
> each call. That requires a lot more thought, planning, and I think it's
> more prone to development errors, etc.
>
Nothing prevents you to have a stateful JAX-RS endpoint, you just need to
ensure your client maintains the session properly.
>
> I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB is
> better for enterprise software, I'd like to be able to articulate it. Or,
> perhaps JAX-RS is best, and I'd like to be able to articulate that.
>
>
Technically both (remote EJB and JAX-RS) are globally the same in term of
architecture. In term of ecosystem JAX-RS+JSON/XML is really bigger and
more standard (you will find clients for all languages in 5mn, not for
EJBd).
> What sorts of other criteria would you use, in choosing a solution?
>
>
Speed can be one, EJBd maintains connections in a more performant way than
HTTP once configured in this mode. Discovery of servers can be another
advantage if needed (multicast/multipoint).
> Thanks.
>
Re: EJB vs REST
Posted by Steve Goldsmith <sg...@gmail.com>.
I depends on the service. Some use MAC addresses, some use customer GUIDs
as keys. Typically I cache expensive calls and use the key to retrieve from
cache (thus you only pass the key, not everything that goes with it each
time). Since the cache is distributed and the VMs are behind a load
balancer it's highly available and scalable.
On Mon, May 30, 2016 at 1:46 AM, Trenton D. Adams <trenton.d.adams@gmail.com
> wrote:
> Hi Steve,
>
> Is that all stateless then? You just pass your state each call?
>
> On Sun, May 29, 2016 at 7:11 PM, Steve Goldsmith <sg...@gmail.com> wrote:
>
> > I've built a scalable solution using EJB/JAX-RS/JAX-WS. I put the
> business
> > logic in EJBs that are called from JAX-RS services. The EJBs are JAX-WS
> and
> > JAX-RS clients. I use JMS for asynchronous operations and the rest of the
> > services are synchronous. It performs very well in the 100K+ to 1M+
> > transactions a day with a couple VMs. Depends on the latency of the
> > business logic.
> >
> > I also use JCache to persist user data for fast access. I maintain state
> in
> > a distributed cache, so no dealing with sticky sessions behind a load
> > balancer. I can take a node down, do a deploy and the cache will sync
> > before I deploy the next node.
> >
> > On Sun, May 29, 2016 at 2:57 PM, Trenton D. Adams <
> > trenton.d.adams@gmail.com
> > > wrote:
> >
> > > Good day,
> > >
> > > I've had discussions with people that think JAX-RS should be used as a
> > > replacement for technologies like EJB, for making n-tier solutions.
> Some
> > > of my main concerns about that would be...
> > >
> > > - JAX-RS is mainly a structured approach to solving the problem, and
> does
> > > not use OOD very well.
> > > - Having stateless remote calls is fine for certain types of data, but
> > I've
> > > found stateful technologies remove a lot of boilerplate stuff.
> Combined
> > > with good OOD, the savings are even better. JAX-RS is intended to be
> > > stateless, so you'd be required to pass all of the state information on
> > > each call. That requires a lot more thought, planning, and I think
> it's
> > > more prone to development errors, etc.
> > >
> > > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB
> is
> > > better for enterprise software, I'd like to be able to articulate it.
> > Or,
> > > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> > >
> > > What sorts of other criteria would you use, in choosing a solution?
> > >
> > > Thanks.
> > >
> >
> >
> >
> > --
> > Steven P. Goldsmith
> >
>
--
Steven P. Goldsmith
Re: EJB vs REST
Posted by "Trenton D. Adams" <tr...@gmail.com>.
Hi Steve,
Is that all stateless then? You just pass your state each call?
On Sun, May 29, 2016 at 7:11 PM, Steve Goldsmith <sg...@gmail.com> wrote:
> I've built a scalable solution using EJB/JAX-RS/JAX-WS. I put the business
> logic in EJBs that are called from JAX-RS services. The EJBs are JAX-WS and
> JAX-RS clients. I use JMS for asynchronous operations and the rest of the
> services are synchronous. It performs very well in the 100K+ to 1M+
> transactions a day with a couple VMs. Depends on the latency of the
> business logic.
>
> I also use JCache to persist user data for fast access. I maintain state in
> a distributed cache, so no dealing with sticky sessions behind a load
> balancer. I can take a node down, do a deploy and the cache will sync
> before I deploy the next node.
>
> On Sun, May 29, 2016 at 2:57 PM, Trenton D. Adams <
> trenton.d.adams@gmail.com
> > wrote:
>
> > Good day,
> >
> > I've had discussions with people that think JAX-RS should be used as a
> > replacement for technologies like EJB, for making n-tier solutions. Some
> > of my main concerns about that would be...
> >
> > - JAX-RS is mainly a structured approach to solving the problem, and does
> > not use OOD very well.
> > - Having stateless remote calls is fine for certain types of data, but
> I've
> > found stateful technologies remove a lot of boilerplate stuff. Combined
> > with good OOD, the savings are even better. JAX-RS is intended to be
> > stateless, so you'd be required to pass all of the state information on
> > each call. That requires a lot more thought, planning, and I think it's
> > more prone to development errors, etc.
> >
> > I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB is
> > better for enterprise software, I'd like to be able to articulate it.
> Or,
> > perhaps JAX-RS is best, and I'd like to be able to articulate that.
> >
> > What sorts of other criteria would you use, in choosing a solution?
> >
> > Thanks.
> >
>
>
>
> --
> Steven P. Goldsmith
>
Re: EJB vs REST
Posted by Steve Goldsmith <sg...@gmail.com>.
I've built a scalable solution using EJB/JAX-RS/JAX-WS. I put the business
logic in EJBs that are called from JAX-RS services. The EJBs are JAX-WS and
JAX-RS clients. I use JMS for asynchronous operations and the rest of the
services are synchronous. It performs very well in the 100K+ to 1M+
transactions a day with a couple VMs. Depends on the latency of the
business logic.
I also use JCache to persist user data for fast access. I maintain state in
a distributed cache, so no dealing with sticky sessions behind a load
balancer. I can take a node down, do a deploy and the cache will sync
before I deploy the next node.
On Sun, May 29, 2016 at 2:57 PM, Trenton D. Adams <trenton.d.adams@gmail.com
> wrote:
> Good day,
>
> I've had discussions with people that think JAX-RS should be used as a
> replacement for technologies like EJB, for making n-tier solutions. Some
> of my main concerns about that would be...
>
> - JAX-RS is mainly a structured approach to solving the problem, and does
> not use OOD very well.
> - Having stateless remote calls is fine for certain types of data, but I've
> found stateful technologies remove a lot of boilerplate stuff. Combined
> with good OOD, the savings are even better. JAX-RS is intended to be
> stateless, so you'd be required to pass all of the state information on
> each call. That requires a lot more thought, planning, and I think it's
> more prone to development errors, etc.
>
> I know TomEE supports JAX-RS as well as EJB, JAX-WS, etc. But, if EJB is
> better for enterprise software, I'd like to be able to articulate it. Or,
> perhaps JAX-RS is best, and I'd like to be able to articulate that.
>
> What sorts of other criteria would you use, in choosing a solution?
>
> Thanks.
>
--
Steven P. Goldsmith