|
From: Ronald v. K. <rv...@ab...> - 2003-07-10 09:36:11
|
I agree it is diffucult (and don't appologize for your English... mine
is probably even worse ;-))
-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: donderdag 10 juli 2003 11:09
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0: sync reply
Agreed to implement sync reply. It's a bit complicated. Let me try to
explain the difficulties here... (please bear with my poor English)..
When Hermes is the sending out message, it normally will wait for the
HTTP response code. In case of the response message coming from the same
HTTP connection, Hermes can now handle it.
When Hermes is receiving messages, by the current implementation, it
will close the HTTP connection after all data from the message has been
read. So, to implement sync reply, we should keep that connection in
memory without closing it. To be precise, there will be a mapping of
AppContext and HTTP connection kept in memory.
[Ronald van Kuijk]
The AppContext? Should'n it be a reference to this specific message?
Whenever the application command to send out a message, that mapping is
being looked up to see any opened HTTP connection ready to use. If there
is one, Hermes should use that HTTP connection to send out the message.
If not found, Hermes should open a new connection.
Here is the difficult part: when should we close that connection? Oh
yes, that should be controlled by a CPA parameter: syncReplyMode. The
possible values are mshSignalsOnly, signalsOnly, responseOnly,
signalsAndResponse, none.
Easy for mshSignalsOnly. Since those ACKs are generated by Hermes, after
those ACKs has been sent, Hermes can then close the connection.
For signalsOnly, responseOnly and signalsAndResponse, Hermes has no idea
about when to close the connection. The reason is Hermes does not know
the message being sent is actually a signal or a response.
Our conclusion is, it is hard to manage the keep alive connection if
Hermes doesn't know about the business process.
[Ronald van Kuijk]
I agree. Isn't the there a SyncReply timeout in the CPA e.g. 8.4.14.10:
8.4.14.10 timeToPerform attribute
The timeToPerform attribute is of type duration [XMLSCHEMA-2]. It
specifies the time period,
starting from the initiation of the RequestingBusinessActivity, within
which the initiator of the
transaction MUST have received the response, i.e., the business document
associated with the
RespondingBusinessActivity.
NOTE: The timeToPerform attribute associated with a BinaryCollaboration
in BPSS is
currently not modeled in this specification. Therefore, it cannot be
overridden. In other
words, the value specified at the BPSS level MUST be used.
When synchronous reply mode is in use (see Section 8.4.23.1), the
TimeToPerform value
SHOULD be used as the connection timeout.
Again, it seems the MSH should have knowledge of the CPA.
Any comments?
[Ronald van Kuijk]
hth
Cheers, -Patrick
Ronald van Kuijk wrote:
Yes, but can the response come from an application or only acks/errors .
The last is currently the case or am I wrong?
Ronald
-----Oorspronkelijk bericht-----
Van: Mayne, Peter [ mailto:Pet...@ap...
<mailto:Pet...@ap...> ]
Verzonden: donderdag 10 juli 2003 0:36
Aan: ' ebx...@li...
<mailto:ebx...@li...> '
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0: sync reply
If I send a message over HTTP with SyncReply set, Hermes will send a
response back using the same HTTP connection. Is this what you mean, or
am I confused?
PJDM
--
Peter Mayne
Technology Consultant
Spherion Technology Solutions
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602
T: 61 2 62689727 F: 61 2 62689777
> -----Original Message-----
> From: Ronald van Kuijk [ mailto:rv...@ab... <mailto:rv...@ab...>
]
> Sent: Wednesday, 9 July 2003 7:14 PM
> To: ' ebx...@li...
<mailto:ebx...@li...> '
> Subject: RE: [ebxmlms-develop] Hermes 1.0: sync reply
>
>
> I didn't really look into this, but afaik SyncReply is not
> implemented.
> To be able to use hermes in a web-service (RPC?) like fashion, I think
> we should implement this (in a plugable way) as wel.
>
> Ronald
>
> > -----Oorspronkelijk bericht-----
> > Van: Patrick Yee [ mailto:kc...@ce...
<mailto:kc...@ce...> ]
> > Verzonden: dinsdag 8 juli 2003 10:32
> > Aan: ebx...@li...
<mailto:ebx...@li...>
> > Onderwerp: [ebxmlms-develop] Hermes 1.0
> >
> >
> > Dear all,
> >
> > I drafted a document, which describe the area we may need to
> > re-engineer
> > and the features we want to have in the 1.0 version. Please comment.
> >
> > Regards, -Patrick
> >
>
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,
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
under the Privacy Act 1988 (Cth). Consent is hereby given by the
recipient(s) to
collect, hold and use such information and any personal information
contained in a
response to this email, for any reasonable purpose in the ordinary
course of
Spherion's
business, including forwarding this email internally or disclosing it to
a third party. All
personal information collected by Spherion will be handled in accordance
with
Spherion's Privacy Policy. If you have received this email in error,
please notify the
sender and delete it.
(c) you agree not to employ or arrange employment for any candidate(s)
supplied in
this email and any attachments without first entering into a contractual
agreement with
Spherion. You further agree not to divulge any information contained in
this document
to any person(s) or entities without the express permission of Spherion.
------------------------------------------------------- This SF.Net
email sponsored by: Parasoft Error proof Web apps, automate testing &
more. Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
|