12

How can I implement my cross-platform library (e.g. on JRE) to operate in a thread-safe manner on object references, so that native front-ends on other platforms can observe the object and take advantage of Observable patterns?

A little background--there is a concept of data binding used in most front-end frameworks. In C# and Java this is related to the Observable trait that gives a class the ability to fire events when changes happen, to which multiple controls or "observers" may subscribe. This way the observers don't have to keep polling/reading the resource, comparing for updates.

I want to work on an analysis engine that makes changes to lists of data over time. It would be nice to be able to have the front-end be able to observe these lists while the analysis is running. It seems to me this would require the front-end to be able to pass an object to the analysis engine, written in a library that hopefully is cross-platform, and be able to make thread-safe reads to that object. Or else, have the library satisfy observability contracts.

The way this is handled in older Unix-style CLI engines is to use stdin/stdout/stderr, and have the engine post updates on regular intervals. This requires standard overhead and text parsing that I would rather avoid, if possible.

Brandon Arnold
  • 1,253
  • 9
  • 15
  • 2
    It's generally best to make the core question a little narrower than "Is X possible?", since the correct answer to that is almost always "Yes, if you try hard enough." It sounds like you really want to ask "How can I do X without the overhead of stdin/stdout?" In which case, why not simply use a statically or dynamically linked library? Do you need this library to be a separate program from the UI for some reason? – Ixrec Aug 25 '15 at 22:16
  • Thanks, Ixrec. Do you think I have phrased it the way you suggest in my title? The reason I would like the library to be portable, and the front-end to be native, is because I think native UI frameworks generally work better (opinion alert!), but I don't want to write the logic of the engine twice. – Brandon Arnold Aug 25 '15 at 22:22
  • Why can't a statically or dynamically linked library be portable? Re: The title, that's a textbook example of a "too broad" question; I didn't focus on that because there appeared to be more specific questions in the rest of your question. – Ixrec Aug 25 '15 at 22:24
  • @Ixrec It can. The question assumes that it is a library, which includes those possibilities. I would just like to make sure that any applications which consume this library will be able to observe references to objects that are passed to it asynchronously, while they are being operated upon. – Brandon Arnold Aug 25 '15 at 22:27
  • 1
    @Ixrec I have updated the title to be less broad – Brandon Arnold Aug 25 '15 at 22:35

2 Answers2

1

You can create an integration tier over your library's model using (for example) the apache camel integration framework. The Netty component probably could fit your needs. With an observable pattern your integration tier should transform your model's received changes and notify them to the front-end subscribers. Another similar way to interpret your requirement is to think about an event-driven architecture where when your model changes, the observer listeners in your integration tier publishes a message in a JMS Topic so connected subscriptors in the front-ends will receive them.

AlexCG
  • 11
  • 4
0

I wrote a completely different answer, suggesting that your publisher writes updates to a queue or a pipe -- but I then I re-read the question.

If I understand right your general question is that you want to write a library to run in the JRE, in which a native front-end can query the state of Java objects in a thread-safe manner.

This is incredibly broad because there are hundreds of ways a front-end can interact with library code running in a JRE -- JNI, EJB RPC, RPC-style HTTP interfaces, request-response over message queues, etc.

Whichever you choose though, at some point in the chain, there ought to be a Java method call, and that's where you get to take control of thread-safety. There, you have the whole arsenal of thread-safety tools at your disposal. You can synchronise, you can return defensive copies, work with cached data, etc.

However, do consider whether this is the model you want to follow. It may be cleaner to move to a "don't ask me, I'll tell you" model, in which your library pushes updates to the front-end containing sufficient information that it doesn't need to query the objects.

slim
  • 799
  • 1
  • 6
  • 11
  • Extra comment - have you considered using Redis (or similar) as an intermediary between your front and back ends? – slim May 31 '16 at 10:13