ebxmlms-general — General discussions

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

>
>> Hmm.. i wonder btw what transport protocol JMS is using if the client is
>> outside the appserver? HTTP? RMI? RMI over HTTP? Some proprietary 
>> protocol?
>>
> Isn't it proprietary?

Depends on the appserver... JBoss gives you several options, including 
http(s)

>
>>>>
>>> Another concern is exclusivity of Java world. A postoffice, by its 
>>> nature, does not imply Java. MQSeries does provide JMS interface, 
>>> but JMS is definitely not the only way to access MQ. Some demands we 
>>> have here is to make a postoffice neutual enough to let clients from 
>>> other worlds (e.g. .net) to use it.
>>
>>
>>
>> OpenPostoffice ->JMS ->J2EE
>> MS-PostOffice -> MS-MQ -> MS
>>
>
> We don't want to exclusively use Java. By the same token we don't want 
> to exclusively use .NET. The philosophy of web service is the 
> separation of dependency between the client and server platform, which 
> I think is a good idea.

I know, I don't want exclusivity for Java as well, but imo the 
postoffice calls are kind of local. If things have to be transported to 
a remote location, ebxml is used isn't it? The thing is, if you want 
real reliability and be not dependend on including specific jms 
libraries to access the specific jms server, you get into reliable 
webservices and how small is the step then to ebxml. Kind of like a 
lightweigt client (your ebxml smtp client, but then with some http calls)

>
>>>
>>> Afterall, I must confess that it makes sense to include ebXML into 
>>> J2EE. It's enterprise thing.
>>
>>
>>
>> I agree... will hermes start using all of the functionality that is
>> present in J2EE servers then? (connectionpooling, transactions) ;-)
>>
> Can you wait till next version? ;-)
>
You mean the things I'm checking out now? ;-)

Happy New Year

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

> Hmm.. i wonder btw what transport protocol JMS is using if the client is
> outside the appserver? HTTP? RMI? RMI over HTTP? Some proprietary 
> protocol?
>
Isn't it proprietary?

>>>
>> Another concern is exclusivity of Java world. A postoffice, by its 
>> nature, does not imply Java. MQSeries does provide JMS interface, but 
>> JMS is definitely not the only way to access MQ. Some demands we have 
>> here is to make a postoffice neutual enough to let clients from other 
>> worlds (e.g. .net) to use it.
>
>
> OpenPostoffice ->JMS ->J2EE
> MS-PostOffice -> MS-MQ -> MS
>

We don't want to exclusively use Java. By the same token we don't want 
to exclusively use .NET. The philosophy of web service is the separation 
of dependency between the client and server platform, which I think is a 
good idea.

>>
>> Afterall, I must confess that it makes sense to include ebXML into 
>> J2EE. It's enterprise thing.
>
>
> I agree... will hermes start using all of the functionality that is
> present in J2EE servers then? (connectionpooling, transactions) ;-)
>
Can you wait till next version? ;-)

Regards, -Patrick

Re: [ebxmlms-general] Error when running loopback.

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

Mark,

I still guess the problem is coming from jwsdp. From the exception, it 
seems that jwsdp is using some conflicting SOAP libraries. Is there any 
chance you can try it on tomcat?

Regards, -Patrick


MTM Zenhorst wrote:

>Hello,
>
>Installed the CVS build Hermes pre 1.0.0.0 version. It starts normally,
>starts polling the database. The log files give no errors.
>
>Then I try to run a Loopback test with the client that I copied from the CVS
>build from Hermes and then the Loopback hangs.
>
>In the logfile of Hermes it shows that the message can be normally stored.
>However it tries to retrieve the message from file. When it tries to create a
>soap envelope of that file it generates an error. the exception is as
>follows:
>[10002] Unknown error
>Exception: com.sun.xml.messaging.saaj.SOAPExceptionImpl
>Message: Unable to create envelope from given source:
>
>then it continues with a Transaction.rollback (txID: #32)
>after the rollback in the logfile everything seems to be ok again. it does a
>retry and that is successfull,  moving to status send and received, however
>the loopback does not continue, it keeps hanging.
>
>
>anybody have an idea about this problem?!?!?
>
>software:
>Linux 9
>jwsdp 1.2
>catalina 4.1.19
>Hermes pre 1.0.0.0
>postgres 3.2.1
>
>Mark Zenhorst
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>ebxmlms-general mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general
>  
>

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

>
>> The reason we do this is that not all our clients are always online 
>> to retrieve messages. Many have dial-up connections and want the 
>> messages pulled as soon as they are online. That is in my opinion 
>> what a postoffice is and why I hope multi-hop will be implemented in 
>> hermes as wel in the 1.1 release or so (any tips what is still 
>> missing or where to start?)
>>
>
> We have been reviewing the ebMS 3.0 white paper lately. Whether 
> multihop is needed or not is still controversial. In fact, as you can 
> see in ebMS 2.0 spec, the behaviour of multi-hop feature is not clear. 
> Therefore, I think this feature will still be on hold until the ebMS 
> TC gets a conclusion on it. :-)

Ok, I've read the whitepaper. What I mean with multi-hop is nothing more 
or less  than reliabilty if a message for one reason or another cannot 
be delivered directly to the end-point msh. In our community we will be 
working with a hub-and-spoke model where everybody delivers their 
messages physically to a central system. That system then delivers the 
message to the recipient, either directly (push) or by a kind of pull 
mechanism. All three systems in this configuration are ebxml compliant 
systems. Ofcourse there needs to be hop-to-hop reliablity. If the 
ws-reliabilty standards will support this, then we do not need a special 
multi-hop mechanism. I think we need (with the emphasis on think) a kind 
of  end-to-end reliability as well, but it could be that should be 
solved by business acknowledgements (which are end-to-end) instead of 
ack's on the msg level. This means delivering the message to the next 
hop and trusting it that it will deliver the message to the next hop. 
End-to-end acks on the messaging level are not needed then.

