Object messaging

[Matthew Browne]

Hi all,
I came across a book describing a modeling system that I think is very interesting with regard to object messaging that we were discussing in the previous thread. The book is Executable UML: A Foundation for Model-Driven Architecture by Stephen Mellor and Marc Balcer. I'm a little skeptical of the idea of an executable modeling system (at least for anything more than generating some code skeletons to get a project started), but what mainly interested me is how they model system behavior. The modeling system is named xtUML (https://xtuml.org/), and their product that includes the visual modeling tool is BridgePoint.

The example app in the book is an online bookstore. Consider this collaboration diagram:

It's interesting how the 'ShoppingCart' and 'Order' models are the starting point for handling checkout, and the 'Warehouse' handles the 'shipmentReadyToPack' event and assigns a shipping clerk to ship the order. In a typical OOP system (or at least all the ones I've seen that are considered "best practice" these days), there would be many more models (i.e. classes in so-called OOP) to handle this behavior, e.g. PlaceOrderService, OrderRepository, AssignShippingClerkService, etc. There's something about assigning these behaviors directly to Order and Shipment that seems simpler and more natural to me, and also reminds me of how in DCI objects can play roles to take on behavior that would normally be handled by some additional object or service (of course roles also handle behavior that would normally be handled by domain objects themselves). Unfortunately xtUML lacks any explicit modeling of roles; I think there's some interesting potential to be explored by adding them. But even in its current form, I think there are a number of interesting aspects of this modeling system that we could take inspiration from, especially regarding "messaging."

One of the things that's different about their system is that almost all systems behavior is accomplished via "signals" sent between objects (signals are part of the latest UML spec and were primarily introduced to model asynchronicity), which are quite different from method calls. There are no return values; in response to a signal, an object performs an action and can send a new signal in response if desired - notice how 'Order' sends a 'chargeApproved' message back to 'Customer'. It doesn't use a message bus in the typical sense, although I assume model compilers could use one in order to implement the plumbing (but that wouldn't be part of the model): instead, signals are always sent to a specific object, or to a class if you need to asynchronously instantiate a new object, or delete it. So it seems a bit similar to the Actor Model.

Another thing that I think allows for behavior like 'checkout' to be handled by 'Order' without causing models to become bloated is that persistence is handled by the model compiler - the model itself doesn't include any details about how or when objects are persisted. (This seems like it might be a slippery slope, but is still interesting.)

Back to messaging, another perhaps more questionable characteristic of xtUML is that with the exception of simple get/set behavior (e.g. Book.addAuthor()), all messages are asynchronous. This means that most classes in the class diagrams don't contain any methods but only signals (events) in the bottom section of the class diagram (note the «event» notation indicating that everything below is an "event" signal):

My assumption is that a system would be simpler to build and understand if things are synchronous by default and only asynchronous where they need to be, but the book made me wonder again about Raoul's suggestion that all messages should be asynchronous by default. Maybe it just requires the right environment and mindset to support it, which would make asynchronicity seem natural and not a source of unnecessary complexity. Still, if synchronous-by-default is desirable, it seems like the basic xtUML approach could still work, and the model compiler (or human programmer if implementing the model manually) could use synchronous method calls instead for the cases where asynchronicity isn't actually needed.

Another very cool thing is that they have a way of handling timing and synchronization that doesn't couple it to any specific technology. They simply have a set of rules about how messages are sent and in what order they should be received (which is unspecified and left up to the model compiler in cases where it doesn't actually matter), and they also allow you to send messages that are deliberately delayed to a future time.

As much as I like the simplicity of synchronous method calls for local programming, I think the xtUML model is much closer to how biological cells work together, or services communicate with each other on the internet, than method calls are - if Kay's vision is indeed the goal. Although I suppose a message bus would also be a contender for this (where the message bus is sort of like the bloodstream or nervous system).

BTW, I should note that the modeling language isn't entirely visual; there's a technology-agnostic action language that goes along with it which is a major part of what makes it fully executable - and I think being able to execute a model to verify that it's correct is worthwhile even if the code it generates is never used in a real production system. I have to say that despite my skepticism (and I'm still skeptical), I was impressed with their track record described in this article:

