ebxmlms-develop — Development discussions

RE: [ebxmlms-develop] Hermes 1.0: sync reply

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

See the message of Patrick Yee on june 5th about SYNC_REPLY_MODE.....
 
btw. does anybody have a problem with my messages beiing
digitally-signed

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: donderdag 10 juli 2003 0:36
Aan: '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...' 
> 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... 
> > 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.

RE: [ebxmlms-develop] Hermes 1.0: sync reply

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

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...]
Verzonden: donderdag 10 juli 2003 0:36
Aan: '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...' 
> 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... 
> > 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.

RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

Great, but the file and url providers could be implemented in the same
way. 
 
Use a jndi lookup to find a 'server-side delivery provider' which knows
how and where to read it's own properties. The url is a property of this
provider, just like the jms server, factory, username's, passwords,
certificates etc. (in any mix). Dynamic registration could follow the
same lines.
 
URL and File are just pre-packaged custom delivery options
 
Ronald
 
 
 

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: woensdag 9 juli 2003 15:07
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


Agreed with JNDI contexts. That's why I propose to use a Properties
object. My proposal is: we provide hook for a client to specify which
server side delivery hook to be used. To specify, the client specify the
class name of the hook, together with a Properties object for
configuration like JNDI contexts. Hermes can then initialize the class
using the Properties object in server side. When an incoming message
arrives, the onMessage() method of that class will be called to delivery
the message.
 
This proposal is what I called "customized server side delivery".
 
Regards, -Patrick
 

----- Original Message ----- 
From: Ronald van Kuijk <mailto:rv...@ab...>  
To: 'ebx...@li...'
<mailto:'ebx...@li...'>  
Sent: Wednesday, July 09, 2003 07:00 PM
Subject: RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

don't use url's but an alternative method (jndi contexts?) The can be
used for filesystem etc. as well.
 
A client registers which jndi name has to be used by the server to
lookup the component for delivery.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: woensdag 9 juli 2003 12:30
Aan: ebx...@li...
<mailto:ebx...@li...> 
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?
Regards, -Patrick


Mayne, Peter wrote:


(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.
 


------------------------------------------------------- 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

Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

Agreed with JNDI contexts. That's why I propose to use a Properties =
object. My proposal is: we provide hook for a client to specify which =
server side delivery hook to be used. To specify, the client specify the =
class name of the hook, together with a Properties object for =
configuration like JNDI contexts. Hermes can then initialize the class =
using the Properties object in server side. When an incoming message =
arrives, the onMessage() method of that class will be called to delivery =
the message.

This proposal is what I called "customized server side delivery".

Regards, -Patrick

  ----- Original Message -----=20
  From: Ronald van Kuijk=20
  To: 'ebx...@li...'=20
  Sent: Wednesday, July 09, 2003 07:00 PM
  Subject: RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


  don't use url's but an alternative method (jndi contexts?) The can be =
used for filesystem etc. as well.

  A client registers which jndi name has to be used by the server to =
lookup the component for delivery.

  Ronald
    -----Oorspronkelijk bericht-----
    Van: Patrick Yee [mailto:kc...@ce...]
    Verzonden: woensdag 9 juli 2003 12:30
    Aan: ebx...@li...
    Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


    How to specify the JMS destination in the form of a URL, if the =
single server-side mode only provides an interface for specifying a URL?
    Regards, -Patrick


    Mayne, Peter wrote:

      (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.

    ------------------------------------------------------- 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

RE: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

don't use url's but an alternative method (jndi contexts?) The can be
used for filesystem etc. as well.
 
A client registers which jndi name has to be used by the server to
lookup the component for delivery.
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: woensdag 9 juli 2003 12:30
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)


How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?
Regards, -Patrick


Mayne, Peter wrote:


(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.
 


------------------------------------------------------- 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

Re: [ebxmlms-develop] Hermes 1.0 (JMS delivery)

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv=3D"Content-Type" content=3D"text/html;charset=3DUTF-8"=
>
  <title></title>
</head>
<body text=3D"#000000" bgcolor=3D"#ffffff">
How to specify the JMS destination in the form of a URL, if the single
server-side mode only provides an interface for specifying a URL?<br>
Regards, -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type=3D"cite"
 cite=3D"mid...@s-...=
m.au">
  <meta http-equiv=3D"Content-Type" content=3D"text/html; ">
  <title>Message</title>
  <meta content=3D"MSHTML 6.00.2800.1141" name=3D"GENERATOR">
  <div><font size=3D"2"><font color=3D"#0000ff"><span
 class=3D"361055900-09072003"><font face=3D"Arial" color=3D"#000000" size=
=3D"2">(Server
side delivery mode)</font></span></font></font></div>
  <div>=C2=A0</div>
  <div><font size=3D"2"><font color=3D"#0000ff"><font face=3D"Arial">-
Shouldn't all (server side ones) implement the same interface<span
 class=3D"361055900-09072003"> </span></font></font><font face=3D"Arial">=
<font
 color=3D"#0000ff">(onMessage()?) and File and URL just be some de</font>=
<font
 color=3D"#0000ff">fault included<span class=3D"361055900-09072003"> </sp=
an></font></font></font><font
 face=3D"Arial" color=3D"#0000ff" size=3D"2">implementations? (Isn't this
also a 'hook'?)</font></div>
  <div>=C2=A0</div>
  <div><span class=3D"361055900-09072003"><font face=3D"Arial" size=3D"2"=
>I
was thinking exactly the same thing. :-) There should be only one
server-side=C2=A0mode, with a trusted repository and URL redirect provide=
d
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.</font></span></div>
  <font color=3D"#0000ff" size=3D"2"><font face=3D"Arial" color=3D"#0000f=
f"
 size=3D"2">
  <p align=3D"left">I'd vote for a jms implementation to and volunteer to
implement one</p>
  </font></font>
  <div><font face=3D"Arial" size=3D"2"><span class=3D"361055900-09072003"=
>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.</span></font></div>
  <div>=C2=A0</div>
  <font face=3D"Arial" size=3D"2"><font face=3D"Arial"></font></font></bl=
ockquote>
</body>
</html>

RE: [ebxmlms-develop] Hermes 1.0: sync reply

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

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...]
> 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
> 

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.

