23 April 1997
15-675
the story so far...
BUT
there are multiple standards (ActiveX, OpenDoc, Corba, ...)
a standard may not suit your architectural needs
legacy components don't uphold the standard
what happens when components weren't made to be used together?
interaction mechanisms vary
database schemas vary
communication protocols vary
packaging mismatch
it makes about interacting with the outside worldwhen those assumptions aren't upheld during integration,
you have packaging mismatch
quick aside: don't get hung up on terminology
interface mismatch -- Wallnau &al
packaging mismatch -- DeLine
today's discussion
Yellin & Strom -- fixing mismatches in method call protocols
a new approach
Purtilo & Atlee : the problem
the number or types of the arguments
void open_window(int x, int y, int width, int height) { ... }
open_window(600,480);
typedef struct { char *name, *address; } label;
void print_envelope (label l) { ... }
typedef struct { int len; char *storage; } string;
typedef struct { string name, SSN, address; } person;
person p;
print_envelope (p);
Purtilo & Atlee : the solution
2 describe data format of definer's args
3 show how to satisfy definer's args with callers' args
caller: w:int; h:int
definer: int; int; int; int
map: int(`20'); int(`50'); w; h
caller: { { int; n:^char }; { int; ^char }; { int; a:^char } }
definer: { ^char; ^char }
map: { n; a }
Purtilo & Atlee : the solution
Yellin & Strom : the problem
to be called in some ordere.g. a File object: open
an illegal order: open
Yellin & Strom : example server object
Receive messages {
bid (bidderId:id, itemBiddingOn:string, amount:real);
updateAck();
}
Send messages {
newItem (itemDescr:string, bidderId:id);
update (highBid:real);
rejectBid (reason:string);
acceptBid();
itemSold();
};
...
}
Yellin & Strom : example client object
Recieve messages {
auctionBegin (auctionInfo:string);
canBid (bidId:id);
cannotBid (why:string);
newHighBid (price:real);
bidOk();
bidNotOk();
gavel();
};
Send messages {
requestToBid (name:string,
bidItem:string);
newBid (bidItem:id, myBid:real);
highBidAck();
};
...
}
Yellin & Strom : the mismatch
Yellin & Strom : solution
that makes up the differences<A,1>: +newItem from auctioneer
write(itemDescr, bidderId);
<B,1>: -auctionBegin to bidder
auctionInfo = Cells.itemDescr,
invalidate(itemDescr);
<B,2>: +requestToBid from bidder
write(bidItem);
<B,2>: +update from auctioneer
write(highBid);
<B,3>: -canBid to bidder
bidId = Cells.bidderId,
invalidate(bidderId);
<B,4>: +update from aucitioneer
write(highBid);
two paths for touring techniques
datatype representation, ADT representation
database views
document formats, file formats
"carrier" aspects of interaction (transfer or communication rules)
parameter passing
method invocation protocols
message formats
"trigger" aspects of interaction
internal vs external control, push vs pull
synchronous vs asynchronous
how much variation in interaction the component provider accounts for
i.e. how big is component's "envelope of variability?"
no envelope of variability
wrap the component
hardware emulator [instruction set]
Word for Word and its ilk [document format]
PC Exchange and its ilk [disk format]
Purtilo & Atlee [parameter passing]
Yellim & Strom [method protocol]
"small" envelope of variability
use provided selection method to choose from
component's set of possibilities
fat binaries [instruction set]
OLE interface negotiation [API]
"medium" envelope of variability
choose combination from component's set of possibilities
procedures with keyword parameters [parameter passing]
"big" envelope of variability
use component's programmable interface
MS Word converter plugins [document representation]
what techniques have I missed?
an example from Kevin Sullivan
how to cope?
he'd have to repeat this effort for each new version of the Unix filter
use a separate design artifact to capture concrete interaction details
compile the two together to get final component