This last thing also solves the discussion about the overlap between 
end-to-end acks and business-process acks. Although some of our clients 
want to see an end-to-end ack on the message level in their msh logging, 
but that is partly because former x.400 systems had that functionality. 
Hmm... I should give this some more thought.

Still, multi-hop is in the current spec and it could give us some 
benefit it was there, at least the end-to-end (signed) and hop-to-hop 
(non-signed) reliability. I'll start looking a little into the spec and 
hermes code to get some leads.

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Ronald van Kuijk wrote:

> Ronald van Kuijk wrote:
>
>> Ronald van Kuijk wrote:
>>
>>> Patrick Yee wrote:
>>>
>>>>
>>>>> The reason we do this is that not all our clients are always 
>>>>> online to retrieve messages. Many have dial-up connections and 
>>>>> want the messages pulled as soon as they are online. That is in my 
>>>>> opinion what a postoffice is and why I hope multi-hop will be 
>>>>> implemented in hermes as wel in the 1.1 release or so (any tips 
>>>>> what is still missing or where to start?)
>>>>>
>>>>
>>>> We have been reviewing the ebMS 3.0 white paper lately. Whether 
>>>> multihop is needed or not is still controversial. In fact, as you 
>>>> can see in ebMS 2.0 spec, the behaviour of multi-hop feature is not 
>>>> clear. Therefore, I think this feature will still be on hold until 
>>>> the ebMS TC gets a conclusion on it. :-)
>>>>
>>> shoot.. .I've been on vacation in brasil for two weeks... did I mis 
>>> something? Is this document public?
>>
>>
>>
>> forget it, I've found it trough google. I saw it was announced on the 
>> ebxml-msg list... I'm subscribed to that but never got that message.
>>
>> Ronald
>
>
> To soon.... It was on the closed list and you have to be a member of 
> OASIS which we are not (yet)
>
> Ronald
>
>
found it ... 
http://www.oasis-open.org/committees/download.php/4383/ebMSv3FeaturePreview.pdf

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Ronald van Kuijk wrote:

> Ronald van Kuijk wrote:
>
>> Patrick Yee wrote:
>>
>>>
>>>> The reason we do this is that not all our clients are always online 
>>>> to retrieve messages. Many have dial-up connections and want the 
>>>> messages pulled as soon as they are online. That is in my opinion 
>>>> what a postoffice is and why I hope multi-hop will be implemented 
>>>> in hermes as wel in the 1.1 release or so (any tips what is still 
>>>> missing or where to start?)
>>>>
>>>
>>> We have been reviewing the ebMS 3.0 white paper lately. Whether 
>>> multihop is needed or not is still controversial. In fact, as you 
>>> can see in ebMS 2.0 spec, the behaviour of multi-hop feature is not 
>>> clear. Therefore, I think this feature will still be on hold until 
>>> the ebMS TC gets a conclusion on it. :-)
>>>
>> shoot.. .I've been on vacation in brasil for two weeks... did I mis 
>> something? Is this document public?
>
>
> forget it, I've found it trough google. I saw it was announced on the 
> ebxml-msg list... I'm subscribed to that but never got that message.
>
> Ronald

To soon.... It was on the closed list and you have to be a member of 
OASIS which we are not (yet)

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Ronald van Kuijk wrote:

> Patrick Yee wrote:
>
>>
>>> The reason we do this is that not all our clients are always online 
>>> to retrieve messages. Many have dial-up connections and want the 
>>> messages pulled as soon as they are online. That is in my opinion 
>>> what a postoffice is and why I hope multi-hop will be implemented in 
>>> hermes as wel in the 1.1 release or so (any tips what is still 
>>> missing or where to start?)
>>>
>>
>> We have been reviewing the ebMS 3.0 white paper lately. Whether 
>> multihop is needed or not is still controversial. In fact, as you can 
>> see in ebMS 2.0 spec, the behaviour of multi-hop feature is not 
>> clear. Therefore, I think this feature will still be on hold until 
>> the ebMS TC gets a conclusion on it. :-)
>>
> shoot.. .I've been on vacation in brasil for two weeks... did I mis 
> something? Is this document public?

forget it, I've found it trough google. I saw it was announced on the 
ebxml-msg list... I'm subscribed to that but never got that message.

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

> Christophe Hartwig-Peillon wrote:
>
>> Hi all,
>>
>>>        What do you think if the interface between the client and Hermes
>>> is Web Service? (Maybe with reliability as well.) In this case, the 
>>> client
>>> side need not be JMS API call at all while Hermes server need not use
>>> a JMS provider and it already sits there to receive HTTP Web Service 
>>> call.
>>> So far, Hermes does not yet touch the J2EE, JMS features and can be 
>>> thus
>>> deployed in an app server as simple as Jetty that SMEs' may feel a 
>>> little
>>> bit light-weight.
>>>  
>>>
>> As far as I know, Hermes and the client already rely on an HTTP based 
>> protocol... The problem is reliability : when two processes 
>> cooperate, you take the risk of having one down (hermes in our case). 
>> In this case, the whole system is down...
>> Relying on JMS, in the context of an app server, suppresses this 
>> problem.
>
In the context of the appserver yes, but then you could also call some
other classes directly, just as is configurable now with hermes.

>> Another interest of JMS is load balancing/fault tolerance.
>> Maybe other free JMS implementations could be used... there are many 
>> of them !
>
Yes but not a lot of them support automatic loadbalancing AND failover
at the same time. e.g. JBoss > 3.2.2 and Bea >WL6.1 do loadbalancing but
no automatic failover
Hmm.. i wonder btw what transport protocol JMS is using if the client is
outside the appserver? HTTP? RMI? RMI over HTTP? Some proprietary protocol?

>>
> Another concern is exclusivity of Java world. A postoffice, by its 
> nature, does not imply Java. MQSeries does provide JMS interface, but 
> JMS is definitely not the only way to access MQ. Some demands we have 
> here is to make a postoffice neutual enough to let clients from other 
> worlds (e.g. .net) to use it.