Re: [ebxmlms-develop] Hermes 1.0

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

<!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 text="#000000" bgcolor="#ffffff">
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <p><font size="2">Great, I'll go over it. Shouldn't it just be a
summary of requested enhancements and later put them in a release
schedule (maybe some of them will be past 1.0?)</font></p>
</blockquote>
Yes. But some requested enhancements might be missed. Please help to
make it complete.<br>
<br>
<blockquote type="cite"
 cite="mid...@po...">
  <p><font size="2">Too bad SourceForge doesn't have a wiki. We could
discuss the document on the mailinglist and have a living document on
wiki. I could set up one on my computer if anybody is interested.</font></p>
</blockquote>
<br>
That will be great. Thanks in advance.<br>
<br>
<font size="2">Regards, -Patrick</font><br>
</body>
</html>

RE: [ebxmlms-develop] Hermes 1.0

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

For anyone interested, look at http://roestbak.xs4all.nl:8080/wiki/

> -----Oorspronkelijk bericht-----
> Van: Patrick Yee [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
> 

RE: [ebxmlms-develop] Hermes 1.0

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

Great, I'll go over it. Shouldn't it just be a summary of requested
enhancements and later put them in a release schedule (maybe some of them
will be past 1.0?)

Too bad SourceForge doesn't have a wiki. We could discuss the document on
the mailinglist and have a living document on wiki. I could set up one on my
computer if anybody is interested.

Ronald

> -----Oorspronkelijk bericht-----
> Van: Patrick Yee [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
> 

[ebxmlms-develop] Hermes 1.0

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

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

[ebxmlms-develop] Signature and axis

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

Hi,

In the PKISignatureImpl.java you do the following:

       DocumentResult docResult = new DocumentResult();
       TransformerFactory.newInstance().newTransformer().
           transform(soapPart.getContent(), docResult);
       ByteArrayOutputStream baos = new ByteArrayOutputStream();
       (new XMLWriter(baos)).write(docResult.getDocument());
       DocumentBuilderFactory factory = DocumentBuilderFactory.
           newInstance();
       factory.setNamespaceAware(true);
       // soapPartDocument is a DOM equivilance of soapPart
       final Document soapPartDocument = factory.newDocumentBuilder().
           parse(new ByteArrayInputStream(baos.toByteArray()));


Just to get from a soapPart to a soapPartDocument. According to the 
specs (well the tutorial at least):

Moreover, the |SOAPPart| of a |SOAPMessage| is also a DOM Level 2 
|Document|, and can be manipulated as such by applications, tools and 
libraries that use DOM. See Chapter 6 
<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JAXPDOM.html#wp79996> 
for details about DOM. See Adding Content to the SOAPPart Object 
<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/SAAJ3.html#wp64119> and 
Adding a Document to the SOAP Body 
<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/SAAJ3.html#wp78963> for 
details on how to use DOM documents with the SAAJ API.

       final Document soapPartDocument = (Document) soapPart;


Should work as well.  Maybe the 'axis' problem is solved then as well.
Eclipse does not complain about the casting and is really good at 
checking this, I'll try running it later (have currently no server 
configured for using certificates).

Ronald

Re: [ebxmlms-develop] getDescriptionCount() et al (similar to get PayloadCount())

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

<!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>
The current implementation of getContentLength() is created for one
purpose: to report number of bytes in that payload without counting the
input stream byte by byte. The only possible way to do this is by
calculations on the pointers stored in AttachmentDataSource. We have a
dillema here. Actually we can count the bytes in InputStream here...
but it will be too time consuming for large payloads. Another concern
is that we are not able to consider the Content-Transfer-Encoding here.
The encoding to be used is not known until the point real sending takes
place...<br>
<br>
Basically, I agree to create a getActualContentLength() method. But I
am worried about the confusion with getContentLength(). <br>
<br>
Regards, -Patrick<br>
<br>
<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <div><span class="387104023-26062003"><font face="Arial" size="2">The
Javadoc for PayloadContainer.getContentLength() says:</font></span><span
 class="387104023-26062003"></span></div>
  <div><font color="#3f5fbf" size="2">&nbsp;</font></div>
  <font size="2"> </font>
  <div><font face="Arial"><font color="#3f5fbf" size="2">Get</font><font
 size="2"> </font><font color="#3f5fbf" size="2">the</font><font
 size="2"> </font><font color="#3f5fbf" size="2">content</font><font
 size="2"> </font><font color="#3f5fbf" size="2">length</font><font
 size="2"> </font><font color="#3f5fbf" size="2">of</font><font size="2"> </font><font
 color="#3f5fbf" size="2">this</font><font size="2"> </font><font
 color="#3f5fbf" size="2">payload.</font><font size="2"> </font><font
 color="#3f5fbf" size="2">Note</font><font size="2"> </font><font
 color="#3f5fbf" size="2">that</font><font size="2"> </font><font
 color="#3f5fbf" size="2">the</font><font size="2"> </font><font
 color="#3f5fbf" size="2">content</font><font size="2"> </font><font
 color="#3f5fbf" size="2">length</font></font><font size="2"> </font></div>
  <div><font face="Arial"><font color="#3f5fbf" size="2">returned</font><font
 size="2"> </font><font color="#3f5fbf" size="2">will</font><font
 size="2"> </font><font color="#3f5fbf" size="2">be</font><font size="2"> </font><font
 color="#7f7f9f" size="2">-</font><font color="#3f5fbf" size="2">1</font><font
 size="2"> </font><font color="#3f5fbf" size="2">if</font><font size="2"> </font><font
 color="#3f5fbf" size="2">this</font><font size="2"> </font><font
 color="#3f5fbf" size="2">container</font><font size="2"> </font><font
 color="#3f5fbf" size="2">is</font><font size="2"> </font><font
 color="#3f5fbf" size="2">not</font><font size="2"> </font><font
 color="#3f5fbf" size="2">created</font><font size="2"> </font><font
 color="#3f5fbf" size="2">from</font></font><font size="2"> </font></div>
  <div><font face="Arial"><font color="#3f5fbf" size="2">AttachmentDataSource.</font><font
 size="2"> </font><font color="#3f5fbf" size="2">Also,</font><font
 size="2"> </font><font color="#3f5fbf" size="2">the</font><font
 size="2"> </font><font color="#3f5fbf" size="2">length</font><font
 size="2"> </font><font color="#3f5fbf" size="2">returned</font><font
 size="2"> </font><font color="#3f5fbf" size="2">does</font><font
 size="2"> </font><font color="#3f5fbf" size="2">not</font><font
 size="2"> </font><font color="#3f5fbf" size="2">take</font></font><font
 size="2"> </font></div>
  <div><font face="Arial"><font color="#3f5fbf" size="2">Content</font><font
 color="#7f7f9f" size="2">-</font><font color="#3f5fbf" size="2">Transfer</font><font
 color="#7f7f9f" size="2">-</font><font color="#3f5fbf" size="2">Encoding</font><font
 size="2"> </font><font color="#3f5fbf" size="2">into</font><font
 size="2"> </font><font color="#3f5fbf" size="2">account,</font><font
 size="2"> </font><font color="#3f5fbf" size="2">if</font><font size="2"> </font></font><font
 color="#3f5fbf" size="2"><font face="Arial">any.</font></font></div>
  <div>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="387104023-26062003">I'm
getting a content length of -1, so I'll believe it. :-)</span></font></div>
  <div><font face="Arial" size="2"><span class="387104023-26062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="387104023-26062003">So
it seems&nbsp;the only way to do this properly would be <font size="2">.getDataHandler().getInputStream()
and count the bytes. However, if by "if we can prevent loading the
documents" you mean "we don't mind if someone else loads the
documents", not a problem. :-)</font></span></font></div>
  <div><font face="Arial" size="2"><span class="387104023-26062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="387104023-26062003">Would
it be sufficient to provide a getActualContentLength()&nbsp;that loads and
counts bytes?</span></font></div>
  <div><font face="Arial" size="2"><span class="387104023-26062003"></span></font>&nbsp;</div>
  <div><font face="Arial" size="2"><span class="387104023-26062003">Would
you also want a EbxmlMessage.getActualPayloadLength() to return the
sum of all payload container&nbsp;lengths?</span></font></div>
  <div>&nbsp;</div>
  <div><span class="387104023-26062003"><font face="Arial" size="2">(Better
name suggestions anyone?)</font></span></div>
  <div><span class="387104023-26062003"></span>&nbsp;</div>
  <div><span class="387104023-26062003"><font face="Arial" size="2">PJDM</font></span></div>
<!-- Converted from text/plain format -->
  <div><font face="Arial" size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777 </font></div>
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 0); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" lang="en-us" dir="ltr"
 align="left"><font face="Tahoma" size="2">-----Original Message-----<br>
    <b>From:</b> Ronald van Kuijk   [<a class="moz-txt-link-freetext" href="mailto:rv...@ab...">mailto:rv...@ab...</a>] <br>
    <b>Sent:</b> Thursday, 26 June 2003 8:14   PM<br>
    <b>To:</b> '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'<br>
    <b>Subject:</b> RE: [ebxmlms-develop] getDescriptionCount() et al
