I’ve had a few questions from folks about the App Tethering articles I’ve been posting, specifically, when the next one is coming.
Between work and preparing for a grading I’ve been a bit busy, however I’ve now started writing the next post and have a few more planned. The next one should be up in a week or so.
Also, several people have asked if they can get them all combined into a single document. Once I have the remaining articles done I’ll combine them and post the details.
After the last few posts, you should be getting comfortable sharing data between multiple apps. That leaves us the last of our original four conceptual areas to cover off : Actions.
Just as App Tethering allows you to share pieces of data out to remote applications, it also allows you to share TActions (strictly speaking, any TCustomAction descendant, but I’ll use TAction for short). Right now you’ve possibly got at least one button or menu item connected to a TAction somewhere in your app. More likely you have dozens of them. Shared Actions let you expose these TActions unchanged, so they can be triggered from remote apps as well. Read On…
Now that we know how to work with Persistent Resources, Transient Resources are going to be a walk in the park.
Transient Resources have many things in common with Persistent Resources. They come in both Data and Stream types. They are one-way. Also their network behaviour is much the same as Persistent Resources. ie. Transient Data Resources are sent via UDP Point-to-Point whereas Transient Stream Resources are notified via UDP Point-to-Point but the value is actually transmitted via TCP.
Where they differ is mostly around the details of how they are sent, and how much work you have to do vs how much the framework does for you. Read On…
Last post we were introduced to sharing resources, in particular, persistent resources, and we wrote an example to share a persistent resource of type Data between two apps.
This time around let’s do the same with a resource of type Stream. On the surface it feels pretty similar, but we’ll look under the covers to understand a key difference between sharing Data and Stream resources, and why you might opt to use a Stream resource even if you are sharing a String.
That’s fine, but there’s not a lot of point in having two apps connected to each other unless they can interact. In App Tethering, that interaction comes in two forms: sharing resources and sharing actions. In this article we’re going to start looking at sharing resources. Read On…
In the previous post, we covered an overview of what App Tethering is and how some customers have used it. We also covered the four conceptual areas of App Tethering:
Let’s take each of these concepts and start looking in more detail. Read On…
One of the capabilities introduced in recent versions of RAD Studio and AppMethod is App Tethering. Over a number of posts I want to explore App Tethering further, starting from an overview of the technology and then going further down… down eventually to the network packet level. My aim is you’ll come out with a quite thorough understanding not just how to use App Tethering, but also what you might use it for.
In the absence of anywhere else to start, let’s start with a question.
In its simplest terms, App Tethering makes it easy for apps to find and communicate with each other. Now, I accept that is so generic an explanation as to be almost useless. You could say something similar about DataSnap, or EMS, or plenty of other distributed systems. So let’s shed a bit more light.
Last week I presented on “Building Distributed Applications That Don’t Suck” twice at the ADUG conferences in Melbourne and Canberra. As the name may suggest, it’s a heavily opinionated session about the common mistakes people make when building distributed systems, and some techniques you can use to avoid the mistakes.
One of the great things about opinionated sessions is that they spark arguments, and I have thoroughly enjoyed the discussions that started during the breaks between sessions and that have continued on in email since then. One of those discussions has been around distributed transactions, and my advice to actively look for opportunities to avoid them. In the session I discussed how, where the business rules allowed, you could use things like Idempotency and even ordering of inserts to avoid the cost of a distributed transaction. However, it was the topic of Eventual Consistency that caused the most angst.