Re: [ebxmlms-develop] Setup of ApplicationContexts

[Patrick Y. <kc...@ce...>]

RE: [ebxmlms-develop] Setup of ApplicationContextsNull message listener =
sounds like desirable, but we have to think carefully about the =
consequence. One of the issues is when Hermes receives an error message =
referring to the sent message, how can Hermes deliver the error message =
to the correct client application. In the current case, Hermes relies on =
the AppContext of the sending Request object to deliver the error =
messages. We will discuss about it next week.

Regards, -Patrick
  ----- Original Message -----=20
  From: Mayne, Peter=20
  To: 'ebx...@li...'=20
  Sent: Friday, March 28, 2003 11:30 AM
  Subject: RE: [ebxmlms-develop] Setup of ApplicationContexts


  >> However, consider the situation where Hermes is running on a server =
in a DMZ, and the listener is=20
  >> running on a different server in the internal network. There's =
definitely no way to control the load=20
  >> sequence then.=20
  >=20
  > In that case, manual procedure in system maintenance should be =
enforced. An analogy is that you have=20
  > to start up DB server before app server. There should be a startup =
procedure which the sequence is=20
  > significant.=20

  I'm not greatly worried by this: once the registration has happened, =
it sticks forever, and it isn't that hard to run the listener at least =
once while Hermes is running. :-)

  > Under the current architecture, you have to use an AppContext which =
is never be used in a real message=20
  > for sending.=20

  Ugh. Can this please be changed? Or can I create an =
ApplicationContext(null, null, null, null) that doesn't match any other =
ApplicationContext? Hmm, no, the constructor throws a =
NullPointerException at the cpaId.toCharArray(), and equals() wouldn't =
work either, and the MSHConfig table doesn't allow nulls in c_cpaid.

  What effect does specifying a null MessageListener to the Request =
constructor have?=20

  PJDM=20
  --=20
  Peter Mayne=20
  Technology Consultant=20
  Spherion Technology Solutions=20
  Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602=20
  T: 61 2 62689727  F: 61 2 62689777=20

The information contained in this email and any attachments to it:

(a) may be confidential and if you are not the intended recipient, any =
interference with,=20
use, disclosure or copying of this material is unauthorised and =
prohibited; and

(b) may contain personal information of the recipient and/or the sender =
as defined=20
under the Privacy Act 1988 (Cth). Consent is hereby given by the =
recipient(s) to=20
collect, hold and use such information and any personal information =
contained in a=20
response to this email, for any reasonable purpose in the ordinary =
course of=20
Spherion's=20
business, including forwarding this email internally or disclosing it to =
a third party. All=20
personal information collected by Spherion will be handled in accordance =
with=20
Spherion's Privacy Policy. If you have received this email in error, =
please notify the=20
sender and delete it.

(c) you agree not to employ or arrange employment for any candidate(s) =
supplied in=20
this email and any attachments without first entering into a contractual =
agreement with=20
Spherion. You further agree not to divulge any information contained in =
this document=20
to any person(s) or entities without the express permission of Spherion.