(similar to get   PayloadCount())<br>
    <br>
    </font></div>
    <div><span class="644384809-26062003"><font face="Arial"
 color="#0000ff" size="2">The   total size of all attachments
(unencoded)</font></span></div>
    <div><span class="644384809-26062003"></span>&nbsp;</div>
    <div><span class="644384809-26062003"><font face="Arial"
 color="#0000ff" size="2">We   partly base billing on this and if we
can prevent loading the documents that   would be great</font></span></div>
    <div><span class="644384809-26062003"></span>&nbsp;</div>
    <div><span class="644384809-26062003"><font face="Arial"
 color="#0000ff" size="2">Ronald</font></span></div>
    <blockquote
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;">
      <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Oorspronkelijk bericht-----<br>
      <b>Van:</b> Patrick Yee     [<a class="moz-txt-link-freetext" href="mailto:kc...@ce...">mailto:kc...@ce...</a>]<br>
      <b>Verzonden:</b> donderdag 26 juni 2003     9:40<br>
      <b>Aan:</b> <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a><br>
      <b>Onderwerp:</b> Re:     [ebxmlms-develop] getDescriptionCount()
et al (similar to get     PayloadCount())<br>
      <br>
      </font></div>
Do you want to get the size of a     particular payload? or to get
number of payloads in a message?     -Patrick<br>
      <br>
