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. Cheers, Greg Trasuk > On Jun 12, 2015, at 5:50 AM, Dawid Loubser <da...@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 :-)
