Prev: just say NO to inline SQL
Next: attn: morty - inspiring movies - geh memco - (1/1)
From: John Carter on 18 Feb 2007 17:14
Ever had a problem of two classes / frameworks/ packages / systems....
that have to be coupled in someway.

Info has to pass between the two.

So the obvious gets done and one side or the other gets to use a rich fat
object from the the other side. And WOW! Oh the PAIN! The two sides are
now deeply and horribly coupled by all the things that rich fat object
depends upon.

Often you can't even compile the ruddy thing!

At that point some bright soul steps forward and says, its the problem of
having the rich fat object. Reduce the information to a simple neutral
format like a number, string, a CSV file an XML file and we're done.

Grreat. Now we're making fast progress. We can unit test we can validate
the xml we can do Good Things. That worked, we decoupled the two systems.

Did we?

Then why during the maintenance phase do we have all kinds of issues
relating ...
* Semantics - (What exactly did that field mean again?)
* Currency - (You changed something? Why didn't you tell us?)
* Encapsulation - (You added something, I don't care why, it broke my
stuff. Pull it out!)
* Duplication - Why are we writing this data encoder / decoder stream
twice?

Oh dear. Maybe a neutral format wasn't so good after all.

Perhaps we needed a middle ground. A slim interface object that just
carried, owned and understood the data required. Maybe the Rich Smart
object should use/hold/reference one of these to it's version of the info.

We've lost something now. The pretty human readable text view. The ability
to time wise decouple things by having the XML on disk. No problem, let
the small slim interface object (de)?serialize itself using CSV/XML/....

ie. Neutral Interface Formats aren't Naked. They have Invariants, they
have life cycles, they ownership, upgrade and maintenance issues. They
should be small standalone, very few dependencies, very reusable
objects/components in their own right.

--


John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter(a)tait.co.nz
New Zealand


From: Nick Malik [Microsoft] on 19 Feb 2007 10:11
Good observations, John. I agree that the data binding between two
frameworks should be
- managed
- versioned
- declared

In the messaging world, this concept is well understood to be true. I
believe you are talking about the OO world of API calls, right? If so, I
agree that the same concept should be emphasized in that space as well.

Question: does the Data Transfer Object pattern cover sufficient portions of
your concerns to be a good starting place for describing the solution?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"John Carter" <john.carter(a)tait.co.nz> wrote in message
news:pan.2007.02.18.22.14.49.835236(a)tait.co.nz...
> Ever had a problem of two classes / frameworks/ packages / systems....
> that have to be coupled in someway.
>
> Info has to pass between the two.
>
> So the obvious gets done and one side or the other gets to use a rich fat
> object from the the other side. And WOW! Oh the PAIN! The two sides are
> now deeply and horribly coupled by all the things that rich fat object
> depends upon.
>
> Often you can't even compile the ruddy thing!
>
> At that point some bright soul steps forward and says, its the problem of
> having the rich fat object. Reduce the information to a simple neutral
> format like a number, string, a CSV file an XML file and we're done.
>
> Grreat. Now we're making fast progress. We can unit test we can validate
> the xml we can do Good Things. That worked, we decoupled the two systems.
>
> Did we?
>
> Then why during the maintenance phase do we have all kinds of issues
> relating ...
> * Semantics - (What exactly did that field mean again?)
> * Currency - (You changed something? Why didn't you tell us?)
> * Encapsulation - (You added something, I don't care why, it broke my
> stuff. Pull it out!)
> * Duplication - Why are we writing this data encoder / decoder stream
> twice?
>
> Oh dear. Maybe a neutral format wasn't so good after all.
>
> Perhaps we needed a middle ground. A slim interface object that just
> carried, owned and understood the data required. Maybe the Rich Smart
> object should use/hold/reference one of these to it's version of the info.
>
> We've lost something now. The pretty human readable text view. The ability
> to time wise decouple things by having the XML on disk. No problem, let
> the small slim interface object (de)?serialize itself using CSV/XML/....
>
> ie. Neutral Interface Formats aren't Naked. They have Invariants, they
> have life cycles, they ownership, upgrade and maintenance issues. They
> should be small standalone, very few dependencies, very reusable
> objects/components in their own right.
>
> --
>
>
> John Carter Phone : (64)(3) 358 6639
> Tait Electronics Fax : (64)(3) 359 4632
> PO Box 1645 Christchurch Email : john.carter(a)tait.co.nz
> New Zealand
>
>


From: H. S. Lahman on 19 Feb 2007 15:21
Responding to Carter...

> Ever had a problem of two classes / frameworks/ packages / systems....
> that have to be coupled in someway.
>
> Info has to pass between the two.
>
> So the obvious gets done and one side or the other gets to use a rich fat
> object from the the other side. And WOW! Oh the PAIN! The two sides are
> now deeply and horribly coupled by all the things that rich fat object
> depends upon.
>
> Often you can't even compile the ruddy thing!

Right. Don't Do That. Object references totally trash encapsulation
because the object exposes part of the sending subsystem's
implementation. (There wouldn't be a reference to pass if the object
wasn't needed to implement the sender subsystem.) There are potentially
unlimited and unexpected side effects for both sender and receiver.

> At that point some bright soul steps forward and says, its the problem of
> having the rich fat object. Reduce the information to a simple neutral
> format like a number, string, a CSV file an XML file and we're done.
>
> Grreat. Now we're making fast progress. We can unit test we can validate
> the xml we can do Good Things. That worked, we decoupled the two systems.
>
> Did we?

That depends. The mechanics (e.g., XML) are not very important compared
to using a pure message paradigm: {message ID, <by-value data packet>}.
That greatly reduces the coupling. But there is no way to eliminate it
completely. There is going to be coupling any time information is
passed. [Among other things there is an inherent timeliness issue: is
the data still valid by the time the receiver processes it? It may not
be if the subsystem interface serializes through a queue.]

>
> Then why during the maintenance phase do we have all kinds of issues
> relating ...
> * Semantics - (What exactly did that field mean again?)

Both sides interpret the message in terms of their own context. To do
that both sides must share the definition of the message itself. That
definition defines the semantics of the just the data packet. Thus
field 3 in the message is a voltage in millivolts expressed as a double
precision floating point number. But the sender may interpret that as a
"pin 5 bias" while the receiver may interpret it as an "channel 16 offset".

IOW, there is a difference between the semantics of the message and the
semantics of the subsystem subject matter. At some point these views
still need to be coordinated so that the mapping between subsystem
subject matters through the message is correct. But that is a problem
for the developers of each subsystem when negotiating the interface.
That represents a solution level (Systems Engineering level, if you
will) coupling but at least it is very narrowly focused on the message
definition rather than what each side does with the information. IOW, it
is a lot easier to negotiate

sender semantics -> message semantics -> receiver semantics

than

sender semantics -> receiver semantics.

because the level of abstraction of the message is higher.

> * Currency - (You changed something? Why didn't you tell us?)

That is not a problem for the message definition. Rather it is a problem
for When the interface is invoked. Currency is, indeed, a level of
coupling that can go wrong even for a message with no data packet at
all. But it is also about as benign as coupling can be. One way to
classify the intimacy of coupling in ascending order is:

message w/o data packet. Currency is the only thing that can go wrong.
The sender can't be directly hurt and the receiver in unlikely to be
permanently hurt, but the receiver can spin wheels. [What the receiver
does is out of synch in the solution, but that was already true as soon
as the message was sent at the wrong time. IOW, the solution was out of
synch as soon as the sender sent the message.]

message w/ by-value data. Add the timeliness and consistency of the data
as something that can go wrong. The sender can't be directly hurt but
the receiver may produce incorrect results. Still pretty benign and
readily controllable.

message w/ data by reference. Add the fact that the receiver can modify
the data values the sender uses without the sender knowing or expecting
it (aka the Global Data Syndrome). This starts to get potentially nasty
because the data is part of the sender's implementation and
encapsulation has been broken.

message w/ behavior (e.g., Java applets). Now the applet can do
unexpected things to the receiver. That is, the sender can modify the
receiver in ways the receiver neither knows about nor expects. This is
really nasty, as any web security guru can testify.

message w/ object references. The worst because the receiver can trash
the sender's data and the behaviors can trash the receiver. In addition
the receiver has access to /all/ of the object properties, not just the
ones the sender expects to be accessed. A veritable Pandora's Box of
unlimited side effects for both sender and receiver.

<aside on the human condition>
We don't seem to learn from past mistakes. Decades ago there was a
language called Forth that essentially allowed the code to modify itself
as it was executing. Like FORTRAN's assigned GOTO, that was one of those
things that seemed like a good idea at the time but turned out to be a
Really Bad Idea. By the late '80s even suggesting using Forth was
grounds for summary dismissal in some shops. Yet within a few years that
hard-won lesson was lost and people started passing Java applets around
indiscriminately.

Similarly, back in the '50s and early '60s markup and scripting
languages were very popular. But by the early '70s they were largely
abandoned because of reliability and maintainability problems. But in
the late '80s they were reborn with a vengeance because interoperability
was needed and the Hardware Guys couldn't standardize things like endian.

So now we get to wonder (A) why we need a desktop today with more power
than a 1984 mainframe to run a spreadsheet that ran just fine on a
TRS-80 in 1984, (B) why the order entry forms on the web are always
breaking, and (C) why some OO applications are much more unreliable than
one would expect (i.e., those passing object references around).
</aside on the human condition>

> * Encapsulation - (You added something, I don't care why, it broke my
> stuff. Pull it out!)

To do that in a pure by-value message interface, one must change the
interface definition. That will usually result in rude comments by the
compiler if both sides aren't privy to it. So it is a problem but there
are pretty good safeguards available in the development process.

> * Duplication - Why are we writing this data encoder / decoder stream
> twice?

I'm afraid don't follow. The encode is done once on the sender side and
the decode is done once on the receiver side for each message.

If you mean that every message needs to be both encoded and decoded,
then that is the price of decoupling so that each side can map the
common message definition into its own semantics. The encode/decode is
essentially a mapping function from the local subject matter context to
the common message definition context. The encode/decode may be tedious
but it usually isn't rocket science. Better to provide semantics
mappings in a simple, mechanical way than in a complex, case-by-case way.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



From: AndyW on 20 Feb 2007 00:08
On Mon, 19 Feb 2007 11:14:53 +1300, John Carter
<john.carter(a)tait.co.nz> wrote:

>Ever had a problem of two classes / frameworks/ packages / systems....
>that have to be coupled in someway.
>
>Info has to pass between the two.
>
>So the obvious gets done and one side or the other gets to use a rich fat
>object from the the other side. And WOW! Oh the PAIN! The two sides are
>now deeply and horribly coupled by all the things that rich fat object
>depends upon.
>
>Often you can't even compile the ruddy thing!
>
>At that point some bright soul steps forward and says, its the problem of
>having the rich fat object. Reduce the information to a simple neutral
>format like a number, string, a CSV file an XML file and we're done.
>
>Grreat. Now we're making fast progress. We can unit test we can validate
>the xml we can do Good Things. That worked, we decoupled the two systems.
>
>Did we?
>
>Then why during the maintenance phase do we have all kinds of issues
>relating ...
> * Semantics - (What exactly did that field mean again?)
> * Currency - (You changed something? Why didn't you tell us?)
> * Encapsulation - (You added something, I don't care why, it broke my
> stuff. Pull it out!)
> * Duplication - Why are we writing this data encoder / decoder stream
> twice?
>
>Oh dear. Maybe a neutral format wasn't so good after all.
>
>Perhaps we needed a middle ground. A slim interface object that just
>carried, owned and understood the data required. Maybe the Rich Smart
>object should use/hold/reference one of these to it's version of the info.
>
>We've lost something now. The pretty human readable text view. The ability
>to time wise decouple things by having the XML on disk. No problem, let
>the small slim interface object (de)?serialize itself using CSV/XML/....
>
>ie. Neutral Interface Formats aren't Naked. They have Invariants, they
>have life cycles, they ownership, upgrade and maintenance issues. They
>should be small standalone, very few dependencies, very reusable
>objects/components in their own right.

I might suggest that when I have two systems that need joining
together I will normall use a middleware package (such as CORBA) that
is designed for supporting disparate systems.
----------------
AndyW,
Mercenary Software Developer
 | 
Pages: 1
Prev: just say NO to inline SQL
Next: attn: morty - inspiring movies - geh memco - (1/1)