Ronald van Kuijk wrote:<br>
      <blockquote
 cite="mid...@po..."
 type="cite">
        <meta content="MSHTML 5.50.4916.2300" name="GENERATOR">
        <div><span class="214561907-26062003"><font face="Arial"
 color="#0000ff" size="2">If it's that easy for you ;-) I got one to...
(didn't look if it's       already there) </font></span></div>
        <div><span class="214561907-26062003"></span>&nbsp;</div>
        <div><span class="214561907-26062003"><font face="Arial"
 color="#0000ff" size="2">getPayloadSize()</font></span></div>
        <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
          <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Oorspronkelijk bericht-----<br>
          <b>Van:</b> Mayne, Peter [<a class="moz-txt-link-freetext"
 href="mailto:Pet...@ap...">mailto:Pet...@ap...</a>]<br>
          <b>Verzonden:</b> donderdag 26 juni 2003 8:17<br>
          <b>Aan:</b> '<a class="moz-txt-link-abbreviated"
 href="mailto:ebx...@li...">ebx...@li...</a>'<br>
          <b>Onderwerp:</b> [ebxmlms-develop] getDescriptionCount() et
al (similar to         getPayloadCount())<br>
          <br>
          </font></div>
          <p><font size="2">Can we please add a getDescriptionCount()
to         MessageHeader and Reference, analagous to getPayloadCount()
in         EbxmlMessage?</font></p>
          <p><font size="2">Similarly for any other ArrayList-type
elements that         return Iterators. The code I'm writing would
find it highly         convenient.</font></p>
          <p><font size="2">If you're agreeable, I'm happy to do it.
It's not that         hard, even for me. :-)</font> </p>
          <p><font size="2">Thanks.</font> </p>
          <p><font size="2">PJDM</font> <br>
          <font size="2">-- </font><br>
          <font size="2">Peter Mayne</font> <br>
          <font size="2">Technology Consultant</font> <br>
          <font size="2">Spherion Technology Solutions</font> <br>
          <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT,
2602</font> <br>
          <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
          <font color="blue" size="3">
          <pre>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.


    </pre>
          </font></blockquote>
      </blockquote>
-------------------------------------------------------     This
SF.Net email is sponsored by: INetU Attention Web Developers &amp;    
Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers.
We     Manage Them. You Get 10% Monthly Commission! INetU Dedicated
Managed Hosting     <a class="moz-txt-link-freetext" href="http://www.inetu.net/partner/index.php">http://www.inetu.net/partner/index.php</a>    
_______________________________________________ ebxmlms-develop mailing
list     <a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>    
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop">https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop</a></blockquote>
  </blockquote>
</blockquote>
</body>
</html>

RE: [ebxmlms-develop] getDescriptionCount() et al (similar to get PayloadCount())

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

The total size of all attachments (unencoded)
 
We partly base billing on this and if we can prevent loading the
documents that would be great
 
Ronald

-----Oorspronkelijk bericht-----
Van: Patrick Yee [mailto:kc...@ce...]
Verzonden: donderdag 26 juni 2003 9:40
Aan: ebx...@li...
Onderwerp: Re: [ebxmlms-develop] getDescriptionCount() et al (similar to
get PayloadCount())


Do you want to get the size of a particular payload? or to get number of
payloads in a message? -Patrick

Ronald van Kuijk wrote:


If it's that easy for you ;-) I got one to... (didn't look if it's
already there) 
 
getPayloadSize()

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [ mailto:Pet...@ap...
<mailto:Pet...@ap...> ]
Verzonden: donderdag 26 juni 2003 8:17
Aan: ' ebx...@li...
<mailto:ebx...@li...> '
Onderwerp: [ebxmlms-develop] getDescriptionCount() et al (similar to
getPayloadCount())



Can we please add a getDescriptionCount() to MessageHeader and
Reference, analagous to getPayloadCount() in EbxmlMessage?

Similarly for any other ArrayList-type elements that return Iterators.
The code I'm writing would find it highly convenient.

If you're agreeable, I'm happy to do it. It's not that hard, even for
me. :-) 

Thanks. 

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


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 is sponsored by: INetU Attention Web Developers & Consultants:
Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage
Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting
http://www.inetu.net/partner/index.php
_______________________________________________ ebxmlms-develop mailing
list ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop

Re: [ebxmlms-develop] getDescriptionCount() et al (similar to get PayloadCount())

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