"xtUML is based on an object-oriented approach used on more than 1400 real-time and technical projects. These projects include life-critical implanted medical devices; DOD flight-critical systems; 24x7 performance-critical, fault-tolerant telecom systems; highly resource-constrained consumer electronics; and large-scale, discrete-event simulation systems."

There's more I could talk about, e.g. extending these concepts to include roles and contexts, but I'll leave it at that for now.

Happy new year everyone,

Matt

[Quang]

I saw similar research years ago: using xml to customize variants for different use cases. XML, Macro, Template, AOP ... they all try to solve the same problem: reuse existing components without modifying them. The tradeoff is the readability of the use case...no one can understand the business use cases any more by reading the code...they have to run the app with breakpoints to figure out how each use cases actually works at runtime. Modifying one use cases silently breaks other use cases as well.... DCI makes use cases more explicit....but we need to modify existing use cases to support new ones and that scares a lot of people.

[James Coplien]

AOP is amazingly counterproductive in this regard, because you can’t see the cutpoints when you read the source code. Yet people believed in it for years until it finally died.

Gregor Kiczales confided the real history of AOP to me in 1995. As you know he’s a big fan of reflection (and now, after DCI, I get it). He was a big of a LISP bigot and absolutely hated Java, and hated that Java was becoming popular. You just can’t do the same elegant kinds of things in Java that you can do in CLOS. So he and Crista Lopes designed a system to show just how ugly a Java solution would look if you tried to implement it. People were stupid enough to think it was great. It was called Aspect-Oriented Programming, and the rest is history.

Until 2014, that is is. Crista Lopes gave an endnote at the final AOSD conference in 2012 noting that AOP had set out with a hypothesis based on three assumptions, and that in more than 15 years of trying, none of the assumptions proved to be true. That was kind of the end of AOP for all rational beings.

-- 
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/b4a84df3-586d-4675-8b3c-6ae7efaa62c6n%40googlegroups.com.

[Matthew Browne]

I wonder what the long-term legacy of CLOS will be. For those who have used F# or other functional languages more commonly used today, do you find that people even use the class/object features of the language very much? It seems like there are plenty of functional programmers quite happily programming without anything resembling objects.

From my perspective working primarily in so-called object-oriented languages, I think one of the biggest lessons we can learn from FP that's useful even in an object-oriented context is the concept of immutability. (We've talked about this before on this group of course.) This probably has nothing to do with the topic of this thread, but I think it could be an interesting experiment to create a fork of the 'trygve' language (or create a new DCI language) where all variables and object properties are immutable by default, forcing the programmer to think carefully about what really needs to be mutable and use a keyword to specify that. Of course the 'stageprop' feature already helps with avoiding unexpected or unknown mutations in a Context.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/B82DF589-D9BB-4189-A684-8AD3D36FDA5C%40yahoo.com.

[Raoul Duke]

it is funny that i generally really want and like visual programming (cf. i mostly enjoy blueprints in unreal; i have yet to try enso) but recognize it isn't easy to create, and never personally mentally clicked well with any UMLesque styles.

plus malheureusement, if the system does not require a specific implementation, but a given environment happens to have a certain behavior, (e.g. message ordering in xUML) then humans very much run the risk of accidentally ending up with a non portable app.

cf. any-and-all unspecified/undefined/etc. behavior in C, or haxe with respect to nullness across targets, or concurrency in general natch.

hmmm the system should have fuzz checking built in. and/or a static type system that prevents humans assuming things somehow (i have no idea how).

[Matthew Browne]

Getting back to "messaging", I think what makes it an interesting and useful concept is that it's a higher-level concept than a simple method call, even one with multiple dispatch. So maybe it's useful as a concept in some contexts (little "c" contexts) that we typically think of as object-oriented but not others. If that means that we're not really doing "object-oriented programming" in a small, simple system with nothing but synchronous method calls and relatively simple instance and role method communication, then so be it. I don't think that makes focusing on "objects", their interactions, and mental models any less useful.

In any case, it's very much worth taking the "messaging" concept and applying it to more complex systems (what Kay ultimately had in mind in the first place, it seems), especially distributed ones, and/or systems designed to maximize use of multiple processors on the same machine. Obviously there has been a lot of ground covered in this area already, and many different attempts to do this, with the actor model perhaps being the most successful.