OpenPostoffice ->JMS ->J2EE
MS-PostOffice -> MS-MQ -> MS

>
>> I must confess I have an app server in my system (jBoss, clustered 
>> for fault tolerance). Does it mean that the protocol between Hermes 
>> and the client should be made pluggable ? This suits the J2EE spirit...
>>
> Pluggable? Hmm.... do you mean allowing multiple ways for the client 
> to connect to Hermes? In the best case, we can find a standard and 
> everybody connect to Hermes (and others message servers) in the same 
> way. I believe that one day we will have it.
>
If there is a good api for application <-> msh connections the
underlying protocol is not relevant.. otoh... with JMS the same problem
exists. Yoou have to use Bea classes to connetct to the Bea JMS server,
the same is true for the JBoss, IBM-MQ etc... A real standardized
'wire-protocol' (so not like JMS) would be best I think.

>> Anyway, I tried to correlate the kind of architecture hermes could 
>> have with requirements for inclusion into J2EE...
>> ebXML, with JAXM is out of J2EE.
>
>
>
> Afterall, I must confess that it makes sense to include ebXML into 
> J2EE. It's enterprise thing.

I agree... will hermes start using all of the functionality that is
present in J2EE servers then? (connectionpooling, transactions) ;-)

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

>
>> The reason we do this is that not all our clients are always online 
>> to retrieve messages. Many have dial-up connections and want the 
>> messages pulled as soon as they are online. That is in my opinion 
>> what a postoffice is and why I hope multi-hop will be implemented in 
>> hermes as wel in the 1.1 release or so (any tips what is still 
>> missing or where to start?)
>>
>
> We have been reviewing the ebMS 3.0 white paper lately. Whether 
> multihop is needed or not is still controversial. In fact, as you can 
> see in ebMS 2.0 spec, the behaviour of multi-hop feature is not clear. 
> Therefore, I think this feature will still be on hold until the ebMS 
> TC gets a conclusion on it. :-)
>
shoot.. .I've been on vacation in brasil for two weeks... did I mis 
something? Is this document public?

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

>
>> But isn't this abstraction exactely what hermes does with you 
>> allowing to implement your own messagelisteners? The only difference 
>> is that registering takes place via a http call rather then a config 
>> file or a gui
>>
> The registration can still take place via a http call in JMS case. I 
> think the use of http call or config file or gui is not a concern at all.

Yup

>
>>
>> So if you don't want to link the application to ebxml why do you want 
>> to link it to the postoffice? I'd like my client to link to a nice, 
>> clean and simple API. If JAXM was done right it would have fitted the 
>> ebxml messaging/transport layer quite well
>>
> Post office can be profiled. That means, post office can support 
> multiple underlying protocols, e.g. ebXML, RNIF, WS-Reliable 
> Messaging, etc. All the client need to master is a single set of APIs.

Just what JAXM liked to be (or at least likes to pretend to be ;-) ) I 
just wonder how much of the different underlying protocols can be hidden 
and still be general. If they start to differ to much I think it becomes 
to difficult.

>
>> We could go even further. It's not about a Business PostOffice, its 
>> about Business Processes. Let's give the J2EE specs a ebxml messaging 
>> protocol/api first and bother about the higher layers later.
>>
> We agree with the vision about business process. It's long. Whether or 
> not to make ebxml a part of J2EE specs is already a long way to go. I 
> would say it's no longer technical, but rather political. :-)
>
>> Last comment:
>> I do not want to sound like I disagree with you all, because on a lot 
>> of points I don't (at all!) but I get the feeling the "PostOffice" is 
>> a nice, clean api to a messaging system? Without the client having 
>> knowledge about the underlaying protocols, right?
>
>
> Yup. We need this kind of discussions to fuel the requirement of our 
> further development. Thank you.
>
I'm glad.. I was afraid to be banned from this list ;-)

Ronald

[ebxmlms-general] Error when running loopback.

[MTM Z. <zen...@fe...>]

Hello,

Installed the CVS build Hermes pre 1.0.0.0 version. It starts normally,
starts polling the database. The log files give no errors.

Then I try to run a Loopback test with the client that I copied from the CVS
build from Hermes and then the Loopback hangs.

In the logfile of Hermes it shows that the message can be normally stored.
However it tries to retrieve the message from file. When it tries to create a
soap envelope of that file it generates an error. the exception is as
follows:
[10002] Unknown error
Exception: com.sun.xml.messaging.saaj.SOAPExceptionImpl
Message: Unable to create envelope from given source:

then it continues with a Transaction.rollback (txID: #32)
after the rollback in the logfile everything seems to be ok again. it does a
retry and that is successfull,  moving to status send and received, however
the loopback does not continue, it keeps hanging.


anybody have an idea about this problem?!?!?

software:
Linux 9
jwsdp 1.2
catalina 4.1.19
Hermes pre 1.0.0.0
postgres 3.2.1

Mark Zenhorst

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

> But isn't this abstraction exactely what hermes does with you allowing 
> to implement your own messagelisteners? The only difference is that 
> registering takes place via a http call rather then a config file or a 
> gui
>
The registration can still take place via a http call in JMS case. I 
think the use of http call or config file or gui is not a concern at all.

>
> So if you don't want to link the application to ebxml why do you want 
> to link it to the postoffice? I'd like my client to link to a nice, 
> clean and simple API. If JAXM was done right it would have fitted the 
> ebxml messaging/transport layer quite well
>
Post office can be profiled. That means, post office can support 
multiple underlying protocols, e.g. ebXML, RNIF, WS-Reliable Messaging, 
etc. All the client need to master is a single set of APIs.

> We could go even further. It's not about a Business PostOffice, its 
> about Business Processes. Let's give the J2EE specs a ebxml messaging 
> protocol/api first and bother about the higher layers later.
>
We agree with the vision about business process. It's long. Whether or 
not to make ebxml a part of J2EE specs is already a long way to go. I 
would say it's no longer technical, but rather political. :-)

> Last comment:
> I do not want to sound like I disagree with you all, because on a lot 
> of points I don't (at all!) but I get the feeling the "PostOffice" is 
> a nice, clean api to a messaging system? Without the client having 
> knowledge about the underlaying protocols, right?

Yup. We need this kind of discussions to fuel the requirement of our 
further development. Thank you.

Regards, -Patrick

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

> The reason we do this is that not all our clients are always online to 
> retrieve messages. Many have dial-up connections and want the messages 
> pulled as soon as they are online. That is in my opinion what a 
> postoffice is and why I hope multi-hop will be implemented in hermes 
> as wel in the 1.1 release or so (any tips what is still missing or 
> where to start?)
>

We have been reviewing the ebMS 3.0 white paper lately. Whether multihop 
is needed or not is still controversial. In fact, as you can see in ebMS 
2.0 spec, the behaviour of multi-hop feature is not clear. Therefore, I 
think this feature will still be on hold until the ebMS TC gets a 
conclusion on it. :-)