<!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>
Do you want to get the size of a particular payload? or to get number
of payloads in a message? -Patrick<br>
<br>
Ronald van Kuijk wrote:<br>
<blockquote type="cite"
 cite="mid...@po...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>getDescriptionCount() et al (similar to getPayloadCount())</title>
  <meta content="MSHTML 5.50.4916.2300" name="GENERATOR">
  <div><span class="214561907-26062003"><font face="Arial"
 color="#0000ff" size="2">If it's that easy for you ;-) I got one
to... (didn't look if it's already there) </font></span></div>
  <div><span class="214561907-26062003"></span>&nbsp;</div>
  <div><span class="214561907-26062003"><font face="Arial"
 color="#0000ff" size="2">getPayloadSize()</font></span></div>
  <blockquote dir="ltr"
 style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px; margin-right: 0px;">
    <div class="OutlookMessageHeader" dir="ltr" align="left"><font
 face="Tahoma" size="2">-----Oorspronkelijk bericht-----<br>
    <b>Van:</b> Mayne, Peter   [<a class="moz-txt-link-freetext" href="mailto:Pet...@ap...">mailto:Pet...@ap...</a>]<br>
    <b>Verzonden:</b> donderdag 26 juni   2003 8:17<br>
    <b>Aan:</b> '<a class="moz-txt-link-abbreviated" href="mailto:ebx...@li...">ebx...@li...</a>'<br>
    <b>Onderwerp:</b> [ebxmlms-develop]   getDescriptionCount() et al
(similar to getPayloadCount())<br>
    <br>
    </font></div>
    <p><font size="2">Can we please add a getDescriptionCount() to
MessageHeader and   Reference, analagous to getPayloadCount() in
EbxmlMessage?</font></p>
    <p><font size="2">Similarly for any other ArrayList-type elements
that return   Iterators. The code I'm writing would find it highly
convenient.</font></p>
    <p><font size="2">If you're agreeable, I'm happy to do it. It's not
that hard,   even for me. :-)</font> </p>
    <p><font size="2">Thanks.</font> </p>
    <p><font size="2">PJDM</font> <br>
    <font size="2">-- </font><br>
    <font size="2">Peter   Mayne</font> <br>
    <font size="2">Technology Consultant</font> <br>
    <font size="2">Spherion Technology Solutions</font> <br>
    <font size="2">Level 1, 243   Northbourne Avenue, Lyneham, ACT,
2602</font> <br>
    <font size="2">T: 61 2   62689727&nbsp; F: 61 2 62689777</font> </p>
    <font color="blue" size="3">
    <pre>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.


    </pre>
    </font></blockquote>
</blockquote>
</body>
</html>

Re: [ebxmlms-develop] getDescriptionCount() et al (similar to getPayloadCount())

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

<!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>
Yes, thanks. -Patrick<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 5.5.2654.45">
  <title>getDescriptionCount() et al (similar to getPayloadCount())</title>
  <p><font size="2">Can we please add a getDescriptionCount() to
MessageHeader and Reference, analagous to getPayloadCount() in
EbxmlMessage?</font></p>
  <p><font size="2">Similarly for any other ArrayList-type elements
that return Iterators. The code I'm writing would find it highly
convenient.</font></p>
  <p><font size="2">If you're agreeable, I'm happy to do it. It's not
that hard, even for me. :-)</font> </p>
  <p><font size="2">Thanks.</font> </p>
  <p><font size="2">PJDM</font> <br>
  <font size="2">-- </font> <br>
  <font size="2">Peter Mayne</font> <br>
  <font size="2">Technology Consultant</font> <br>
  <font size="2">Spherion Technology Solutions</font> <br>
  <font size="2">Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602</font> <br>
  <font size="2">T: 61 2 62689727&nbsp; F: 61 2 62689777</font> </p>
  <font size="3" color="BLUE">
  <pre>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.


  </pre>
  </font> </blockquote>
</body>
</html>

RE: [ebxmlms-develop] getDescriptionCount() et al (similar to get PayloadCount())

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

If it's that easy for you ;-) I got one to... (didn't look if it's
already there) 
 
getPayloadSize()

-----Oorspronkelijk bericht-----
Van: Mayne, Peter [mailto:Pet...@ap...]
Verzonden: donderdag 26 juni 2003 8:17
Aan: 'ebx...@li...'
Onderwerp: [ebxmlms-develop] getDescriptionCount() et al (similar to
getPayloadCount())



Can we please add a getDescriptionCount() to MessageHeader and
Reference, analagous to getPayloadCount() in EbxmlMessage?

Similarly for any other ArrayList-type elements that return Iterators.
The code I'm writing would find it highly convenient.

If you're agreeable, I'm happy to do it. It's not that hard, even for
me. :-) 

Thanks. 

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


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.

Re: [ebxmlms-develop] Persistent store

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

I am working on a document describing the 1.0 plan. This would be added 
to the plan. :-)
Regards, -Patrick


Ronald van Kuijk wrote:

