Re: [ebxmlms-develop] CertResolver questions

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

<!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>Multiple
email converations at once...</div>
</blockquote>
 
Why? In single-client mode (as I'm currently
doing), dynamic registration isn't required, and is actually a pain.
In ASP mode, if you allow dynamic registration, you have to come up
with a mechanism to stop the clients registering arbitrary
ApplicationContexts, as you said, and that makes things even more
complicated. I would do away with dynamic registration altogether. 
 
If you are using single-client mode, static registration is enough,
then why painful? 
I still think dynamic registering is more flexible. For example, if we
are going to build a upper layer software on top of Hermes to handle BP
issues, and probably we will be using ebXML CPPA. There may be a
interface to deploy CPA files and it will do registration to Hermes
dynamically. If Hermes only supports static registration, the
deployment of CPA will include automatic modification of the properties
file (and restart Hermes, of course we can make Hermes re-read the
properties file regularly, but is it getting complicated again?). In
this case, I think dynamic registration is better. 
 
<blockquote type="cite"
 cite="mid...@s-...">
 <div>To rephrase my response, I think this is adding
far too much complication. To do this, you have to maintain a
server-side database mapping clients to the ApplicationContexts that
they're allowed to use. In other words, you're creating a static
registration database, but you want the clients to dynamically register
as well, and/or you want to invent a new more sophisticated (read
"more complicated") authentication mechanism! Gulp!</div>
</blockquote>
Agree that it is complicated, and I understand your concern. But why
don't we think of a more acceptable mechanism if it is that complicated? 
 
How did you come up with registering by
CPA+conversation+service+action? 
 
<big>In early versions of Hermes, ToPartyId has to be always the MSH
endpoint. So we need another key to deliver messages. Anyway, even in
current case, it is more reasonable to dispatch messages to
applications using AppContext, as different service/action handler by
different routines are reasonable. In spec, PartyID is inherited from
CPA, which is generally used to identify an organization. What if (ASP
mode again), a company installed one Hermes, and different departments
are using it and they are responsible for different parts of a business
process? (Thus, they are responsible for different service/action, and
thus different AppContext). In this case, the ToPartyID is probably the
name of the company. I know a single receiver like what you are doing
can always solve the problem, but what are the problems if we can do a
finer categorization in an earlier stage? We can make the application
simpler, at least don't have to dispatch the message, by doing this
kind of registration. 
 
In view of all these, we think within all the header fields of an ebXML
message, those 4 are the best candidate for dispatching messages. 
 
</big>There isn't a problem (I think) with
sharing CertResolver's certificates amongst clients, so there's no
point making it ApplicationContext-specific. 
 
It may not be a problem with sharing certificates. But
the incoming messages may be coming from different senders (in ASP
mode, different senders send to different receiving applications,
determined by different AppContext). Different senders may use
different brands of MSH. Some may include a cert in the message, which
do not need a CertResolver. Some may not include a cert in the message,
which need a CertResolver. That's the point to call up different
CertResolver depending on AppContext. 
 
Regards, -Patrick 
 
</body>
</html>