Regards, -Patrick

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Christophe Hartwig-Peillon wrote:

> Hi all,
>
>>        What do you think if the interface between the client and Hermes
>> is Web Service? (Maybe with reliability as well.) In this case, the 
>> client
>> side need not be JMS API call at all while Hermes server need not use
>> a JMS provider and it already sits there to receive HTTP Web Service 
>> call.
>> So far, Hermes does not yet touch the J2EE, JMS features and can be thus
>> deployed in an app server as simple as Jetty that SMEs' may feel a 
>> little
>> bit light-weight.
>>  
>>
> As far as I know, Hermes and the client already rely on an HTTP based 
> protocol... The problem is reliability : when two processes cooperate, 
> you take the risk of having one down (hermes in our case). In this 
> case, the whole system is down...
> Relying on JMS, in the context of an app server, suppresses this problem.
> Another interest of JMS is load balancing/fault tolerance.
> Maybe other free JMS implementations could be used... there are many 
> of them !
>
Another concern is exclusivity of Java world. A postoffice, by its 
nature, does not imply Java. MQSeries does provide JMS interface, but 
JMS is definitely not the only way to access MQ. Some demands we have 
here is to make a postoffice neutual enough to let clients from other 
worlds (e.g. .net) to use it.

> I must confess I have an app server in my system (jBoss, clustered for 
> fault tolerance). Does it mean that the protocol between Hermes and 
> the client should be made pluggable ? This suits the J2EE spirit...
>
Pluggable? Hmm.... do you mean allowing multiple ways for the client to 
connect to Hermes? In the best case, we can find a standard and 
everybody connect to Hermes (and others message servers) in the same 
way. I believe that one day we will have it.

> Anyway, I tried to correlate the kind of architecture hermes could 
> have with requirements for inclusion into J2EE...
> ebXML, with JAXM is out of J2EE.


Afterall, I must confess that it makes sense to include ebXML into J2EE. 
It's enterprise thing.

Regards, -Patrick

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

> Is the application server trust worthy ? it does have DB access 
> control... So the postoffice is not less trust worthy than an 
> application server... And in most cases, communication between client 
> and postoffice would be inter-process... otherwise, JSM over SSL 
> implementations are available.
>
The messaging service is deployed to the application server. We have to 
trust it. But, the postoffice is another process, or in stricter sense, 
another system sitting in the middle between the senders and receivers. 
Therefore, we have good reason not to trust it.

JMS over SSL helps only the confidentiality over the wire. It's tough to 
make sure the postoffice cannot view the confidential part of the 
message. Unless we use XML encryption to encrypt only the secret part, 
and leaving the header part in clear text for routing purpose.

Regards, -Patrick

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Patrick Yee wrote:

> Sorry for late response again.
>
>> 1. I believe there is a need for a postoffice in J2EE. Whether one 
>> implementation of this postoffice uses ebXML is another question :-)
>> However, using JMS queues to link Hermes and the Hermes client would 
>> be cool (as a first step maybe) : IMHO, one weak point of Hermes is 
>> the HTTP transport between the client and the MSH, because when there 
>> is a need for guaranteed delivery, the application has to persist its 
>> own messages before attempting to send them to Hermes, just in case 
>> the delivery is not possible immediately (Hermes down for 
>> instance)... Using JMS, you could simply use JMS reliable messaging 
>> to make sure the message WILL be sent by Hermes.
>>
> Good point. Using JMS, or other reliable service, is the ultimate 
> solution. Currently, the argument to use HTTP is that the Hermes 
> server/Hermes client communication is within a relatively stable 
> network environment, e.g. inside a corporate. In this case, the demand 
> for a error-tolerant channel is lower.

A lightweight ebxml server like hermes provides almost the same 
functionality. A JMS server also has to persist it's messages and the 
only thing you have to do for it is configure a database or filesystem 
(just like in hermes). Just like CY said, a reliable webserivice is 
possible to and that is IMHO what ebxml is. At least the ebxml ms standard

>
>> 2. I believe there would be a need for configurability of the 
>> postoffice (read XML deployment descriptors) like all other J2EE 
>> technologies. Its goal is to redirect incoming message to different 
>> JMS queues depending on... it depends on the protocol, so must be 
>> abstracted :-) ... in the case of ebXML, depending on CPAid, or 
>> fromParty, or toParty, or Service, or Service/Action or a combination...
>>
> Agreed.

But isn't this abstraction exactely what hermes does with you allowing 
to implement your own messagelisteners? The only difference is that 
registering takes place via a http call rather then a config file or a gui

>
>> 3. I believe the important point is that encryption must appear 
>> somewhere within the system boundaries where security is OK. Is 
>> security OK between Postoffice and JMS clients ? Well, its tough to 
>> hack inside an application server (the client could now stand in the 
>> same process as Hermes) ! However, I think I would rather use JMS 
>> headers (instead of ebXML headers) to tell the Postoffice what to do 
>> with messages, because I would not want to link my client application 
>> to ebXML but to the PostOffice... so as to use another protocol if 
>> needed.
>> Regarding end to end security... think of it: is your database 
>> encrypted too ?
>>
> The problem is: is Postoffice trust worthy? I don't think so. The 
> database can only be read by authorized persons through DB access 
> control.

