river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Using an unchecked exception instead of RemoteException
Date Fri, 12 Jun 2015 15:31:01 GMT

Just a comment on the complexity of Jini services.  I agree that starting up Jini services
using the ServiceStarter is overly complex and arcane, which is why other service frameworks
like Rio, StartNow, and river-service-container exist.

I’m hoping the river-examples project makes things a little easier for people, as well.
 Also, it would be great if we could adopt a service-definition method that’s a little more
like EJB3 or JAX-WS.  Can’t get much easier than putting an annotation on a class.

However, I stopped thinking that Jini services themselves are complex after I did some work
with the WS-* stack.  You can’t tell me that the combination of WSDL, WS-SE, Schema, and
everything else that goes along with WS-* is simpler than Jini.

So take heart, setting up security wouldn’t be any easier under any other SOA framework.


Greg Trasuk

> On Jun 12, 2015, at 5:50 AM, Dawid Loubser <dawid@travellinck.com> wrote:
> On 12/06/2015 05:34, Palash Ray wrote:
>> In my 2 years of using Jini, one feedback that I have as a developer is its
>> overtly complex. For instance, if I want to configure security, its so
>> complex, that I have to spend days together to get it up.
>> I strongly believe that we should try to make things simple for the users.
>> And flexible.
>> Thanks,
>> Palash.
> Fair enough. But distributed security (e.g. authentication) is a
> somewhat inherently complex problem!
> What are you looking to achieve? I always find that true distributed
> systems, having more of a peer-to-peer nature,
> don't have a single, authoritative point of control. In the long run, I
> think that some sort of federated trust model,
> similar to what we have with PGP, might work.
> If what you're building is inherently client/server, and especially if
> you're just shuffling data around, Apache River is
> often not the right solution. The sorts of problems that River provides
> solutions to, make it inherently more complex
> for some other common scenarios.
> regards,
> Dawid
> P.S. This discussion should probably be on the river *users* list, not
> the *dev* one :-)

View raw message