> Alexei,
>
> Things like this are already happening in other points in the code 
> (resolving a url, verifiy a certificate)
>
> I agree that persistancy is another of those points. If we would start 
> using Hermes in production environment, we have to run it in a Bea 
> Weblogic Server and are forced by our ASP to use the internal 
> connectionpools, are not allowed to use a filesystem for persistancy 
> (unless it is controlled by bea e.g. file persitency for jms queues)
>
> This  means however that configuration items of the persitancy should 
> probably not be in the general MHS configuration, but in a separate 
> file or so. Major changes which I think should not happen before the 
> 1.0 release,  but shortly after that. (and take clustering/failover 
> into account as well)
>
> Ronald
>
> Alexei Zolotarev probeerde het volgende duidelijk te maken op 
> 25-6-2003 10:13:
>
>> Hi,
>>
>> I`m follow the Hermes development for about half year and notice
>> one unpleasant design defect. The persistent store in Hermes designed
>> in following manner:
>>  1) Message relations are stored in RDBMS structure.
>>  2) Messages are stored in file system
>> Not bad decision.
>>
>> But under living conditions we are forced to use Oracle to storage
>> both for message relations and for messages themselves. Oracle offers
>> BLOB type for such issues.
>> Hermes source code investigation shows that it`s not easy to correct
>> product. Too many things are based on files and their names :-(
>>
>> Could you define Java interface for file storage operations? Anybody
>> who want to redifine storage manner will create new interface
>> imlementation only. I think that this will simplify Hermes code and
>> make Hermes for flexible.
>>
>> What do you think?
>>
>> Regards,
>> Alexei Zolotarev
>> Software Developer
>> RDTEX JSC
>> Zavodskoi proezd 6, Protvino, Moscow region, Russia Federation
>>
>> P.S. Excuse me for my bad English
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: INetU
>> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>> _______________________________________________
>> ebxmlms-develop mailing list
>> ebx...@li...
>> https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>>  
>>
>

Re: [ebxmlms-develop] Should Hermes makes dispatching decision?

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

<!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>
I am working on the plan... will post to the list for comment. -Patrick<br>
<br>
<br>
Mayne, Peter wrote:<br>
<blockquote type="cite"
 cite="mid...@s-...">
  <meta http-equiv="Content-Type" content="text/html; ">
  <title>Message</title>
  <meta content="MSHTML 6.00.2800.1141" name="GENERATOR">
  <div><font face="Arial" size="2"><font color="#0000ff"><font
 face="Times New Roman" size="3">Most of the attributes are from CPA.
But the current implementation is a bit confusing.. I should admit.
Some attributes are set at Request object (session wide), some
attributes are set at EbxmlMessage (i.e. per message based). Luckily,
there is no attribute being set at property file (not configurable in
run time).. ... <br>
  <br>
We should make it consistent in 1.0.</font><br>
  </font></font></div>
  <div><span class="784571823-23062003"><font face="Arial" size="2">I
agree (both with the "confusing" and the "consistent" :-). Are you
going to&nbsp;develop a plan we can look at?</font></span></div>
  <div>&nbsp;</div>
  <div><span class="784571823-23062003"><font face="Arial" size="2">PJDM</font></span></div>
<!-- Converted from text/plain format -->
  <div><font face="Arial" size="2">--<br>
Peter Mayne<br>
Technology Consultant<br>
Spherion Technology Solutions<br>
Level 1, 243 Northbourne Avenue, Lyneham, ACT, 2602<br>
T: 61 2 62689727&nbsp; F: 61 2 62689777</font></div>
  <font size="3" color="BLUE">
  <pre>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.


  </pre>
  </font> </blockquote>
</body>
</html>

Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

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

Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 
25-6-2003 10:36:

<snip/>

>        As said, we ultimate goal should be switching to Axis. However,
>Axis currently has a really "nice" feature. It would serialize the XML
>document in a pretty way by adding indenting white spaces. My colleague
>and I ever trace the source codes and it seems that there is no way to
>call SAAJ method to disable such a "nice" feature. After signing with
>digital signature, the serialization breaks it. This is the reason why
>up to now, I do not yet upload Axis libraries into lib/.
>  
>
I've read in some newsgroups/mailinglists that lots of people have a 
problem with this (e.g. opensaml)

As a workaround they write:

<scott cantor>
If you can use Axis to get hold of the SOAP DOM (the envelope), what you 
can do is write your own code to output the DOM using the

c14n algorithm inside xmlsec. I don't expose that because I'm trying to hide my use of xmlsec inside. But you can always import and
call those methods directly.

Just look at toStream() in any of the SAML classes to see how to do it.
</scott cantor>

see

http://marsalis.internet2.edu/cgi-bin/viewcvs.cgi/opensaml/java/src/org/opensaml/SAMLObject.java?rev=1.13&content-type=text/vnd.viewcvs-markup

Maybe this could work here to...getting that output and using that as 
input for the signature verification.

Ronald

Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

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

Ng Chi Yuen [Cyng] probeerde het volgende duidelijk te maken op 
25-6-2003 10:36:

>Hi,
>
>  
>
>>Axis saaj compliant (the api), so i think you mean removing the sun
>>reference-implementation of saaj?
>>    
>>
>
>        Actually, the current 1.0 branch can already work with Axis
>(except digital signature). Our thought is to remove Sun's RI of SAAJ.
>
I know, got it running here... but initally i removed all jaxm libs.. 
and then it doesn't work  (it didn't even compile, but I missed that 
part stupid me)
didn't try signatures yet (but you already reported that that doesn't 
work yet)