So if you don't want to link the application to ebxml why do you want to 
link it to the postoffice? I'd like my client to link to a nice, clean 
and simple API. If JAXM was done right it would have fitted the ebxml 
messaging/transport layer quite well

>
>> And... whether encryption is required or not depends on the CPA, 
>> which IMHO would be better handled by the postOffice itself... Let's 
>> talk about it.
>> There would be a good match between the CPA (in terms of agreement) 
>> and the tasks of the PostOffice... I mean if I had to implement this 
>> postOffice, I would handle CPAs (and what is related to 
>> communication, encryption, sync-replies or not, reliable messaging or 
>> not, etc...) at the postOffice (well, its ebXML implementation), not 
>> at the "JMS client" level. The JMS client would then need to know 
>> nothing about ebXML (or other protocols !) : just tell the postOffice 
>> where you want the message to go (in abstract terms) and what message 
>> it is (in abstract terms), and the postOffice knows how/where to send 
>> the message... ebXML headers are filled-in at the very last minute, 
>> the application needs not care about ebXML headers anymore...
>>
> Agreed.

Agreed to that extent that the application should not have to worry 
about ebxml headers directly. Values of some headers could be relevant 
to the application, or even provided by the application. Again, a simple 
API like the one for JMS would be enough. The only thing that to me we 
are proposing is shifting some  of the reliabilty issues of ebxml from 
the ebxml level to the transport level. It almost looks as if JMS could 
be the core of ebxml based systems. That is excately why I'd like to see 
the redelivery-timeout, maximum time to live etc be standardized in JMS.

>
>> I believe abstracting ebXML is important... I like ebXML, but I 
>> believe web services have (or will soon have) extensions to make them 
>> appropriate for reliable messaging, ordered delivery, etc... ebXML is 
>> not the only protocol we can think of in terms of B2B communication...
>> IBM has Reliable Messaging specs available for comments... and 
>> business process orchestration... etc...
>> And when your trading partners don't have an ebXML infrastructure 
>> ready, you need to rely on something else !
>>
Currently it is easier to have a ebxml infrastructure ready (hermes?) 
than a standards based webservices b2b system with reliability (oasis 
has another standard for this almost ready!)

>> The J2EE community would better accept ebXML if the specs for 
>> integrating ebXML to J2EE are open to other technologies... Look at 
>> J2EE technologies : they always make abstraction of the actual 
>> implementation... You don't have Tibco support, but you have JMS. You 
>> don't have Tuxedo support, but JCA. You must have PostOffice to have 
>> ebXML support :-)
>
Why? you can imo not compare the differences in tibco/jms or tuxedo/jca 
standards to postoffice/ebxml. All these standards provide is some 
functionality and an api. So we want a standardized API right? Isn't 
this what they tried and failed to with JAXM? Again, Adapting the JMS 
standard so it fits perfectly with the ebxml functionality seems good to me

>>
>> IBM and BEA just announced their work on SDO : an API to work with 
>> data, from XML to RDBMSes, etc... The need for abstraction is 
>> everywhere. We first abstracted the implementations (JMS, JDBC, JCA), 
>> now we abstract the actual nature of things...
>> I'm afraid we can't have ebXML support in J2EE if we don't have a 
>> good abstract spec... which JAXM is not.
>>
>
Agreed. Again, like IBM and others already said, there is a standard for 
messaging in J2EE. It's called JMS.