I'm interested in exploring how asynchronous messaging could work in DCI. I've always thought of DCI on a smaller scale than a large, distributed system, and I think using DCI to represent remote web services as Contexts playing roles would be a whole research topic on its own—I'm unsure if DCI would even be an appropriate paradigm there. (It would be exciting if it did work though.)

So I started small—just a single, local program. My simple little experiment (not finished and not ready to share the code yet) is based on the xtUML model of message passing. I got a fair amount of mileage out of it at first, but ran into some limitations due to the lack of any concept of a return value: when an object receives a message and performs the requested action, the only way it has to say "I'm done" is to send a new message back to the object that called it. In a general sense that's fine (and how it should work), but I think the programming environment would need some way of distinguishing between "response messages" and regular messages. For example, suppose that the Source account role in the money transfer example looks like this:

        roles: {
            Source: {
                transferToDestination({ amount }) {
                    tell(self, 'withdraw', { amount })
                },

                withdraw({ amount }) {
                    tell(self, 'decreaseBalance', { amount })
                }
            }
        }

In the 'withdraw' role method, the account sends a 'decreaseBalance' message to itself, which is received by the Account Context (or class, depending on the implementation), but the Account Context doesn't have a good way of sending a message back to the Source role—it can't do so directly because in this asynchronous "fire-and-forget" model, that would mean breaking the rule that role methods should only be callable by code within their enclosing context (in other words, Contexts should be encapsulated). One idea I came up with to solve this in a simple way is to make a special exception for response messages:

        roles: {
            Source: {
                responseMessageHandlers: {
                    increaseBalanceSucceeded({ amount }) {
                        tell(destination, 'deposit', { amount })
                    }
                },
                ...

The environment would need to ensure that response messages can't be sent or received where they shouldn't be—the goal is only to allow the flow to return to the role that made the original request.

This is all very rough and preliminary of course, but I'd be curious to hear anyone's thoughts on this.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/CAJ7XQb5myhUusieA3%2BjRycCpgi3x7CRe6vht8V5vPZ4zQTrZNQ%40mail.gmail.com.

[Matthew Browne]

There are two other updates I wanted to share...

1. I watched a few more Alan Kay videos over the holidays. My favorite was "Doing with Images Makes Symbols"—really fascinating stuff, and the article that led me to it was also interesting. But in this video, he addresses the topic of messaging directly:

If you think about scaling... And this is what biology is partly good for—we tend to think on the scales that we live in in computing, but biology is on scales millions and millions, billions of times larger. And once you scale out, as we were thinking about in the internet, you have to get away from gear-like meshing of procedure calls and stuff and you have to go to something like messaging.

So if we really want to get to the root of messaging and object-orientation, I think we have to recognize that Kay's concept of messaging was always inextricably tied to biological-like systems and massive scalability, even though it wasn't achievable or even really attempted (the messaging part at least) in Smalltalk 72.

2. I read more about xtUML, and as I conjectured earlier, there's nothing about it that forces you to make everything concurrent or parallel. All messages are asynchronous at a conceptual level, but in the book they give this example of a model that can be implemented without concurrency:

Now consider a pacemaker. This application has a loosely periodic nature that can be expressed asynchronously using timed signals to assume the  responsibility for detecting the nonoccurrence of certain periodic events, such as a heartbeat. There is no need for concurrency, nor a distributed  network of computers. Rather, the goal is to minimize the computing hardware required so it can be implanted in the body.

A model compiler that optimized memory usage and executed on a single chip without concurrency would be ideal for this situation.

One more quote:

Similarly, Executable UML has active elements such as “signal” and  “action,” and the model compiler must provide an implementation for these too. Hence, a call to a SignalTaker function could implement a signal synchronously within a single task, as could the sending and receiving of a particular kind of message between tasks.

I've highlighted the examples of synchronous approaches, but of course technologies like Akka also work well for implementing xtUML signals/messages when concurrency is actually needed.

[Raoul Duke]

my first thought is of course to just use erlang :-)

[Matthew Browne]

Haha yes... and how would DCI look in erlang? Not being sarcastic; I genuinely don't know if anyone has tried this...but I suspect it would need a little help (e.g. language extensions, source transformation) to achieve highly readable code.

On 1/21/24 10:29 AM, Raoul Duke wrote:

my first thought is of course to just use erlang :-)

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/CAJ7XQb5kYF2qsgeOtKa0c619%2Bp8%2BZgWPYkc7jjkvANXNoQjQhQ%40mail.gmail.com.

