MHonArc v2.5.0b2 -->
ebxml-msg message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [ebxml-msg] Multiple handlers
Duane Nickull's Question:
I reviewed the specification and did not find an answer to this
question.Is there anything in the ebXML MS spec that says a MS
implementation MUST be capable of supporting multiple HTTP listeners?
DaleMoberg> Do you mean anything that implies that a MSH MUST handle
multiple URLs? I don't think so. I guess you could set it up so that all
messages from all parties to all parties (handled by the MSH) use the
same URL. Not a very REST-friendly constraint, but permissible.
However, using distinct URLs as initial screening on routing/processing
might be useful. It could be conducive to scaling up to a cluster of
servers, with different servers configured for different jobs. And so
on. I would certainly argue against stipulating that a single MSH MUST
use exactly one URL per MSH. That would be a repressive constraint IMO
that would unduly restrict implementation and design choice.
Duane continues:
CPA allows there to be multiple listeners/transport endpoints listed for
MSH's that may have more than 1 endpoint. Does this seem logical or is
it a potential misalignment of the specifications.
DaleMoberg> I don't know if it is "logical" or not but it allows a lot
more freedom in configuring a MSH, and using URLs to partition in
accordance with resources or whatever. RESTifarians find it "logical"--
even the true "Tao of Web"; other people like to throw everything into
one hopper and then struggle to figure out how to demultiplex. CPPA
tries to accomodate both ends of the spectrum. I don't think there is
any misalignment so far. Unless Messaging tries to stipulate which way
to go, I think they are compatible. Personally I favor a tolerant
framework that allows both styles.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]