> We have some negative experience when using JMS, and other J2EE 
> technologies: although the spirit of J2EE technologies is to decouple 
> the abstract programming model and the implementation, it's still not 
> very easy to make easy replacement of actual implementations. That is, 
> when I build a system using J2EE technologies, it's easy for me to 
> fall into the "trap" of the vendors and become locked in. :-)
>
> Do you have any experience to share on this part?
>
The only vendor traps we (deliberately) fell in are redelivery-delay and 
time-to-live functionality in the JMS implementation of Bea. Which IBM, 
JBoss and probably others have also implemented in there JMS 
implementations but each with other parameters because there are not 
standardized (yet) :-(

> Regards, -Patrick
>
>
>> I think JAXM is a bad match for ebXML because it treats ebXML as SOAP 
>> w/Attachment+something, as a protocol and nothing more.
>> ebXML is more than that, it's about B2B communication, 1-n 
>> relatioships, not a 1-1 relationship.
>>
Hmm...
- the ebxml *messaging standard* is soap w/Attachment + something (e.g. 
hidden reliable delivery), so a protocol
- It had a 'simple' way of persisting messages and have them redeliverd 
later (client could use this easily)
- jaxm itself was not 1-1, that was only the ebxml or rpc implementation 
that came with it (correct me if i'm wrong)

>> Don't you think there is a lack in the J2EE specs : there is no spec 
>> yet for "get business messages out of the app server, to my business 
>> partners, and receive messages from them". It's not about a protocol, 
>> it's about a Business PostOffice.
>>
We could go even further. It's not about a Business PostOffice, its 
about Business Processes. Let's give the J2EE specs a ebxml messaging 
protocol/api first and bother about the higher layers later.

Last comment:
I do not want to sound like I disagree with you all, because on a lot of 
points I don't (at all!) but I get the feeling the "PostOffice" is a 
nice, clean api to a messaging system? Without the client having 
knowledge about the underlaying protocols, right?

Ronald

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Ng Chi Yuen [Cyng] wrote:

>Hi,
>
>  
>
>>The point is : would the J2EE JCP comittee accept an implementation
>>(ebXML) which would not rely on a standard (J2EE postoffice ?) to remain
>>abstract ? I don't think so, and I would not either. The second question
>>is: if ebXML is not part of J2EE, does it mean it's not an Enterprise
>>feature ? The answer is definitely no, so a solution must be found !
>>Abstract API is the Java-way solution...
>>    
>>
>
>        What do you think if the interface between the client and Hermes
>is Web Service? (Maybe with reliability as well.) 
>

Hmm.. the only standardized reliable webservice that is currenty 
available is imnsho ebxml (with the emphasis on standardized)

In a pre ebxml 2.0 version of a messaging system, we use a http/soap/xml 
based 'webservices' like protocol with some reliability to get al the 
messages from a 'postoffice'. It provides the functions of
- listInbox (show a list of al wating messages based on some simple 
filters like subject=edi* or something like that)
- getMessage (with a parameter that uniquely identifies a message in the 
list produced by the listInbox)
- ackMessage (with a parameter that uniquely identifies the message 
retrieved in getMessage, so in can be deleted in the central server)
- sendMessage(deliver a ebxml message to the central server, which 
mainly acts like a hub in a multi-hop way)

The reason we do this is that not all our clients are always online to 
retrieve messages. Many have dial-up connections and want the messages 
pulled as soon as they are online. That is in my opinion what a 
postoffice is and why I hope multi-hop will be implemented in hermes as 
wel in the 1.1 release or so (any tips what is still missing or where to 
start?)

A very lightweight client that can do the things mentioned above removes 
the need for an smtp server while providing the same functionality.

Ronald

>In this case, the client
>side need not be JMS API call at all while Hermes server need not use
>a JMS provider and it already sits there to receive HTTP Web Service call.
>So far, Hermes does not yet touch the J2EE, JMS features and can be thus
>deployed in an app server as simple as Jetty that SMEs' may feel a little
>bit light-weight.
>
>Regards,
>CY
>
>  
>

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

[Christophe Hartwig-P. <chr...@re...>]

Hi all,

>        What do you think if the interface between the client and Hermes
>is Web Service? (Maybe with reliability as well.) In this case, the client
>side need not be JMS API call at all while Hermes server need not use
>a JMS provider and it already sits there to receive HTTP Web Service call.
>So far, Hermes does not yet touch the J2EE, JMS features and can be thus
>deployed in an app server as simple as Jetty that SMEs' may feel a little
>bit light-weight.
>  
>
As far as I know, Hermes and the client already rely on an HTTP based 
protocol... The problem is reliability : when two processes cooperate, 
you take the risk of having one down (hermes in our case). In this case, 
the whole system is down...
Relying on JMS, in the context of an app server, suppresses this problem.
Another interest of JMS is load balancing/fault tolerance.
Maybe other free JMS implementations could be used... there are many of 
them !

I must confess I have an app server in my system (jBoss, clustered for 
fault tolerance). Does it mean that the protocol between Hermes and the 
client should be made pluggable ? This suits the J2EE spirit...

Anyway, I tried to correlate the kind of architecture hermes could have 
with requirements for inclusion into J2EE...
ebXML, with JAXM is out of J2EE.

Chris

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Hi,

> The point is : would the J2EE JCP comittee accept an implementation
> (ebXML) which would not rely on a standard (J2EE postoffice ?) to remain
> abstract ? I don't think so, and I would not either. The second question
> is: if ebXML is not part of J2EE, does it mean it's not an Enterprise
> feature ? The answer is definitely no, so a solution must be found !
> Abstract API is the Java-way solution...

        What do you think if the interface between the client and Hermes
is Web Service? (Maybe with reliability as well.) In this case, the client
side need not be JMS API call at all while Hermes server need not use
a JMS provider and it already sits there to receive HTTP Web Service call.
So far, Hermes does not yet touch the J2EE, JMS features and can be thus
deployed in an app server as simple as Jetty that SMEs' may feel a little
bit light-weight.

Regards,
CY

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

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

[Christophe Hartwig-P. <chr...@re...>]

Patrick Yee wrote:

> Good point. Using JMS, or other reliable service, is the ultimate 
> solution. Currently, the argument to use HTTP is that the Hermes 
> server/Hermes client communication is within a relatively stable 
> network environment, e.g. inside a corporate. In this case, the demand 
> for a error-tolerant channel is lower. 

It's a matter of simplicity too : I think Hermes would be simpler to 
implement...

> The problem is: is Postoffice trust worthy? I don't think so. The 
> database can only be read by authorized persons through DB access 
> control. 

Is the application server trust worthy ? it does have DB access 
control... So the postoffice is not less trust worthy than an 
application server... And in most cases, communication between client 
and postoffice would be inter-process... otherwise, JSM over SSL 
implementations are available.

> We have some negative experience when using JMS, and other J2EE 
> technologies: although the spirit of J2EE technologies is to decouple 
> the abstract programming model and the implementation, it's still not 
> very easy to make easy replacement of actual implementations. That is, 
> when I build a system using J2EE technologies, it's easy for me to 
> fall into the "trap" of the vendors and become locked in. :-)
> Do you have any experience to share on this part? 

My experience is a J2EE app I worked on, which we ported from Orion to 
Weblogic to Websphere... quite smoothly. It used EJBs, servlets, JMS, 
XSLT, etc... The porting effort was not 0, but was not unacceptable 
(except for Websphere 3.x).

JMS, JDBC, J2EE, implementations for all these always offer slight 
variations. However, nobody questions the interest of a standard. The 
same approach would probably apply for the postoffice : a standard which 
does not cover everything is better than no standard when it comes to 
porting to another implementation. In the Java world, the protocol has 
never been the standard (even it it inspires standards): the API sets 
the standard.

The point is : would the J2EE JCP comittee accept an implementation 
(ebXML) which would not rely on a standard (J2EE postoffice ?) to remain 
abstract ? I don't think so, and I would not either. The second question 
is: if ebXML is not part of J2EE, does it mean it's not an Enterprise 
feature ? The answer is definitely no, so a solution must be found ! 
Abstract API is the Java-way solution...

Regards,
Chris

Re: [ebxmlms-general] Error when running loopback or monitor.

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

Mark,

I guess the problem occurs when the jwsdp tries to locate the default 
SOAP message factory. This may be due to duplicated saaj*.jar and 
jaxm*.jar. And the classloader of jwsdp may be confused if there are 
multiple copies of the same library. You can try to delete those files 
in either directory and see the effect in a trial-and-error way.. :-) I 
am sorry we are not so familiar with jwsdp, and so we cannot give you a 
direct answer. Thanks.

