Menu
▾
▴
Re: [ebxmlms-develop] CertResolver questions
|
From: Patrick Y. <kc...@ce...> - 2003-06-11 10:30:27
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<title></title>
</head>
<body>
<blockquote type="cite"
cite="mid...@s-...">
<div><span class="653165205-11062003"><font face="Arial" size="2">Because
if I only require static registration, there's a whole bunch more
Hermes code I have to look through to figure out how to do it, and
it's not easy at the moment. More code means more complicated, harder
to maintain, and less reliable.</font></span></div>
<div><span class="653165205-11062003"></span></div>
</blockquote>
<br>
So, will you be more comfortable if there are "Hermes - ASP Mode
Edition" and "Hermes - Standalone Mode Edition"? :-)<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="653165205-11062003">You've
made the listener (potentially) slightly less complicated at the
expense of making Hermes a lot more complicated.</span></font></div>
</blockquote>
To "make the listener (potentially) slightly less complicated" is only
part of the reason. Please note again that not all use cases can be
done with a global listener.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="653165205-11062003">The
listener has to dispatch the message anyway: in my case, it puts all
messages on a JMS queue. Now, suppose I want to put messages on
different queues (for different departments), depending on the
service/action? I can:</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">(a) register
several different listener instances, each with a different
configuration to tell it which queue to put the message on, and get
Hermes to deliver messages to those different instances.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">(b) register
one listener instance with a single configuration and a decision table
with a single configuration.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">I'll
go with (b) every time, even given the (a) option. In fact, I do:</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">(c)
register one listener instance that puts all messages on a single JMS
queue; a service on the other end of the queue gets the messages and
does slightly different things depending on the action.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">If
I did this by registering a different listener for each action, it
would end up being more complicated and harder to manage! :-)</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font><font
face="Arial" size="2"><span class="653165205-11062003"></span></font> <br>
</div>
</blockquote>
I understand your (i.e. standalone mode) use case.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="653165205-11062003">My
single listener can be more flexible: what if I want all purchase
orders where FromPartyId="CECID" to be dealt with by our express
orders department? The ApplicationContext can't do that, because it
doesn't look at FromPartyId, whereas a listener can.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font></div>
</blockquote>
As I said, we have CPPA concepts in our mind when doing the design. We
found that CPA_ID would imply FromPartyID & ToPartyID. So, we don't
use From/To PartyID as the decision keys.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div> <font face="Arial" size="2"><span class="653165205-11062003">Most
importantly, I don't think it is Hermes' job to do finer
categorisation. As you've implied above, by allowing the MSH to decide
where to deliver the message to, you're entangling the MSH with the
company's internal business process, and I don't think that's right.
The MSH should just deliver the message, and let the business process
in or behind the listener decide what to do with it (as in (b) or (c)
above). I *really* don't want a piece of software that lives in the
DMZ making business process decisions that should be made internally.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> <br>
</div>
</blockquote>
An analogy is email server. A traditional business process may involve
different people from different departments. Sometimes you need to talk
to outside world. And the outside world will send emails to specific
departments during the process. Upon receiving the emails from outside,
the email server has to dispatch the messages to each person's mailbox.
The decision is based on the email address. This is the same as Hermes
to dispatch the messages to each application, basing on the AppContext.<br>
<br>
Hmm, email server is placed in the DMZ, right?<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div><font face="Arial" size="2"><span class="653165205-11062003">This
is why I disagree with the idea that it is more reasonable to deliver
messages to applications using the ApplicationContext. Different
service/action handling by different routines *is* reasonable, but the
MSH shouldn't be making that decision.</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">A
company large enough to have different departments and flexible enough
to be using an open source MSH isn't going to have any problems
writing a listener that can do different service/action handling. :-)</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">So,
why don't I just register my clever listener
with ApplicationContext("*","*","*","*"), and forget about the rest?
Because as I said above, this part of Hermes is already too complicated,
and you're considering making it even more complicated (two kinds of
registration, another authorisation scheme), and therefore less
reliable and harder to maintain. That's important in an open source
product. :-)</span></font></div>
<div><font face="Arial" size="2"><span class="653165205-11062003"></span></font></div>
</blockquote>
I know we may be aiming too high. :-) But at least the ASP mode use
case is possible for small companies as well.<br>
<br>
<blockquote type="cite"
cite="mid...@s-...">
<div> </div>
<div><font face="Arial" size="2"><span class="653165205-11062003">But
you're saying here that the need for a CertResolver depends on the
presence or absence of a certificate in a message, not on an
ApplicationContext, and I agree with that. Therefore, why would
different CertResolvers be needed for different ApplicationContexts?</span></font> <br>
</div>
</blockquote>
If the certificates of all clients will be stored in a centralized
place, e.g. a centralized keystore, it's ok to have a global one. But
if the certificates are to be managed by the applications in a
distributed way, the CertResolver implementation will be different for
different applications.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
</body>
</html>
|
