I think the idea is that any time an object changes its properties, associated objects will automatically get notification. The observed object need not have actions such as the following snippet in a Shipment state model:
this.Delivered = true;<Ref>Order order = FIND this->A1;GENERATE Order:orderDelivered() TO order;
Instead, A1 would imply that the order object will get change notification. The action language would only update a flag:
this.Delivered = true;
The change to Shipment:Delivered would cause the order object to get an ShipmentChanged signal by virtue of the A1 association.
I feel like the DDS way makes the inherent coupling less explicit. I want inherent coupling to be explicit and non-essential to be coupling removed. Order and Shipment are coupled and changing the way that is declared doesn't change the fact.
I would like to put DDS DCPS in the category of transport technology subsystem where it would not affect the application subsystem model. It would only affect how I translate the model into an executable system. The GENERATE statement in the AAL doesn't mean I cannot use DCPS mechanisms to make the system behave according to the model. However, when I use explicit message sending in the application subsystem model, my colleagues call a foul.
However, DDS has complicated that by introducing
the publish/subscribe model, which adds coupling because to subscribe
the sender needs to know what the publisher provides! How can these guys
claim they have minimized coupling when they do that?
If not with the provider, with who?
Sure. But my problem (other than a lot of overhead!) is on the> subscriber side. The subscriber has to explicitly define what data it
> needs. It also has to provide enough information so that the
> registration process knows which publisher to match (e.g., which one
> of 247 publishers with a 'color' attribute does the subscriber really
> want.)
Well, obviously there has to be some agreement about message identity and content or it would be difficult to communicate, but I think one can get pretty close to the publisher announcing that something has happened with the relevant data and subscribers can look at the list of possible messages and decide which ones they are interested in. That can be quite loose.
The other is> that the subscription specification is indirected through the
> publish/subscribe Manager (or whatever they call it). I think those
> two issues combine to be a nasty maintainability problem because of
> the coupling through the third party Manager.
I don't see the coupling. Instead, I see a good separation of responsibility. The manager knows nothing about message content or even about the identity beyond that it currently has a message with a particular identity in the system. What it does know about is the topics and queues, i.e., the plumbing responsible for receiving and passing along messages to interested parties ... not to mention added value services like failover.
Au contraire! That manager has to know a lot about content. The problem is the registration. It is a matter of knowing who publishes what data and who subscribes to what data. When you insert a third party (other than the message sender and receiver) to analyze and match subscriber and publisher, that third party now has an intimate knowledge of what both sender and receiver know. That breaks encapsulation, regardless of whether it is hidden or not. You can optimize the actual message passing by doing a look-up and passing the data packet as-is. But to define that look-up the manager has to have intimate knowledge of the objects.I don't see the coupling. Instead, I see a good separation of responsibility. The manager knows nothing about message content or even about the identity beyond that it currently has a message with a particular identity in the system. What it does know about is the topics and queues, i.e., the plumbing responsible for receiving and passing along messages to interested parties ... not to mention added value services like failover.
The best way to see that is to look at how object state machines work because they enforce good encapsulation. When a state action sends an event, the action's behavior does not know who the receiver is, why it is going to that receiver, or what the receiver will do, if anything, in response. As far as the sender is concerned, all the event does is announce that it has done something. Similarly, the receiver's behavior does not know where the event came from or why it was sent. Thus the sender's and receiver's behaviors are functionally completely decoupled as far as what they know about each other. The reason is because the rules of finite state automata stipulate that a state action cannot know what the previous state was or what the next state will be.
I think we may be arguing slightly at cross-purposes, because I've been working with a primitive tool that expects publish/subscribe to be used in what are really inter-domain bridges but which (because of tool limitations) need to be written by hand; the publisher is typically an I/O domain, the subscriber an application domain, and the subscriber's response to the "target acquired at <position> with <velocity>" message from the Radar is to post the appropriate events to its own domain objects.
Au contraire! That manager has to know a lot about content. The problem is the registration. It is a matter of knowing who publishes what data and who subscribes to what data. When you insert a third party (other than the message sender and receiver) to analyze and match subscriber and publisher, that third party now has an intimate knowledge of what both sender and receiver know. That breaks encapsulation, regardless of whether it is hidden or not. You can optimize the actual message passing by doing a look-up and passing the data packet as-is. But to define that look-up the manager has to have intimate knowledge of the objects.I don't see the coupling. Instead, I see a good separation of responsibility. The manager knows nothing about message content or even about the identity beyond that it currently has a message with a particular identity in the system. What it does know about is the topics and queues, i.e., the plumbing responsible for receiving and passing along messages to interested parties ... not to mention added value services like failover.
One mechanism used to address this issue keeping publishers/subscribers decoupled is dynamic discovery via domain-specific service metadata. OSGi, UDDI and Jini are concrete examples that come to mind. That allows, for instance, a program to send a document to the color printer John Doe has access to that is closest to his office without having knowledge of what printers are actually available.
Great debate!
I want to suggest that a concrete example of a loosely coupled system is a system that must be extended w/o re-deployment of the original components. I'm using "loosely coupled" to help make requirements distinct from the design concept of "loose coupling." A loosely coupled system just means that it is a reality that the system is made up of not-very-easily-controlled set of elements. They are not well coupled to each other and that is just an attribute of the problem space. Give a problem space like that, one in which we don't have the option to better integrate the pieces, what are the design patterns that help us? Pub/sub is one. What if the problem space elements are better integrated and not loosely coupled? Should we still always use Pub/sub? Doubt it.
Regarding the design concept of "loose coupling," we want to make coupling as tight as required but no tighter. Loose coupling is very commonly stated as a goal as if the looser the better. Not so.
Right, but the direct OO communication has less overhead.
Which is sensible in those places where tight coupling is appropriate, but when loose coupling has an advantage, the small overhead is more than justified by the advantages.
> Let's try this a different way. A topic is just a shortcut. It says,
> "I publish this pile of very particular data called X (topic) and I
> put it in a very specific place (queue)."
Well, no. A queue is a channel that delivers a message to a single end point and a topic is a channel that delivers to multiple endpoints. The topic is typically a category of related messages, like a TV channel with a particular theme. The publisher publishes a message to that channel because all messages about a certain subject are published there. The subscriber listens to that channel because it is interested in messages on that subject. The publisher and subscriber choose the channel, not the MOM. The MOM only manages the channels. Only with Content-Based Routing, found in ESBs, does the MOM even look at the content and then only of specified messages and only the content needed for the routing decision. As I described before, this is an alternative to using an external routing service to make the decision.
The only semantic difference is that in the OO case the access is> peer-to-peer while in the publish/subscribe case there is an
> intermediary.
Actually, they are entirely different.
More important, one has exactly the same problem during maintenance> when the pile of data associated with the topic changes. Now you
> potentially have to perform surgery (e.g., add new queues and topics
> or navigate to different objects) with the registration mechanism
> because some existing subscribers may still want the old pile of X
> data.
Most ESB messages are XML (which I know you despise, but let's not get distracted by that) so if a new or revised consumer needs a new piece of data than is contained in an existing message, one typically just modifies the supplier to add that data and that specific consumer to use it.
As I have said a couple of times, the coupling is not in the> transmission; it is in the subscription. No matter what the
> terminology is for a particular implementation, somebody (usually the
> developer) has to know what I quoted. You cannot create the necessary
> lookup tables for routing without that information.
There are no lookup tables.
> That last clause of the last sentence is the problem. I have consumer
> A and consumer B of a single pile of published data. The requirements
> change and consumer A needs to substitute a new data element in that
> pile for another. However, that requirements change does not affect
> consumer B. There is no way that you can accommodate that without
> both changing the subscription specification for consumer A and
> adding a publishing specification for the source and, somehow,
> providing a mapping between them.
Well, no. Much of the time one simply adds an additional data element to the message.
The same thing would be true if the subscriber talked directly to the> publisher in an OO fashion. The difference lies in the intermediary
> for publish/subscribe. Now the subscriber has to tell the
> intermediary that the subscription is changed and the publisher has
> to tell the intermediary there is a new pile of data being published.
> More to the point, the construction of the lookup tables in the
> intermediary have to change. Now there is coupling between three
> objects rather than two and the internals of three objects need to
> change rather than two.
Except there are no lookup tables and, except for Content-Based Routing which I have discussed previously, the intermediary doesn't look at the contents at all and does not have to change in any way for something like this.
In both the OO case and the publish/subscribe case, the developer has> to know what all the symbols mean and provide an implementation
> mechanism for connecting them all up.
One of the big difference here ... and one I know you hate ... is that the OO link is typically going to be composed of specific, typed arguments so any change in argument count or type is going to require touching all consumers while the MoM or ESB link is typically XML, a single blob, so one can freely add new elements to it and not disturb any consumer who does not need that element.
That mapping> mechanism enables the initialization of the routing lookup tables in
> the intermediary. However, it is exactly equivalent, in principle, to
> what the OO developer does when defining relationship navigation.
> That mapping is still identity coupling.
The two are quite different. For direct OO relationship connections, one needs navigate connections with matching signatures.
<aside author="H.S. Lahman" >
This is why I said to George that I think coupling is largely irrelevant at the OOA/D level. You already have a minimum coupling specification of the semantics in OOA/D. You depend on the OOP developer to do the right thing when implementing it. Shameless plug: And if you are a translationist, you don't care if there is lots of coupling at the 3GL level because you don't maintain the 3GL code; it gets regenerated automatically when the model semantics change. B-)
</aside>
AND
"No argument that, at the model level, one can't see any of this. It is a question of how one translates the model into an implementation." - Mercer-Hursh
That was the guidance I was looking for. "Data-Centric" architecture is just an architecture. It does not change the functional requirements. When functional requirements call for interaction between objects, we might apply different designs but the design choice does not change the functional requirement.
Methodology will have an overall practical impact. The elaboration advocates will strive to make the code match the model. They do this by necessity because they don't have a means, such as formal translations, to maintain traceability. They pay for it with some amount of obfuscation as the analysis model morphs to reflect the form of the design. If I were using elaboration, I'd probably make that trade-off. Since I'm using translation, I can keep the analysis model clear, concise and, because it is clear and concise, I can validate it and maintain it. (Eric Evins' Domain-Driven Design methodology is a really clear example of the elaboration approach).
I can now proceed with developing my translations with the confidence that the EUML/MBSE rules in the OOA/D model remain valid even if the architecture is "Data-Centric."
Thank you,Dan
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to umlforum+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
I can now proceed with developing my translations with the confidence that the EUML/MBSE rules in the OOA/D model remain valid even if the architecture is "Data-Centric."
In any publish/subscribe infrastructure, the subscriber needs to be> notified when a message of interest is placed on a queue. Otherwise,
> the subscriber is just polling a queue and it is not
> publish/subscribe. The most efficient way to do that is via a lookup
> table to address the notifications. (Not to mention that when the
> publisher adds a message, the intermediary needs to find the right
> queue address, based on message and publisher identity, to push the
> message.)
My point was that the connection is made entirely based on the channel, not anything to do with the message. In individual object pub/sub, one subscribes to an event on an object, but in MOM pub/sub, one publishes and subscribes to a channel and the subscriber receives all traffic on that channel.
Right. Then they can sit around and bemoan the fact that their> applications are difficult to maintain because there is a sea of
> global data floating around and nobody knows where and if it is
> actual being used. Developers who do things like that should have
> their thumbs broken. That sort of thing was a no-no in the '70s!
Obviously, one needs to do these things with discretion. While one clearly doesn't want one global message containing all information that anyone might want to use, one also doesn't want 79 different messages, each with a slight variation of the contents.
LOL. Really? The subscriber gets connected to the right queue by its> fairy godmother? There has to be an explicit identity mapping in the
> within the intermediary implementation to deal with the inherent *:*
> relationship between subscribers and publishers. Dealing with that
> *:* relationship is what publish/subscribe infrastructure does.
This is a design issue, not the MOM software looking at message contents. At design time one has a catalog of messages and channels and chooses the ones that one is interested in.
Both have to have exactly the same understanding of the> expected semantic data content and exactly the same understanding of
> what formatting conventions with be used at the implementation level
> (e.g., whether the publisher is silly enough to use XML).
Yes and no. This is where implementation matters. If one passes individual arguments in a message signature, then clearly everyone needs the same signature. If one passes an XML blob or an object, then each consumer merely needs to know how to extract the information it needs and doesn't care if there might be other information in there.
Everything /you /are talking about is low> level 3GL implementation in a particular computing environment. Here,
> though, none of that type system coupling is present and we see real
> minimum coupling. Hopefully, however the AAL is implemented will be
> the minimum possible coupling for the given environment.
No argument that, at the model level, one can't see any of this. It is a question of how one translates the model into an implementation.
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
umlforum+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "UML Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/umlforum/me_qFhetdXs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to umlforum+u...@googlegroups.com.
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
--- You received this message because you are subscribed to a topic in the Google Groups "UML Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/umlforum/me_qFhetdXs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to umlforum+unsubscribe@googlegroups.com.
I think the use of publish/subscribe should be determined by the> presence of one or both of two specific problem space requirements.
As a general principle, I agree, but with the qualification that these requirements tend to apply to many subsystem boundary communications (not all).
One is that publishers and/or suppliers can come and go. That's the> classic networking issue of who is available. The second is the
> situation is where there is a *:* relationship between potential
> subscribers and publishers where only one pair is linked at a time.
> This is the classic channel/port allocation situation that is also
> common in networking. Since those requirements are commonplace in
> distributed processing, it is not terribly surprising that
> publish/subscribe is an attractive implementation architecture for
> interprocess communication. But I don't see using it if publisher and
> subscriber are always around and always mate with one another.
The second seems not quite on to me since there is not really a one to one link made in a MOM. It is much more like a message is broadcast to a channel and whomever is listening to the channel gets the message without any direct connection being made. I.e., the sequence is publisher to channel, then channel to one or more subscribers, with no connection directly between publisher and subscriber.
"OK. But isn't that the assumption one always makes with distributed (external) bridges (i.e., the receiver can't know why it is getting the message; only what it should do with it)?" - H.S. Lahman
The receiver isn't getting a message at all but somehow knows that the observed object's attributes changed value. Could be polling or whatever. There is no indication of what the change means. I've understood the I'm Done message to relate to the behavioral contract. The I'm Done has some meaning in the context of that contract. For example, a clerk might not have a "busy" attribute but it might be required to signal when it is done being free or busy. Those two I'm Done signals would have different ids. In the DC system, I have to make a "busy" attribute.
DDS isn't a message passing mechanism. It distributes object attributes. The attributes of object A are available in object B execution environment within a specified time after changing. By delaying signals to B by that time, B can use the attributes as if A were local. A changes its attributes and sends "I'm done." The EUML VM holds the "I'm done," stops time, to let DDS do it's distributing. The EUML VM dispatches the "I'm done" event and object be uses object A's attribute values.
Obviously, this requires a global clock and relatively high quality communications. It works even in a real-time system as long as the domain latency tolerance is commensurate with the communications bandwidth.
Still, if I'm not allowed to use an "I'm Done" signal in the architecture. The restriction is going to bleed into the applicaiton domain and result in less clear requirements specification. Sigh.
--
--
You received this message because you are subscribed to the Google
Groups "UML Forum" group.
Public website: www.umlforum.com
To post to this group, send email to umlf...@googlegroups.com
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/umlforum?hl=en?hl=en
---
You received this message because you are subscribed to a topic in the Google Groups "UML Forum" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/umlforum/me_qFhetdXs/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to umlforum+u...@googlegroups.com.
I'm just skeptical that the GENERATE-less model will be easy to validate.