Regards, -Patrick


MTM Zenhorst wrote:

>Hello,
>
>The Hermes messaging seems to run ok, starts polling and no errors in
>the log files.
>
>The client does give an error when running either the loopback or the
>monitor. Both with the same error...
>
>The error is:
>cannot create request objects.
>hk.hku.cecid.phoenix.message.handler.RequestException: Cannot initialize
>request object: Default message factory cannot be instantiated.
>at hk.hku.cecid.phoenix.message.handler.Request.<init> (Unknown Source)
>at hk.hku.cecid.phoenix.message.handler.Request.<init> (Unknown Source)
>at Loopback.run(Loopback.java:29)
>at Loopback.main(Loopback.java:11)
>
>I cant find the thing that is wrong. versions of the jar files are all
>the same as in the jwsdp.
>
>used software:
>Windows 2k
>jwsdp1.2
>apache 2
>
>I hope somebody can help me with this.
>
>Regards,
>
>Mark Zenhorst
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>ebxmlms-general mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general
>  
>

Re: [ebxmlms-general] Re:Application context - receiving all messages

[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">
HK,<br>
<br>
If I understand that correctly, you are setting up 2 clients, one
called Loopback and the other called Client. And you want to send a
message from LoopBack to Client, right?<br>
<br>
In this case, Loopback will register AppContext as ("A", "B", "C",
"D"), and Client will register as ("*", "*", "*", "*"). Now, a message
comes to the Hermes server, with AppContext as ("A", "B", "C", "D"),
because it is sent by Loopback. It seems that the message matches with
both AppContexts. But Hermes server will resolve to match the more
specific AppContext first, i.e. ("A", "B", "C", "D"). Therefore,
Loopback, instead of Client, will be expected to receive the message.<br>
<br>
Regards, -Patrick<br>
<br>
<br>
Han Kim NGO wrote:<br>
<blockquote type="cite"
 cite="mid004f01c3b9b2$9632e160$aa3...@sd...">
  <meta content="text/html; " http-equiv="Content-Type">
  <meta name="GENERATOR" content="MSHTML 6.00.2800.1276">
  <style></style>
  <div><font size="2" face="Arial">Hi CY,</font></div>
  <div>&nbsp;</div>
  <div><font size="2" face="Arial">Thanks for your answer. I tried the
ApplicationContext("*","*","*","*") and it didn't work out. Here's what
I did. Maybe you can tell me what I did wrong or at least give me a
hint.</font></div>
  <div><font size="2" face="Arial">I&nbsp;made a copy of the LoopBack class
and and renamed it to Client. So the CPAId and others values are still
the same as in the original LoopBack class. I just ask the class to
print the timestamp before sending the message.</font></div>
  <div><font size="2" face="Arial">Then I slightly changed the LoopBack
class by changing the ApplicationContext to ("*","*","*","*") and I
deleted the part that sends a message. (From "AttachmentDataSource ads
..." till "mshReq.send(message);&nbsp;"). I also changed the 10000 value in
the sleep method to 50000 and ask the MessageListener to print the
timestamp.</font></div>
  <div><font size="2" face="Arial">I started the Loopback in one window
and run the Client class in another window.</font></div>
  <div><font size="2" face="Arial">I don't get anything in the LoopBack
window. But when I turn the ApplicationContext to its original value, I
do get an answer in the LoopBack window saying that&nbsp;a message was
received and the timestamp printed in that window is the same as the
one in the client window.</font></div>
  <div><font size="2" face="Arial">That's why I asked is the
("*","*","*","*") was to receive all the messages.</font></div>
  <div><font size="2" face="Arial">Do you see anything wrong in the way
I proceed? Did I miss anything?</font></div>
  <div>&nbsp;</div>
  <div><font size="2" face="Arial">Thanks again for your time.</font></div>
  <div>&nbsp;</div>
  <div><font size="2" face="Arial">Regards,</font></div>
  <div>&nbsp;</div>
  <div><font size="2" face="Arial">HK</font></div>
</blockquote>
<br>
</body>
</html>

Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through JMS

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

Sorry for late response again.

> 1. I believe there is a need for a postoffice in J2EE. Whether one 
> implementation of this postoffice uses ebXML is another question :-)
> However, using JMS queues to link Hermes and the Hermes client would 
> be cool (as a first step maybe) : IMHO, one weak point of Hermes is 
> the HTTP transport between the client and the MSH, because when there 
> is a need for guaranteed delivery, the application has to persist its 
> own messages before attempting to send them to Hermes, just in case 
> the delivery is not possible immediately (Hermes down for instance)... 
> Using JMS, you could simply use JMS reliable messaging to make sure 
> the message WILL be sent by Hermes.
>
Good point. Using JMS, or other reliable service, is the ultimate 
solution. Currently, the argument to use HTTP is that the Hermes 
server/Hermes client communication is within a relatively stable network 
environment, e.g. inside a corporate. In this case, the demand for a 
error-tolerant channel is lower.

> 2. I believe there would be a need for configurability of the 
> postoffice (read XML deployment descriptors) like all other J2EE 
> technologies. Its goal is to redirect incoming message to different 
> JMS queues depending on... it depends on the protocol, so must be 
> abstracted :-) ... in the case of ebXML, depending on CPAid, or 
> fromParty, or toParty, or Service, or Service/Action or a combination...
>
Agreed.

