Use of Jini #20
Comments
|
What are some of the alternatives? Should we research some of the latest microservices stacks to achieve these goals? For both Cassandra and JINI, my concerns would be tight coupling to specific providers of the functionality we need. Could these be refactored out to be behind an interface, with Spring or Guice driving the DI? Perhaps such interfaces are not easy to refactor out. |
|
Invitation sent to user@river.apache.org Hi Folks, Many years ago I had a friend who spent some time telling me about "how cool" Jini was, but I never really got around to investigating it for myself at that time. Several years ago I was thinking of a project and remembered what he sad and read the Jini specs. They struck me as something that should have been much more successful than they were. They really look like they solve a lot of key problems, and I started playing a little bit and decided I probably wanted to use river. However in the way that side projects often do, it fell victim to work schedules etc. Lately, I've been reviving the project and now I've got a collaborator and a very rudimentary 0.1 release. The primary concern I've heard every time I mention Jini to anyone is the perception that it's old, done, yesterday, dying etc. Having been lurking on this list for the last couple years I can say that releases still happen and it's "Not Dead Yet" (in my best Monty Python voice) but I also can't honestly say it's very lively either. Help me counter the nay sayers :) I've laid out my reasoning for why it fits with what I want to do in the link below and I'd like to invite anyone who actually uses Jini regularly to do any of the following:
I've started an issue in my Github repository to describe the way I plan to use Jini and host discussion about pros/cons of this choice so if you're interested you can find it here: #20 I also hope that if this project succeeds it might serve to re-publicize jini a bit and bring it back into the attention sphere of some of the larger open source software community... Best, Gus |
|
Ah besides the tutorial link on the river site, google just revealed to me this more detailed site also by Jan Newmarch http://www.javacoffeebreak.com/books/extracts/jini/jini.html |
|
If you perform interface based design and programming practices, then you already have what you need, in your design/system, to use Jini. The "Remote" interface is an additional requirement so that all methods in your interface throw "RemoteException". Some people choose to use a different object as a delegate for the remote implementation/inbound-call-sync. What is important to understand about Jini is the freedom it gives you to stop having binary->text->binary marshal->unmarshal->instantiate overhead in your application. You can just use serializable objects and make the majority of applications work. What doesn't work so well in any network application, is the transport of large data objects continuously. If you are doing Documents and using Javaspaces as an async store and forward queue, it is probably worth creating a document store service and just providing GUIDs in you java spaces entries which allow any client, at any point, to go get the document from the storage service. That would be the place for your leasing to go through for lifecycle management. The lease time can be stored at the time of insert into the document storage service. Then, you can use a classic timeout mechanism to discard the document. The document storage system could then retain the registration without the document for a more extended time and respond to "Get" requests with an appropriate failure message. |
|
Thanks for the input Gregg. I'll keep your comments about interfaces and serialized objects in mind. I'm interested in your comments about JavaSpaces. First off, I agree that data transfer has to be minimized. In my conception of the system (which I probably haven't properly documented anywhere) the basic mode of operation is passing documents from step to step in the JVM with no persistence, and of course no network transport. JavaSpaces would only come into play when documents need to be passed from one machine to another. I'm generally thinking that the last step to execute on Machine A before the hop to Machine B would store the Document in a JavaSpace hosted on Machine A, if possible within the same JVM (I hope that's possible but haven't validated). Thus the only cost for that step is expressing the document such that it complies with the Jini Entry Specification. Since we are sending from machine to machine and the Document Processors will often need to access the bytes of the document itself (i.e. we are hopping to one of N machines deployed to provide OCR) we probably can't escape the transport cost of a single transfer per machine hop. Writing to an external store, passing a reference and then reading back from it would seem be two network transfers. Your point about marshal/unmarshal steps does seem applicable to this however. It's possibly difficult to make the document object itself a valid Entry, and if so we have a similar conversion to/from an Entry (I tried once and gave up but I no longer remember why). Such conversion shouldn't be as heavy as conversion to JSON or XML or database write, but still might be excess processing. The reason steps don't just send to each other directly is that I want to have the steps pull their next document rather than block the preceding step, which is why I need some sort of storage between machine hops. Usually if one has configured the system to hop to a new machine the next step is something heavy that needs to be spread across machines. Writing this I realize that I may not yet have designed in sufficient capacity in this regard between steps within the JVM however. A buffering scheme should probably be be available there too. hmmm... maybe. Need to think more on that. Presently there is a "batchSize" which controls the size of the incoming queues, but really large queues would be memory hogs and when small queues fill up they have to block to avoid loss. Maybe everything should go into the local JavaSpace and I should just make that as efficient as possible? |
|
I'd like to understand the pros and cons of using JINI especially in the light of the recent surge of activity around the notion of microservices and the related tools and frameworks. For instance, Lightbend, the makers of Scala and Akka, have published a high level overview here. Their CTO Jonas Boner has some interesting presentations on slideshare also. Other links:
And of course, there's a bunch of materials from Martin Fowler. I think it may be worth doing some research to see what advantages we may get from JINI vis a vis these other tools and frameworks. |
|
Jini has been moderately successful, it's used in a number of successful commercial products, but it isn't very visible publicly. It's used for federating compute resources on local area networks, NAT - network address translation limits it's use outside local area networks, however IPv6 doesn't have this limitation. I've registered IPv6 multicast discovery protocols on IANA, but they're not implemented in any Apache River releases yet. No modern frameworks provide equivalent functionality at this time. You're interested in SSL, so it sounds like you want to venture past the firewall :) Regarding security, the SSL protocols haven't been updated, so you can't use the latest and greatest such as AES_256_GCM or key exchanges such as ECDHE_ECDSA and ECDHE_RSA, at least not without modifying the source code. I'd recommend using Java 8, as this prevents the use of weaker SSL protocols that are vulnerable to MITM attack. The strong encryption constraints in Jini are considered weak nowadays. Set the following system property: Regarding Entry's, these are like a Java interface (prior to Java 8), once defined and deployed, do not change them; or you will end up in a world of hurt. Entry's are not designed for evolution or change, do not change the names of fields, or their order, or add or remove fields from an Entry after deployment. If you need new fields, create a child class that extends the original Entry. |
|
Hi Peter,
|
|
You're welcome. If you're new to Apache River and don't have an existing deployment, you may like to try checking out and building from trunk. I believe River is only making source releases going forward, unless someone volunteers to make a binary. The trunk branch uses Groovy for configuration and contains over 250 bug fixes (most relate to race conditions and Java memory model compliance, a lot of code in 2.2 pre dates the current JMM), the 2.2 code has been in deployment for ten years or so (containing only minor changes since Jini 2.1). However concerns remain that new bugs may have been introduced in trunk and their impact on existing deployments is unknown. Existing deployments have either found workarounds for existing bugs or aren't affected by them, the upcoming River 3.0.0 source release will be in beta, trunk is frozen ready for release, when it occurs. If you're a new user, you're likely to be less impacted by bugs with trunk, which has been tested on IBM's J9 JVM and Oracles JVM on multiple CPU architectures as well as FindBugs static analysis, it's test suites are all maintained, including the jtreg test suite. The 2.2 branch, has the benefit of existing deployments, however its jtreg test suite hasn't been maintained, certs have expired etc, and it hasn't received the scrutiny that trunk has in recent times. If you're really adventurous, Cheers, Peter. |
|
Regarding IPv4 NAT translation, these are the limitations it places on Jini:
|
|
IPV6 certainly is something we should be supporting. Is there a way to limit how far away JINI will look (via a TTL on the packets for example?) It would probably be quite cool to run with a TTL of 2 or some small number and be robust vs small network adjustments, but throw up a warning when we see things change... so the system doesn't break but you know your sysadmins are up to something and might need to be reminded of your system's particular needs. Probably over thinking it though :) |
|
The good thing about IPv6 is addresses are self auto discoverable/self assigning, all the IPv4 network configuration issues dissappear. Although IPv6 supports TTL, additionally, there are multicast groups, eg jini-announcement; node local FF01::155, link local FF02::155, site local FF05::155 and variable scope FF0X::155. Groups are independant, if you join one, you won't receive packets from one of the other groups, unless you join them also. For now, I've only implemented site local for jini request and site local or variable scope for jini announcement. |
|
Unfortunately Apache River has moved to the attic, and is retired. Some other solution will be required. |
|
JGDMS is a maintained evolution of River, it can be found here:
https://github.com/pfirmstone/JGDMS
River was suited to private networks, but not the internet.
JGDMS is a fork of River, re-architected for the internet, with the
following capabilities:
1. IPv6 Multicast Discovery, X500 distinguished names, integrity
checking hash functions.
https://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
2. TLSv1.3 Stateless session ticket resumption
3. Atomic Serialization - a public serialization api, implementing
classes define a de-serialization constructor. Currently there is
only one provider, a subset of Java Serialization, which prevents
gadget attacks using input validation and atomic failure. See
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-platform/src/main/java/org/apache/river/api/io/AtomicSerial.java
4. Services can be configured to use JERI (Jini Extensible Remote
Invocation) with Atomic Serialization
https://github.com/pfirmstone/JGDMS/blob/trunk/JGDMS/jgdms-jeri/src/main/java/net/jini/jeri/AtomicILFactory.java
Unlike earlier versions, codebase annotations aren't included in the
serialization stream, class visibility is determined by a
ClassLoader at each JERI Endpoint. The Server Endpoint ClassLoader
is configured, the client Endpoint ClassLoader is created for each
service identity, so that services that use identical codebases, but
different identity (Eg, an identical service using a different
server Principal, running on a different server, will have a
different identity).
5. Supports securely authenticated Remote Event's and distributed
garbage collection. River / Jini, only supports Remote Event's for
anonymous, unauthenticated event servers.
River 3.0 broke backward compatibility with River 2.x, by changing the
com.sun.jini namespace to org.apache.river, JGDMS includes a Jini 2.x
compatibility library
Compared to River, JGDMS has improved:
1. Security
2. Scalability
3. Performance
4. ClassLoading
5. IPv6 Network support
…--
Regards,
Peter Firmstone
On 15/01/2023 2:26 am, Patrick (Gus) Heck wrote:
Unfortunately Apache River has moved to the attic, and is retired.
Some other solution will be required.
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYWKMUXSLNK6XOL3P7AABTWSLHUVANCNFSM4B626WFA>.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Hi Peter, Thanks for the info! You might want to get your project listed on the attic page for river then (https://attic.apache.org/projects/river.html) |
|
Thanks Gus,
Probably be helpful for users visiting the River site.
…--
Regards,
Peter Firmstone
On 16/01/2023 4:41 am, Patrick (Gus) Heck wrote:
Hi Peter,
Thanks for the info! You might want to get your project listed on the
attic page for river then (https://attic.apache.org/projects/river.html)
—
Reply to this email directly, view it on GitHub
<#20 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACYWKMQZYTZ6S7UDIG7NRJLWSRAF3ANCNFSM4B626WFA>.
You are receiving this because you commented.Message ID:
***@***.***>
|
This issue will be used to explain what it is we hope to get out of Jini, why it looks useful and discuss whether or not these expectations are realistic. Also alternative solutions may be examined. There is repeated concern about the health/viability/future of JINI and so folks ivolved in the Apache River project will be invited to comment on this issue and argue for or against these proposed usages of Jini.
General Goals:
(1) Except a group name (as per DJ.1.4.1) denoting a particular logical jesterj system (several might exist on the same network), and a secret/password/key/??/etc for access to the system
Specific benefits of Jini:
The text was updated successfully, but these errors were encountered: