RE: [ebxmlms-develop] Hermes 1.0 my remarks

[Ronald v. K. <rv...@ab...>]

I wouldn't put jms forward as the 'single' option, sorry... I agree that
for smaller systems probably do not have it, but the switch from tomcat
to jboss is small one.
 
I agree with the CPA/parameter remarks though... I'venot done that much
with CPA's yet, so didn't think of that
 
Ronald

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: woensdag 9 juli 2003 3:55
Aan: 'ebx...@li...'
Onderwerp: RE: [ebxmlms-develop] Hermes 1.0 my remarks


(Server side delivery mode)
 
- Shouldn't all (server side ones) implement the same interface
(onMessage()?) and File and URL just be some default included
implementations? (Isn't this also a 'hook'?)
 
I was thinking exactly the same thing. :-) There should be only one
server-side mode, with a trusted repository and URL redirect provided as
implementations of that mode. If "customised mode" isn't good enough to
implement trusted repository or URL redirect, then it probably isn't
good enough for much else either.
I'd vote for a jms implementation to and volunteer to implement one

I've done a JMS implementation, which is what sparked some of the
discussion about delivery modes. However, including it with Hermes may
be problematic: since JMS isn't part of the standard JRE, it would not
be possible to build Hermes unless you had a JMS implementation. Maybe
we could have a "contributions" library.
 
Registration

Addition: Static registration, with a registrationresolver hook (we want
an ldap implementation, hell we want ldap for everything :-) )

Static registration has been discussed as well. I'm surprised not to see
it mentioned here. (Although it may be implied in "For sending out
messages, there is no need to register".) I totally agree with this, and
having just set up OpenLDAP yesterday, I'm all for LDAP as well. :-)

 

 Registration specifies which types of messages are to be received

Isn't it a little to much to have al these kind of messages through all
kinds of different channels? I'd let that be the responsibility of the
application. It can receive all messages on one channel and it should
itself take care of the rest.

There's been some discussion about this kind of thing on the list. I
think the summary is (someone stop me if I'm wrong) that the CECID view
is that Hermes should do as much as possible, to avoid complication in
the application, but my view is that if this many different channels are
required, and the environment is complex enough to have that many
applications, you're better to let a single application handle things
specifically to the environment, and keep Hermes as simple as possible.

I'd like to see what kind of environment would use these different
channels.

 


o All parameters should be set in the EbxmlMessage object (e.g.
AckRequested, DuplicateElimincation, etc.)

o Also, communication parameters are specified when sending (e.g.
retries, retry interval)

Are the communicationparameters set on the ebXML message or as
parameters to the send method? I'd prefere the first, don't know why

Aren't retries, retry interval, etc part of the CPA? Therefore, they
shouldn't be specified in either the EbxmlMessage or as parameters to
send(). Instead, they should be in the CPA where they are looked up by
Hermes. Likewise, there isn't any need for a separate URLResolver, since
the CPA specifies where messages are delivered to. Perhaps a broader
CpaResolver is required. Given a CpaId, it returns a CPA object, which
encapsulates retries, retry interval, destination, etc. A default
provided CpaResolver could retrieve these things from a simple
Properties file. (I have a Sections class which uses something that
looks like the old Windows .ini files: Properties files in separate
sections with a file, which would be ideal for a simple implementation.)

I think parameters should be carefully classified. Those that are part
of a message (AckRequested, DuplicateElimination, etc) should be set in
the EbxmlMessage. Those that are part of the CPA (retries, retry
interval, etc), and are *not* part of the message, or of an individual
send(), should *not* be set in the message or as send() parameters.
Instead, they should be provided by the CpaResolver.

 

(Scalability)
 
Why reinvent the wheel? Persisting the message and then handing it (or a
reference) over to JMS queues for further processing is what we
currently do. JMS is (in most big appservers) also cluster aware and has
failover. Where available you could even the retry timeout etc. from the
jms queues for the sending component. Deploying a custom server-side
delivery class is nothing more than deploying a simple MDB (remember the
onMessage() !)

For smaller shops that don't have MQSeries clusters, or implementations
that don't have retry timeout(?), it may be that Hermes is up but JMS
isn't. It probably wouldn't hurt to consistently persist an incoming
message immediately, and hand it to a different thread for processing.
This makes message handling consistent, whether the processor is JMS,
URL redirect, or whatever. I'm all for JMS, but why single it out as a
special case?
 
Deploying a custom server-side delivery class is nothing more than
deploying a simple MDB (remember the onMessage() !)

I don't think Tomcat or other servlet containers do message driven
beans, which means you'd need JBoss or equivalent. EJB's, ugh. However,
faking it on Tomcat isn't difficult, just kick off a thread that sits on
a queue.

 
(Database Schema)
 
The current schema does not allow for partyId types, or multiple
parties, for instance. (It may now, I haven't looked lately.)
 
Management Functions

 We plan to remove most management functions (e.g. backup/archive).
Those functions will be cover by a separate module to make the code
cleaner

 

Excellent. This may also resolve some management vs user authorisation
problems, which haven't been addressed here.

 
Packaging

 Add a constructor in EbxmlMessage object which loads an ebXML message
from a file

 
I'm currently doing this by subclassing EbxmlMessage and building a
SOAPMessage to pass to EbxmlMessage(), where the file is the output from
from SOAPMessage.writeTo().
 
Transport / Security

 Add outgoing client authentication (certificates?)

 

I've done this by using the new LocalConfiguration hook to install my
own KeyManager. Perhaps another one for the contributions library? :-)
Using the apache-commons-httpclient instead of the built-in Sun stuff is
a damned good idea, though.

 

Add pluggable authentication (like jaas, or use what the
appserver/servlet enging already supports

AuthResolver and LDAP, yay! :-)

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...] 
Sent: Wednesday, 9 July 2003 9:08 AM
To: 'ebx...@li...'
Subject: RE: [ebxmlms-develop] Hermes 1.0 my remarks



First short remarks. Added in blue-courier. 

Regards, 

Ronald 

> -----Oorspronkelijk bericht----- 
> Van: Patrick Yee [ mailto:kc...@ce...
<mailto:kc...@ce...> ] 
> Verzonden: dinsdag 8 juli 2003 10:32 
> Aan: 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.