> 3. I believe the important point is that encryption must appear 
> somewhere within the system boundaries where security is OK. Is 
> security OK between Postoffice and JMS clients ? Well, its tough to 
> hack inside an application server (the client could now stand in the 
> same process as Hermes) ! However, I think I would rather use JMS 
> headers (instead of ebXML headers) to tell the Postoffice what to do 
> with messages, because I would not want to link my client application 
> to ebXML but to the PostOffice... so as to use another protocol if needed.
> Regarding end to end security... think of it: is your database 
> encrypted too ?
>
The problem is: is Postoffice trust worthy? I don't think so. The 
database can only be read by authorized persons through DB access control.

> And... whether encryption is required or not depends on the CPA, which 
> IMHO would be better handled by the postOffice itself... Let's talk 
> about it.
> There would be a good match between the CPA (in terms of agreement) 
> and the tasks of the PostOffice... I mean if I had to implement this 
> postOffice, I would handle CPAs (and what is related to communication, 
> encryption, sync-replies or not, reliable messaging or not, etc...) at 
> the postOffice (well, its ebXML implementation), not at the "JMS 
> client" level. The JMS client would then need to know nothing about 
> ebXML (or other protocols !) : just tell the postOffice where you want 
> the message to go (in abstract terms) and what message it is (in 
> abstract terms), and the postOffice knows how/where to send the 
> message... ebXML headers are filled-in at the very last minute, the 
> application needs not care about ebXML headers anymore...
>
Agreed.

> I believe abstracting ebXML is important... I like ebXML, but I 
> believe web services have (or will soon have) extensions to make them 
> appropriate for reliable messaging, ordered delivery, etc... ebXML is 
> not the only protocol we can think of in terms of B2B communication...
> IBM has Reliable Messaging specs available for comments... and 
> business process orchestration... etc...
> And when your trading partners don't have an ebXML infrastructure 
> ready, you need to rely on something else !
>
> The J2EE community would better accept ebXML if the specs for 
> integrating ebXML to J2EE are open to other technologies... Look at 
> J2EE technologies : they always make abstraction of the actual 
> implementation... You don't have Tibco support, but you have JMS. You 
> don't have Tuxedo support, but JCA. You must have PostOffice to have 
> ebXML support :-)
> IBM and BEA just announced their work on SDO : an API to work with 
> data, from XML to RDBMSes, etc... The need for abstraction is 
> everywhere. We first abstracted the implementations (JMS, JDBC, JCA), 
> now we abstract the actual nature of things...
> I'm afraid we can't have ebXML support in J2EE if we don't have a good 
> abstract spec... which JAXM is not.
>

We have some negative experience when using JMS, and other J2EE 
technologies: although the spirit of J2EE technologies is to decouple 
the abstract programming model and the implementation, it's still not 
very easy to make easy replacement of actual implementations. That is, 
when I build a system using J2EE technologies, it's easy for me to fall 
into the "trap" of the vendors and become locked in. :-)

Do you have any experience to share on this part?

Regards, -Patrick


> I think JAXM is a bad match for ebXML because it treats ebXML as SOAP 
> w/Attachment+something, as a protocol and nothing more.
> ebXML is more than that, it's about B2B communication, 1-n 
> relatioships, not a 1-1 relationship.
>
> Don't you think there is a lack in the J2EE specs : there is no spec 
> yet for "get business messages out of the app server, to my business 
> partners, and receive messages from them". It's not about a protocol, 
> it's about a Business PostOffice.
>
> My 2 cents
> Chris
>

[ebxmlms-general] Re: I have a question about MSH...

[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=3Dx-windows-949">
  <title></title>
</head>
<body text=3D"#000000" bgcolor=3D"#ffffff">
Under current Hermes implementation, you need to call
setDuplicateElimination() on the MessageHeader object of the ebXML
message object on a message by message basis.<br>
Regards, -Patrick<br>
P.S. For future discussion, please subscribe ebxmlms-general mailing
list at <a class=3D"moz-txt-link-freetext" href=3D"https://sourceforge.ne=
t/mail/?group_id=3D56612">https://sourceforge.net/mail/?group_id=3D56612<=
/a>. Thanks.<br>
<br>
<br>
=B9=AE=B1=D4=BF=F8 wrote:<br>
<blockquote type=3D"cite"
 cite=3D"mid001401c3c2ff$940a2e10$4b16fdcb@smartmkw">
  <meta content=3D"text/html; " http-equiv=3D"Content-Type">
  <meta name=3D"GENERATOR" content=3D"MSHTML 6.00.2800.1276">
  <style></style>
  <div><font size=3D"2">Hello, My name is kyuwon.</font></div>
  <div>&nbsp;</div>
  <div><font size=3D"2">I would like to set duplicationElimination
"never" or "always" as definition in CPA.</font></div>
  <div>&nbsp;</div>
  <div><font size=3D"2">How do I set the value of dulicationElimination?<=
/font></div>
  <div>&nbsp;</div>
  <div><font size=3D"2">Please answer me..</font></div>
  <div>&nbsp;</div>
  <div><font size=3D"2">Thank you for reading my mail.</font></div>
  <div>&nbsp;</div>
  <div><font size=3D"2">Regards, Kyuwon.</font></div>
</blockquote>
<br>
</body>
</html>

[ebxmlms-general] Error when running loopback or monitor.

[MTM Z. <zen...@fe...>]

Hello,

The Hermes messaging seems to run ok, starts polling and no errors in
the log files.

The client does give an error when running either the loopback or the
monitor. Both with the same error...

The error is:
cannot create request objects.
hk.hku.cecid.phoenix.message.handler.RequestException: Cannot initialize
request object: Default message factory cannot be instantiated.
at hk.hku.cecid.phoenix.message.handler.Request.<init> (Unknown Source)
at hk.hku.cecid.phoenix.message.handler.Request.<init> (Unknown Source)
at Loopback.run(Loopback.java:29)
at Loopback.main(Loopback.java:11)

I cant find the thing that is wrong. versions of the jar files are all
the same as in the jwsdp.

used software:
Windows 2k
jwsdp1.2
apache 2

I hope somebody can help me with this.

Regards,

Mark Zenhorst