[
Lists Home |
Date Index |
Thread Index
]
Alessandro Triglia wrote:
...
If you have the following type definition:
--------------------------------------------------
PersonInformation ::= SEQUENCE {
name UTF8String,
age [ATTRIBUTE] INTEGER OPTIONAL,
age-elem [NAME AS "age"] INTEGER OPTIONAL,
address UTF8String,
...
}
--------------------------------------------------
the ellipsis ("...") indicates a position in the sequence (usually but not
necessarily at the end) where an "addition" may occur.
A writer may add stuff after the "address" field. PER wraps the stuff and
adds a length prefix right before it. A reader will be able to either
decode the stuff (if he thinks it understands it) or skip it. If a reader
decides to relay the message, it can re-include the wrapped stuff in the
message, whether or not it understands the stuff.
Without the ellipsis, it is forbidden to add anything after the address.
With the ellipsis, the wrapping mechanism ensures that any addition will be
recognized as such, whether or not it is understood.
That's cool, but I still don't understand how fields are identified in
a way that is usable and supportable in other than tightly coupled
environments. (Where tightly coupled includes standards like H.323,
SS7, cell networks, etc.)
If there exists an application as above and it is receiving messages
from multiple parties, say many different schools submitting graduation
records. What if one school adds a height field and another adds a
languages field? This interface can see those fields without confusion
and pass them on to another tier? Is there a way for this tier to
interpretively process those fields in a coherent way?
I think that you've shown that a receiver can handle extensions from
the one changer of formats which helps with schema evolution to some
degree, but it still doesn't seem like loose coupling.
...
<Sigh> Make that "ASN.1 + xER + existing implementations".
Message format + semantic sugar = API or Message format +
protocol + semantic sugar = API Standard message format
implies standard API Standard API does not imply standard API.
Sorry, I still don't get it. An API is not the same thing as a data type.
Why do you think they are the same thing?
Alessandro
A "remote procedure call" is the transfer of a message with associated
semantics that map that message to a method or method stub and return
the results with an associated semantic. A "protocol" is the transfer
of messages with a certain semantic where the processer of messages may
eventually call a method. Although distinct models, they aren't
necessarily that far apart semantically. Even a local method
invocation can be represented as a pair of messages. Some paradigms
extend this: SQL servers generally receive a single request and may
respond with any number of responses. SOA methods like message
passing/oriented point to point and publish/subscribe have much more
rich possible communication patterns.
To be clear, you can have data types that are just data types such as
"Person" and data types that represent an RPC/message of some type such
as: NewPerson{ Person np }, NewPersonReponse{ ID newid, Success ok }.
It's better to define the message traffic, ok to define the protocol
also, and marginally useful to describe the 2GL API.
sdw
--
swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw
|
begin:vcard
fn:Stephen Williams
n:Williams;Stephen
email;internet:sdw@lig.net
tel;work:703-724-0118
tel;fax:703-995-0407
tel;pager:sdwpage@lig.net
tel;home:703-729-5405
tel;cell:703-371-9362
x-mozilla-html:TRUE
version:2.1
end:vcard
|