>
>  
>
>>Or do you realy want to start using the lowlevel axis api of jdom?
>>Personally I wouldn't do that. Just stick with saaj and use the axis
>>implementation. (doesn't axis use jdom?)
>>    
>>
>
>        Axis does not ride on JDOM but just DOM (Xerces). Well, keeping
>SAAJ API is fine for me. The current 1.0 branch is exactly what it is.
>However, I just mean that if there is any modification to packaging,
>simply switching to JDOM is not that difficult because SAAJ is now quite
>now transparent to users. Users just know EbxmlMessage and SAAJ of Axis
>is just an implementation. Of course, the only reason to switch to JDOM
>is for efficiency.
>
I do not realy have a preference..  internally we normally change things 
if it results in more than 5% performance gain, otherwise we don't 
bother (unless it's a real simpel switch) . We've had a situation 
however where we had 4 changes 4% each and we did implement them (16% 
overall is a lot)

>
>  
>
>>Great, on an internal project we currently have thrown all sun http
>>classes overboard and use commons-httpclient  from apache. This gives us
>>better proxy support (including authentication, even NTLM) because the
>>Sun has some issues there, especially with M$ proxies. And
>>http-keepalive, which especially on busy connections, leads to 300%
>>performance gain.
>>    
>>
>
>        This idea inspires me. I don't ever use Apache httpclient but
>I think we would also review whether we use keep-alive feature and
>bypassing Sun's http code. Http.java is now quite ready to add codes
>for adding user authentication, proxy support, and performance tune.
>  
>
I'll look into this a little. What will be important is the whole 
queueing thing. For another server we are running, we have a jms queue 
per destination, with an MDB's that can use a connection from a 
connectionpool (per destination).

<sidenote>
We use jms since many jms servers (at least IBM, Bea and JBoss) 
currently support redeliverytimeouts, timetolive, maximum retries, a 
dead-letter-queue etc. so we did not have to implement anything for 
this. The only issue they do not support, or only partly, is ordered 
delivery within a subset of messages in the same queue.
</sidenote>

>  
>
>>Doesn't axis use jdom and Sun dom4j?.... I'l have a look So if  the sun
>>implementation of saaj is not used anymore we could switch to whatever
>>we want.
>>    
>>
>
>        As said, we ultimate goal should be switching to Axis. However,
>Axis currently has a really "nice" feature. It would serialize the XML
>document in a pretty way by adding indenting white spaces. My colleague
>and I ever trace the source codes and it seems that there is no way to
>call SAAJ method to disable such a "nice" feature. After signing with
>digital signature, the serialization breaks it. This is the reason why
>up to now, I do not yet upload Axis libraries into lib/.
>  
>
Realy??... is this a problem of axis xml-dsig? After reading a 
cannonicalization document  indenting whitespace seems to matter... 
hmm.. is a bug already filed with the axis developers? Where does it go 
wrong? Do you have a class name and a line number?  We  internally want 
to start using xml-dsig as wel with axis so probably run into this as 
well. Maybe a collegue of mine can make a pacht for axis and submit it.

>  
>
>>btw, did you ever have a look at  jxpath.... I you want clean code....e.g.
>>Address address = null;
>>Collection locations = vendor.getLocations();
>>Iterator it = locations.iterator();
>>while (it.hasNext()){
>>    Location location = (Location)it.next();
>>    String zipCode = location.getAddress().getZipCode();
>>    if (zipCode.equals("90210")){
>>      address = location.getAddress();
>>      break;
>>    }
>>}
>>can be written as
>>    Address address = (Address)JXPathContext.newContext(vendor).
>>         getValue("locations[address/zipCode='90210']/address");
>>especially the manipulation of the ebxmlmessage would then be realy
>>clean... just learn the xsd
>>    
>>
>
>        Oh, I don't ever look at JXpath. From the above coding style,
>the code is obviously cleaner. But I wonder if there is any concern,
>e.g., performance degradation (evaluating the expression instead of
>manipulating a DOM tree), or there is a strong dependency to use this extra
>library. Is JXpath quite stable and widely now? Anyway, I am open to this
>and we will discuss.
>  
>
A In real complex documents there is a performance issue, but on some 
tests we did, performance degradation was only relative to this piece of 
code (40%), but if you look at the absolute numbers (or relative to te 
full application) it was marginal.

If you guys have an option to do a performancetest, I'll try to change 
some pieces of the code to use jxpath and we can see. I do not mean we 
(you) should switch to jxpath, I just thought i'd mention it. (it is on 
apache btw and uses jdom)

Ronald

Re: [ebxmlms-develop] Persistent store

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

Alexei,

Things like this are already happening in other points in the code 
(resolving a url, verifiy a certificate)

I agree that persistancy is another of those points. If we would start 
using Hermes in production environment, we have to run it in a Bea 
Weblogic Server and are forced by our ASP to use the internal 
connectionpools, are not allowed to use a filesystem for persistancy 
(unless it is controlled by bea e.g. file persitency for jms queues)

This  means however that configuration items of the persitancy should 
probably not be in the general MHS configuration, but in a separate file 
or so. Major changes which I think should not happen before the 1.0 
release,  but shortly after that. (and take clustering/failover into 
account as well)

Ronald

Alexei Zolotarev probeerde het volgende duidelijk te maken op 25-6-2003 
10:13:

>Hi,
>
>I`m follow the Hermes development for about half year and notice
>one unpleasant design defect. The persistent store in Hermes designed
>in following manner:
>  1) Message relations are stored in RDBMS structure.
>  2) Messages are stored in file system
>Not bad decision.
>
>But under living conditions we are forced to use Oracle to storage
>both for message relations and for messages themselves. Oracle offers
>BLOB type for such issues.
>Hermes source code investigation shows that it`s not easy to correct
>product. Too many things are based on files and their names :-(
>
>Could you define Java interface for file storage operations? Anybody
>who want to redifine storage manner will create new interface
>imlementation only. I think that this will simplify Hermes code and
>make Hermes for flexible.
>
>What do you think?
>
>Regards,
>Alexei Zolotarev
>Software Developer
>RDTEX JSC
>Zavodskoi proezd 6, Protvino, Moscow region, Russia Federation
>
>P.S. Excuse me for my bad English
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: INetU
>Attention Web Developers & Consultants: Become An INetU Hosting Partner.
>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>_______________________________________________
>ebxmlms-develop mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-develop
>  
>

Re: [ebxmlms-develop] Sun WSDP1.2 without jaxm

[Ng C. Y. [Cyng] <cy...@cs...>]

Hi,

> Axis saaj compliant (the api), so i think you mean removing the sun
> reference-implementation of saaj?

        Actually, the current 1.0 branch can already work with Axis
(except digital signature). Our thought is to remove Sun's RI of SAAJ.

> Or do you realy want to start using the lowlevel axis api of jdom?
> Personally I wouldn't do that. Just stick with saaj and use the axis
> implementation. (doesn't axis use jdom?)

        Axis does not ride on JDOM but just DOM (Xerces). Well, keeping
SAAJ API is fine for me. The current 1.0 branch is exactly what it is.
However, I just mean that if there is any modification to packaging,
simply switching to JDOM is not that difficult because SAAJ is now quite
now transparent to users. Users just know EbxmlMessage and SAAJ of Axis
is just an implementation. Of course, the only reason to switch to JDOM
is for efficiency.

> Great, on an internal project we currently have thrown all sun http
> classes overboard and use commons-httpclient  from apache. This gives us
> better proxy support (including authentication, even NTLM) because the
> Sun has some issues there, especially with M$ proxies. And
> http-keepalive, which especially on busy connections, leads to 300%
> performance gain.

        This idea inspires me. I don't ever use Apache httpclient but
I think we would also review whether we use keep-alive feature and
bypassing Sun's http code. Http.java is now quite ready to add codes
for adding user authentication, proxy support, and performance tune.

> Doesn't axis use jdom and Sun dom4j?.... I'l have a look So if  the sun
> implementation of saaj is not used anymore we could switch to whatever
> we want.

        As said, we ultimate goal should be switching to Axis. However,
Axis currently has a really "nice" feature. It would serialize the XML
document in a pretty way by adding indenting white spaces. My colleague
and I ever trace the source codes and it seems that there is no way to
call SAAJ method to disable such a "nice" feature. After signing with
digital signature, the serialization breaks it. This is the reason why
up to now, I do not yet upload Axis libraries into lib/.

> btw, did you ever have a look at  jxpath.... I you want clean code....e.g.
> Address address = null;
> Collection locations = vendor.getLocations();
> Iterator it = locations.iterator();
> while (it.hasNext()){
>     Location location = (Location)it.next();
>     String zipCode = location.getAddress().getZipCode();
>     if (zipCode.equals("90210")){
>       address = location.getAddress();
>       break;
>     }
> }
> can be written as
>     Address address = (Address)JXPathContext.newContext(vendor).
>          getValue("locations[address/zipCode='90210']/address");
> especially the manipulation of the ebxmlmessage would then be realy
> clean... just learn the xsd

        Oh, I don't ever look at JXpath. From the above coding style,
the code is obviously cleaner. But I wonder if there is any concern,
e.g., performance degradation (evaluating the expression instead of
manipulating a DOM tree), or there is a strong dependency to use this extra
library. Is JXpath quite stable and widely now? Anyway, I am open to this
and we will discuss.

Regards,
CY

----------------------------------------------------------------------------
Ng Chi Yuen, CY.       cy...@ce...       http://www.cecid.hku.hk/
Technology Officer,
Centre for E-Commerce Infrastructure Development,
The University of Hong Kong
----------------------------------------------------------------------------

[ebxmlms-develop] Persistent store

[Alexei Z. <st...@ra...>]

Hi,

I`m follow the Hermes development for about half year and notice
one unpleasant design defect. The persistent store in Hermes designed
in following manner:
  1) Message relations are stored in RDBMS structure.
  2) Messages are stored in file system
Not bad decision.

But under living conditions we are forced to use Oracle to storage
both for message relations and for messages themselves. Oracle offers
BLOB type for such issues.
Hermes source code investigation shows that it`s not easy to correct
product. Too many things are based on files and their names :-(

Could you define Java interface for file storage operations? Anybody
who want to redifine storage manner will create new interface
imlementation only. I think that this will simplify Hermes code and
make Hermes for flexible.

What do you think?

Regards,
Alexei Zolotarev
Software Developer
RDTEX JSC
Zavodskoi proezd 6, Protvino, Moscow region, Russia Federation

P.S. Excuse me for my bad English