[Raoul Duke]

i am not a biologist but... not sure how much we should strive to slavishly copy biology. at least stuff like cellular signals. (synapses are maybe perhaps more amenable to modeling simplistically so i'm not meaning those here.) afaik biology is not debuggable like software. messaging in biology is very different iiuc. messaging tends to be a flood rather than a single mesage. and the final meaning is a stochastic statistical result. with lots of redundancy. lots of message duplication and even alternative backup messages. sure it has been successful thank Darwin but i cannot say i think we know how to do all that in software. 

[Matthew Browne]

On 1/21/24 10:36 AM, Raoul Duke wrote:
> i am not a biologist but... not sure how much we should strive to
> slavishly copy biology

I agree with this. It's more about taking inspiration from it. I've seen
others who know more about biology say similar things about applying it
too literally to software...obviously there are certain things in
biology that you can't afford to have fail, so there are tons of
redundancies. There are some similar situations in software but they're
not the norm, and also the way biological systems do it probably isn't
the most efficient. Plus there are all kinds of quirks that have evolved
over time that don't always help or still serve a purpose even if it
"works".

[Lund Soltoft]

> Den 21. jan. 2024 kl. 15.32 skrev Matthew Browne <mbro...@gmail.com>:
>
> I'm interested in exploring how asynchronous messaging could work in DCI. I've always thought of DCI on a smaller scale than a large, distributed system, and I think using DCI to represent remote web services as Contexts playing roles would be a whole research topic on its own—I'm unsure if DCI would even be an appropriate paradigm there. (It would be exciting if it did work though.)

Inspired by Alan Kay’s definition of OO programs being a network of interconnected objects. I made a POC some years ago where you could compile some ASP.NET into memory or separate the services into docker containers. The idea was that in memory you could single step debug through the code while in production you’d be able to using horizontal scaling for each service. Those service could be seen as a static/identityless version of a context and for each message being sent it would find the right actors. It wasn’t any where close to DCI but it did get me thinking that it would be possible to write a compiler of sorts that would use container images as the blue print for contexts

[James O Coplien]

On Jan 21, 2024, at 15:32, Matthew Browne <mbro...@gmail.com> wrote:

I'm interested in exploring how asynchronous messaging could work in DCI.

I’ve thought a lot about this and have decided that it’s a relatively uninteresting problem — at least, no more interesting than with asynchronous messaging in C.

I once found one place in the execution flow where DCI introduces an additional critical section under a reasonable implementation, but I think that is readily handled. I don’t remember what it was...

[Matthew Browne]

Here is what I found interesting about the xtUML model of concurrency...quoting from the Executable UML book:

"This view of time is similar to Einstein's relativistic view of time. If we transmit a signal to two stars, one of which in turn transmits a signal to our second star, it is not known which signal will arrive at the second star first, only that if we send two signals to a single star the signals will arrive in the order we sent them."

One of the "rules about signals":
"No priorities. Similarly, there is no notion of signal priority, in these rules, and a modeler cannot arbitrarily accelerate one signal ahead of another. To do so would be equivalent to 'going backwards in time.'"

However:
"Signals sent to self are always accepted before other signals to that instance."

Of course, this is not the only approach in the UML space. I also came across this paper which combines the actor model with hierarchical state machines, but I wonder if that's over-complicating things for most use cases.

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/object-composition/93184BE5-9DFF-4877-BD66-9EA269212728%40gmail.com.

[Matthew Browne]

That sounds cool :) And I like the idea of a local in-memory option for debugging.

The docker containers sound quite granular (depends on the use cases of course)...but I suppose the essential idea would still work just as well if each docker container contained its own little network of interacting local Contexts...?