ebxmlms-general — General discussions

RE: [ebxmlms-general] freebXML MSH Scalability

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

Ajit,
 
Regarding point 2, I've already tried once to implement this and it
works. Since all j2ee servers support this and even tomcat and jetty
have connectionpool mechanisms, I'm all in favour of using that what is
provided with the appserver/servlet enginge. What I did not try is to
make it configurable to be able to use both solutions. This would
require a DBConnectionPoolInterface. Since hermes uses a combination of
a connection pool and some direct connections, getRawConnection(), I
mapped the implementation of these methods to the connectionpool. 
 
Another thing I was looking at was a real persistency layer (in it's own
package?) as interfaces which would make it possible to also store the
messages in the database as blobs (our ASP does not allow us to store
'things' in a filesystem).
 
Unfortunately I had a major system crash and lost all of this code and
did not start over again... 
 
Failover is also not possible (i think) since the message sending
threads (for retries etc) are created on a restart of the server, so if
one crashes you have to restart the other to have it pick up the
messages.
 
One of the other things (for us) is centralized authentication using an
ldap server where we can manage all users/clients/systems that have
access to the server. I'd like an abstraction layer for this to so we
can implement something that uses the authentication of the application
server / servelet engine (e.g. through jaas)
 
 
Ronald

-----Oorspronkelijk bericht-----
Van: Tripathi, Ajit (GXS) [mailto:Aji...@gx...]
Verzonden: maandag 3 november 2003 11:06
Aan: 'ebx...@li...'
Onderwerp: [ebxmlms-general] freebXML MSH Scalability


Hi,
 
    Hermes MSH is essentially a JAXM servlet with a lot more behind it.
 
    My question is - how does/would hermes scale w.r.t messaging
requirements?
 
    1. Can hermes use administered components such as datasources,
connection pools etc (other than hermes' native connection pools).
    2. What conversational state is preserved in a servlet instance of
hermes MSH? Can different instances of Hermes MSH share the same
underlying resources?
    3. What are the other key considerations w.r.t deploying hermes MSH
in an app server ( e.g. weblogic) cluster?
 
    Has someone experimented with this?
 
regards,
Ajit
 

-----Original Message-----
From: Patrick Yee [mailto:kc...@ce...]
Sent: Thursday, October 30, 2003 7:47 PM
To: ebx...@li...
Subject: Re: [ebxmlms-general] SMTP Port not configurable


Ajit,
Ooops.. you are right. We will include it in our next release. Thanks
for your suggestion.
Regards, -Patrick
 

    By the way, why is the SMTP port not configurable in
msh.properties.xml? 
 
      <SMTP>
        <Host>localhost</Host>
        <User>ajitkt</User>
        <Password>nainital</Password>
      </SMTP>
 

Re: [ebxmlms-general] freebXML MSH Scalability

[Bob K. <py...@ce...>]

I think currently there is no support on scalability on Hermes yet. 
However, now we are designing the 1.0 version of Hermes so that 
scalability will be one of the issues to be considered. Currently I am 
designing the way to support multiple Hermes servlet to run on same 
database.
For administered components you mentioned, can you give me some examples 
so that I can also consider it on the design? Other suggestions on 
Hermes are also welcomed.

Regards,
Bob Koon

Tripathi, Ajit (GXS) wrote:

> Hi,
>  
>     Hermes MSH is essentially a JAXM servlet with a lot more behind it.
>  
>     My question is - how does/would hermes scale w.r.t messaging 
> requirements?
>  
>     1. Can hermes use administered components such as datasources, 
> connection pools etc (other than hermes' native connection pools).
>     2. What conversational state is preserved in a servlet instance of 
> hermes MSH? Can different instances of Hermes MSH share the same 
> underlying resources?
>     3. What are the other key considerations w.r.t deploying hermes 
> MSH in an app server ( e.g. weblogic) cluster?
>  
>     Has someone experimented with this?
>  
> regards,
> Ajit
>  
>
>     -----Original Message-----
>     From: Patrick Yee [mailto:kc...@ce...]
>     Sent: Thursday, October 30, 2003 7:47 PM
>     To: ebx...@li...
>     Subject: Re: [ebxmlms-general] SMTP Port not configurable
>
>     Ajit,
>     Ooops.. you are right. We will include it in our next release.
>     Thanks for your suggestion.
>     Regards, -Patrick
>      
>
>             By the way, why is the SMTP port not configurable in
>         msh.properties.xml?
>          
>               <SMTP>
>                 <Host>localhost</Host>
>                 <User>ajitkt</User>
>                 <Password>nainital</Password>
>               </SMTP>
>          
>

Re: [ebxmlms-general] servlet instance problem

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

Hi,

>> javax.servlet.ServletException: Error instantiating
>> servlet class
>> hk.hku.cecid.phoenix.message.handler.MessageServiceHandler
>>     at
>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:912) 

         I think there are some more lines like "Root cause:....." after 
this stack trace in the tomcat log that may probably tell you the reason why 
it cannot load the servlet.

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] servlet instance problem

[Bob K. <py...@ce...>]

I am sorry that I cannot figure the reason why the servlet cannot be 
loaded. It seems that the MessageServiceHandler fail at a very early 
stage during the loading from tomcat. Would you please help me to check 
the settings on tomcat to see whether it is okay?

Regards,
Bob Koon

asad ghori wrote:

>hello
>am a newbie and start deploying my application
>my environemnt is
>jdk1.4.1
>tomcat LE
>window2000
>oracle 9i DB
>when i deply the msh.war file it's through an
>exception
>even i have removed servlet.jar file from msh.war file
>
>2003-11-04 02:19:04 WebappLoader[/msh]: Deploy JAR
>/WEB-INF/lib/xmlsec.jar to E:\Tomcat
>4.1\bin\..\webapps\msh\WEB-INF\lib\xmlsec.jar
>2003-11-04 02:19:05 StandardManager[/msh]: Seeding
>random number generator class
>java.security.SecureRandom
>2003-11-04 02:19:05 StandardManager[/msh]: Seeding of
>random number generator has been completed
>2003-11-04 02:19:07 StandardWrapper[/msh:default]:
>Loading container servlet default
>2003-11-04 02:19:07 StandardWrapper[/msh:invoker]:
>Loading container servlet invoker
>2003-11-04 02:19:07 StandardWrapper[/msh:msh]: Marking
>servlet msh as unavailable
>2003-11-04 02:19:07 StandardContext[/msh]: Servlet
>/msh threw load() exception
>javax.servlet.ServletException: Error instantiating
>servlet class
>hk.hku.cecid.phoenix.message.handler.MessageServiceHandler
>	at
>org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:912)
>	at
>org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
>	at
>org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3421)
>	at
>org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
>	at
>org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
>	at
>org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
>	at
>org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
>	at
>org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:307)
>	at
>org.apache.catalina.core.StandardHost.install(StandardHost.java:772)
>	at
>org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:492)
>	at
>org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:400)
>	at
>org.apache.catalina.startup.HostConfig.start(HostConfig.java:718)
>	at
>org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:358)
>	at
>org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>	at
>org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196)
>	at
>org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
>	at
>org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
>	at
>org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
>	at
>org.apache.catalina.core.StandardService.start(StandardService.java:497)
>	at
>org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
>	at
>org.apache.catalina.startup.Catalina.start(Catalina.java:512)
>	at
>org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
>	at
>org.apache.catalina.startup.Catalina.process(Catalina.java:180)
>	at
>sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>Method)
>	at
>sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>	at
>sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>	at java.lang.reflect.Method.invoke(Method.java:324)
>	at
>org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
>
>
>sameer
>
>
>__________________________________
>Do you Yahoo!?
>Exclusive Video Premiere - Britney Spears
>http://launch.yahoo.com/promos/britneyspears/
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?   SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>ebxmlms-general mailing list
>ebx...@li...
>https://lists.sourceforge.net/lists/listinfo/ebxmlms-general
>
>  
>

Re: [ebxmlms-general] SMTP Port not configurable

[Bob K. <py...@ce...>]

I have just commit the fix for it on sourceforge. You can check it out 
from sourceforge if you like.
Regards,
Bob Koon

Tripathi, Ajit (GXS) wrote:

> Patrick,
>  
>     Thanks a lot. So far I like what I see ... freebXML msh is 
> significantly simplifying our life down here.
>  
>     By the way, why is the SMTP port not configurable in 
> msh.properties.xml?
>  
>       <SMTP>
>         <Host>localhost</Host>
>         <User>ajitkt</User>
>         <Password>nainital</Password>
>       </SMTP>
>  
>     I am running a freeware smtp server on my machine for testing but 
> port 25 has already been taken by some daemon process (windows)!!! 
> It'd been nice if the port was configurable!
>  
> regards,
> Ajit
>
>     -----Original Message-----
>     From: Patrick Yee [mailto:kc...@ce...]
>     Sent: Thursday, October 30, 2003 7:25 PM
>     To: ebx...@li...
>     Subject: Re: [ebxmlms-general] bundled loopback client: question
>
>     Ajit,
>     We only have those 2 documents at the moment. :-)
>     Regards, -Patrick
>      
>
>             Any other hermes documentation available (other than dev.
>         and install guide) will be very useful!
>          
>

[ebxmlms-general] Re: ERROR [Thread-56]: [10505] Cannot send SOAP message

[Bob K. <py...@ce...>]

If you have any question on Hermes, I will recommend you to subscribe
the mailing lists of Hermes at
http://sourceforge.net/mail/?group_id=56612 . We will try to answer the
problem on the mailing list.
For the problem you asked, I had investigated the problem but I cannot
get out the reason. It seems that the SOAPConnection on JAXM is failed
to be make because the endpoint type is bad (but I cannot see how bad it
is). If you can, help me to check whether you environment on your Unix
is correct that it can access the correct JAXM library.

Regards,
Bob Koon

changgwj wrote:

> Hello ?
> I am a Janggwonjin that live in Korea.
>
> Receive your module in the Internet and is using well.
>
> Module that is using present is no error in NT PC.
>
> By the way,
>
> The error happens if sending Data from UNIX.
>
> I ask reply as send error message.
>
> Thank you .
>
> -----------------------------------------------------------------------------
>
> -------------[msh.log] error Message
> ------------------------------------------
>
> ------------------------------------------------------------------------------
>
> 2003-11-03 13:32:47,620 DEBUG [Thread-55]: => MessageProcessor.run
> 2003-11-03 13:32:47,621 DEBUG [Thread-55]: Send... try #1
> 2003-11-03 13:32:47,623 DEBUG [Thread-55]: => MessageServer.retry
> 2003-11-03 13:32:47,623 DEBUG [Thread-55]: =>
> DbConnectionPool.getConnection
> 2003-11-03 13:32:47,624 DEBUG [Thread-55]: <=
> DbConnectionPool.getConnection
> 2003-11-03 13:32:47,632 DEBUG [Thread-55]: current state: <Started
> Sending> specified state: <Retrying #1>
> 2003-11-03 13:32:47,634 DEBUG [Thread-55]: Update state to become
> <Retrying #1>
> 2003-11-03 13:32:47,642 DEBUG [Thread-55]: <= MessageServer.retry
> 2003-11-03 13:32:47,642 DEBUG [Thread-55]: => Transaction.commit
> (txID: #67)
> 2003-11-03 13:32:47,647 DEBUG [Thread-55]: =>
> DbConnectionPool.freeConnection
> 2003-11-03 13:32:47,647 DEBUG [Thread-55]: <=
> DbConnectionPool.freeConnection
> 2003-11-03 13:32:47,648 DEBUG [Thread-55]: <= Transaction.commit
> 2003-11-03 13:32:47,653 DEBUG [Thread-56]: => HttpSender.run
> 2003-11-03 13:32:47,653 DEBUG [Thread-56]: => HttpServlet.send
> 2003-11-03 13:32:47,654 INFO [Thread-56]: Sending message to
> http://203.235.70.254:7020/ebms/msh
> 2003-11-03 13:32:48,970 ERROR [Thread-56]: [10505] Cannot send SOAP
> message
> Exception: javax.xml.soap.SOAPException
> Message: Bad endPoint type http://203.235.70.254:7020/ebms/msh
> 2003-11-03 13:32:48,972 DEBUG [Thread-56]: => MessageProcessor.wakeUp
> 2003-11-03 13:32:48,973 DEBUG [Thread-56]: <= MessageProcessor.wakeUp
> 2003-11-03 13:32:48,973 DEBUG [Thread-56]: <= HttpSender.run
> 2003-11-03 13:32:48,973 DEBUG [Thread-55]: => MessageServer.logSentMessage
> 2003-11-03 13:32:48,974 DEBUG [Thread-55]: =>
> DbConnectionPool.getConnection
> 2003-11-03 13:32:48,974 DEBUG [Thread-55]: <=
> DbConnectionPool.getConnection
> 2003-11-03 13:32:48,982 DEBUG [Thread-55]: <= MessageServer.logSentMessage
> 2003-11-03 13:32:48,982 DEBUG [Thread-55]: => Transaction.commit
> (txID: #68)
> 2003-11-03 13:32:48,986 DEBUG [Thread-55]: =>
> DbConnectionPool.freeConnection
> 2003-11-03 13:32:48,986 DEBUG [Thread-55]: <=
> DbConnectionPool.freeConnection
> 2003-11-03 13:32:48,986 DEBUG [Thread-55]: <= Transaction.commit
> 2003-11-03 13:32:48,987 DEBUG [Thread-55]:
> hk.hku.cecid.phoenix.message.handler.HttpSender cannot send message
> successfully for 1 ti
> mes: [10505] Cannot send SOAP message
> 2003-11-03 13:32:48,987 DEBUG [Thread-55]: =>
> MessageProcessor.generateError
> 2003-11-03 13:32:49,015 DEBUG [Thread-55]: final sequence number in
> store: -9998
> 2003-11-03 13:32:49,015 DEBUG [Thread-55]: => MessageServer.store
> 2003-11-03 13:32:49,016 DEBUG [Thread-55]: =>
> ................messageId=20031103-043248995-banca.03.N08.real.urn:bancassurance.Batch
> .23@42.1.51.12 <mailto:.23@42.1.51.12>..........
> 2003-11-03 13:32:49,016 DEBUG [Thread-55]: =>
> ................refToMessageId=20031103-043243630-banca.03.N08.real.urn:bancassurance.
> Batch.1@42.1.51.12 <mailto:Batch.1@42.1.51.12>..........
> 2003-11-03 13:32:49,016 DEBUG [Thread-55]: insert into reftomessage
> database
> 2003-11-03 13:32:49,017 DEBUG [Thread-55]: =>
> DbConnectionPool.getConnection
> 2003-11-03 13:32:49,017 DEBUG [Thread-55]: <=
> DbConnectionPool.getConnection
> 2003-11-03 13:32:49,025 DEBUG [Thread-55]: => DirectoryManager.store
> 2003-11-03 13:32:49,026 DEBUG [Thread-55]: =>
> DirectoryManager.getRepositoryFileName
>
>
>

[ebxmlms-general] freebXML MSH Scalability

[Tripathi, A. (GXS) <Aji...@gx...>]

Hi,
 
    Hermes MSH is essentially a JAXM servlet with a lot more behind it.
 
    My question is - how does/would hermes scale w.r.t messaging
requirements?
 
    1. Can hermes use administered components such as datasources,
connection pools etc (other than hermes' native connection pools).
    2. What conversational state is preserved in a servlet instance of
hermes MSH? Can different instances of Hermes MSH share the same underlying
resources?
    3. What are the other key considerations w.r.t deploying hermes MSH in
an app server ( e.g. weblogic) cluster?
 
    Has someone experimented with this?
 
regards,
Ajit
 

-----Original Message-----
From: Patrick Yee [mailto:kc...@ce...]
Sent: Thursday, October 30, 2003 7:47 PM
To: ebx...@li...
Subject: Re: [ebxmlms-general] SMTP Port not configurable


Ajit,
Ooops.. you are right. We will include it in our next release. Thanks for
your suggestion.
Regards, -Patrick
 

    By the way, why is the SMTP port not configurable in msh.properties.xml?

 
      <SMTP>
        <Host>localhost</Host>
        <User>ajitkt</User>
        <Password>nainital</Password>
      </SMTP>
 

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

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

Hi all,

I've been thinking more about it this week end... Here is a new approach 
to the problem:
There is no specification in J2EE concerning messages that should get 
out of the system.
JMS only concerns sending messages reliably to a queue. Even JMS bridges 
simply allow sending messages to a queue and forwarding to an external 
queue (JSM to Tibco bridge for instance)... There is no way to take JSM 
messages out !

What we need is a JMS postoffice ! That's why the match between JMS and 
ebXML is not easy : ebXML is a distribution (in the sense of mail 
distribution) protocol.

What would be cool is to think in terms of an ebXML postoffice. When you 
want to send snail mail, you post your letter in a mailbox, except this 
mailbox is then emptied by the postman, and the mail is dispatched.
Internal mail (in a company) does not go through a postoffice, you put 
the letter in you recepient's mailbox : that's JMS...

ebXML actually determines the distribution : to whom should the messages 
be delivered, should a receipt be expected, should the message be 
signed, should the message use the HTTP or SMTP path (remember the 
AirMail stickers on letters ?), should a return address be used for 
replying, etc...
I like this approach because :
- everybody now understands the difference between JMS and ebXML goals
- the need for ebXML is obvious
- the lack of an existing standard is obvious too
- the mismatch of JAXM and these goals is obvious (because JAXM does not 
try to play this postoffice role, does not have postoffice semantics)
- the fact that JMS and ebXML are related is clear : JMS is for posting 
the letter, ebXML is sending it in the right place. ebXML is receiving 
the mail from the postoffice, JSM is for opening and reading the letter...
- CPAs are used to tell the postoffice what it should do, how the 
message can reach its recepient, etc...

Do you like it this way ?

I like the idea of a JSR... Because ebXML is now different than JMS (but 
related to it!), is not about reliable messaging, but about inter-system 
reliable routing and sending of messages... This is a functional area 
not yet covered by other Java specifications, so there should be some 
place for it... Note that there are JSRs related to CPPs/CPAs already...

I'm eager to hear your opinion !
Bye
Chris

---------------------------------------------------------------------
 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
--------------------------------------------------------------------- 

[ebxmlms-general] servlet instance problem

[asad g. <asa...@ya...>]

hello
am a newbie and start deploying my application
my environemnt is
jdk1.4.1
tomcat LE
window2000
oracle 9i DB
when i deply the msh.war file it's through an
exception
even i have removed servlet.jar file from msh.war file

2003-11-04 02:19:04 WebappLoader[/msh]: Deploy JAR
/WEB-INF/lib/xmlsec.jar to E:\Tomcat
4.1\bin\..\webapps\msh\WEB-INF\lib\xmlsec.jar
2003-11-04 02:19:05 StandardManager[/msh]: Seeding
random number generator class
java.security.SecureRandom
2003-11-04 02:19:05 StandardManager[/msh]: Seeding of
random number generator has been completed
2003-11-04 02:19:07 StandardWrapper[/msh:default]:
Loading container servlet default
2003-11-04 02:19:07 StandardWrapper[/msh:invoker]:
Loading container servlet invoker
2003-11-04 02:19:07 StandardWrapper[/msh:msh]: Marking
servlet msh as unavailable
2003-11-04 02:19:07 StandardContext[/msh]: Servlet
/msh threw load() exception
javax.servlet.ServletException: Error instantiating
servlet class
hk.hku.cecid.phoenix.message.handler.MessageServiceHandler
	at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:912)
	at
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:823)
	at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3421)
	at
org.apache.catalina.core.StandardContext.start(StandardContext.java:3609)
	at
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:821)
	at
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:807)
	at
org.apache.catalina.core.StandardHost.addChild(StandardHost.java:579)
	at
org.apache.catalina.core.StandardHostDeployer.install(StandardHostDeployer.java:307)
	at
org.apache.catalina.core.StandardHost.install(StandardHost.java:772)
	at
org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:492)
	at
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:400)
	at
org.apache.catalina.startup.HostConfig.start(HostConfig.java:718)
	at
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:358)
	at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1196)
	at
org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
	at
org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
	at
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
	at
org.apache.catalina.core.StandardService.start(StandardService.java:497)
	at
org.apache.catalina.core.StandardServer.start(StandardServer.java:2190)
	at
org.apache.catalina.startup.Catalina.start(Catalina.java:512)
	at
org.apache.catalina.startup.Catalina.execute(Catalina.java:400)
	at
org.apache.catalina.startup.Catalina.process(Catalina.java:180)
	at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
	at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:324)
	at
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)


sameer


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

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

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

Frankie Lam wrote:

>Sounds like an interesting thread =)
>
>I believe that using JMS API as the standard API is a great idea; it allows
>developers that have JMS experience to use ebXML messaging facility
>immediately. It should be a lot better than designing another set of
>standard API for ebXML messaging.
>  
>
The JMS api is a fairly technical  one. Creating  factories, session, 
working with acknowledgements  is not what you want an 'end-user' to 
have to do. It could (should?) be simpeler.  Especially things the way 
acknowledgements work in a JMS session is not  realy nice in the way 
that you cannot process multiple messages and just acknowledge the ones 
you want to. I you acknowledge one, all previous ones are achknowledged. 
JAXM as an api is to me not much more that "SOAP+". I'm curious to what 
the API's will look like for WS-Reliability (WS-ReliableMessaging?) etc...

>As Patrick said, currently the biggest problem is mapping the
>ebxmlms-specific functions to JMS API. Creating a new JSR for JMS 2.0 to
>cater for the features that are supported by ebXML MS is hard and
>time-consuming. 
>

I didn't say it would be easy ;-) but I think we could get BEA, someone 
from JBoss and maybe even oracle to join in and within a year it could 
be done (don't call it JMS 2.0 then but rather 1.x since otherwise there 
is the risk for a full redesign that is not nessecary now)

>Moreover, when JMS 2.0 is available, the messaging service
>specification may reach 3.0 / 4.0 already =) 
>
Naaahhh... 3.0 will not be that different i think. Not in functionality 
it won't. If there are some ws-* standards then for security (hmm how 
would that fit in??) and reliability probably those  will be used then. 
(kind of like a WS-I ebXML-MS profile)

>So there will always be a
>mismatch between the functionality provided by JMS and ebXML MS.
>
>  
>
I agree, I therefor see more in  using JMS to implement some things for 
ebXML (queueing (with persistency), retries etc)  instead of using the 
API in the front. JAXM doesn't fit either. It's to general.  I do not 
fully  agree with  IBM et.al  that there should be only one api for 
messaging.  JMS itself has its purpose, just like ebXML has. btw, there 
are several api's for DOM manipulation (dom, dom4j, jdom etc...) If done 
right, giving ebxml MS it's own (simple!!) API would not be bad at all.

>I am no JMS expert (or even a beginner). But would it be better if we
>implement JMS API using ebxml MS, while allowing the users to take advantage
>of ebxmlms-specific functionalities by setting some provider-specific
>properties?
>  
>
Using the same API but implementing a new JMS provider? Don't know. I 
think that on that level there are to many incompatibilities. Beginning 
with the queues (are they the paryID's?)  MsgID's beeing generated by 
the provider etc... I see more in a simple bug good ebxml-ms specific 
api and for those who want it implement it on top of JMS.

>Frankie
>
>----- Original Message ----- 
>From: "Ronald van Kuijk" <rv...@ab...>
>To: <ebx...@li...>
>Sent: Sunday, November 02, 2003 1:39 AM
>Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through
>JMS
>
>
>  
>
>>Hi all,
>>
>>After some real busy weeks I finally got back to working with/on Hermes
>>again.
>>
>>I love this new discussion for several reasons and totally agree with
>>Patrick.  Nice to see some new people with good ideas on this mailinglist.
>>
>>Using JMS with some extentions as the basis for an api for ebMS could
>>prove interesting since at least three (afaik) JMS servers, the ones
>>that come with Websphere, Bea and JBoss support some extentions on JMS
>>that make it even easier to implement  a ebMS backend based on JMS. They
>>support time-to-live, retry-interval and maximum number of retries. And
>>last, but certainly not least, for HA/Failover one could use the
>>functionality provided by the JMS servers to achieve this.
>>
>>I'd therefor love to see the JMS specs get to version 2.0 (or 1.3 or
>>whatever) and have the ttl, retry-interval and number of retries in that
>>new spec. Hmmm....I almost start thinking of creating a new JSR within
>>the JCP for JMS2.0 specs. The similarityies go even further. JMS has an
>>defined property called JMSXGroupID en JMSXGroupSeq. There is however no
>>defined functionality for these properties and why not specify in the
>>JMS specs that they should be used for orderd delivery when present.
>>
>>I'm currently looking into the possibility of using the packaging etc
>>from Hermes and use JMS with MDB's or MessageListeners (not sure which
>>one to use yet) as the processing layer. All of this on JBoss,
>>unfortunately currently without failover.
>>
>>Ronald
>>
>>
>>
>>Patrick Yee wrote:
>>
>>    
>>
>>>Chris & Ajit,
>>>
>>>Thanks. I mean we long for this kind of discussions so as to make
>>>ebXML messaging more usable.
>>>
>>>Personally, I like JMS too. The good thing is that it decouples the
>>>application logic with the choice of MOM provider. If I am a hard core
>>>open source supporter, I can use JBoss. Or if I become rich later, I
>>>can buy a MQ. This concept is proven to be useful, so we all can see
>>>the success of JDBC and JNDI.
>>>
>>>Obviously we need the same in ebXML messaging. Theorectically by
>>>conforming to the spec, MSHs are interoperable. But still,
>>>applications are not permitted to switch the vendor of MSH if the
>>>interface between MSH and application is proprietary to the MSH. This
>>>is a sad thing especially when we compare this with the successful
>>>JDBC and JNDI.
>>>
>>>JAXM seems to be the one we need. But it's not that easy to map to the
>>>function of ebXML MS. So you mentioned JMS, which is a widely accepted
>>>API standard. However, I would say that it's not easy to map to ebXML
>>>MS too. Implementing a JMS provider is not an easy task, especially
>>>because the mapping between JMS functions and ebXML MS functions is
>>>not intuitive.
>>>
>>>So Chris's idea is cool. However, afterall it's still proprietary.
>>>What we need is a commonly accepted API, endorsed by most MSH vendors.
>>>We agreed very much with Ajit's point as well. Java is all we need.
>>>Many MSHs are written in Java, that's perfectly fine. But that doesn't
>>>mean that the backend application that "uses" MSH should be in Java too.
>>>
>>>To sum up, we need a common ebMS API. And we need an API which is
>>>endorsed by MSH vendors. At the end, it's not purely technical. It's
>>>not going to be easy, but we see no choice.
>>>
>>>Lastly, we are forming a group which gathers people with the same
>>>vision to work that out. If you are interested, please send us an email.
>>>
>>>Sorry for the long mail. Happy Halloween!
>>>
>>>Regards, -Patrick
>>>
>>>
>>>
>>>    ----- Original Message -----
>>>    *From:* Tripathi, Ajit (GXS) <mailto:Aji...@gx...>
>>>    *To:* 'ebx...@li...'
>>>    <mailto:%27e...@li...%27>
>>>    *Sent:* Friday, October 31, 2003 6:41 PM
>>>    *Subject:* RE: [ebxmlms-general] idea : use ebXML to bridge the
>>>    gap, through JMS
>>>
>>>    Chris,
>>>
>>>        I see what you are saying ... you are not alone ...  BEA and
>>>    IBM don't want to see two different messaging models in J2EE
>>>    either, one for MDBs and another for JAXM. Hence, JAXM was voted
>>>    out of J2EE. However, XML/SOAP over HTTP can't be replaced by
>>>    XML/SOAP over JMS.
>>>
>>>        However, ebXML is in no way restricted by the choice of
>>>    messaging. You may want to use ebXML over a synchronous
>>>    messaging protocol, as much as you can use it with HTTP, SMTP,
>>>    JAXM and JMS. Hence common JMS features need to be reinvented by
>>>    MSHs. ebXML cares about what _services _an MSH provides. How it
>>>    does that is in a large degree, left to MSHs.
>>>
>>>         Implementation independence is a goal for a very good reason
>>>    - ebXML without interoperability would be useless.  Never forget
>>>    Microsoft - Java isn't the only thing in the integration world.
>>>
>>>    regards,
>>>    Ajit
>>>
>>>        -----Original Message-----
>>>        *From:* Christophe Hartwig-Peillon
>>>        [mailto:chr...@re...]
>>>        *Sent:* Friday, October 31, 2003 3:50 PM
>>>        *To:* ebx...@li...
>>>        *Subject:* Re: [ebxmlms-general] idea : use ebXML to bridge
>>>        the gap, through JMS
>>>
>>>        Hi,
>>>
>>>        I'm not talking about using JMS as the transport... It's the
>>>        opposite : I'm talking about using JMS as the API and
>>>        architecture, and using ebXML over (choose your favorite
>>>        transport) for the encoding and transport.
>>>
>>>        ebXML wants to be independant (of transport, apis, etc...) :
>>>        the net result is lack of adoption, lack of integration.
>>>        ebXML is not considered a "solution", just an encoding :-(
>>>
>>>        If sending an ebXML message was as easy as sending a JMS
>>>        message with a toParty header, and receiving an ebXML message
>>>        was as easy as writing a message bean, ebXML would be easier
>>>        to adopt !
>>>
>>>        I tend to think of ebXML as an encoding for MOM semantics. JMS
>>>        has no encoding protocol : JMS assumes the transport layer
>>>        also takes care of the encoding. The protocol stack would be,
>>>        from top to bottom :
>>>        - JMS
>>>        - ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME
>>>        mini-stack)
>>>        - HTTP, SMTP, or whatever protocol the MSH could support
>>>
>>>        If you prefer : ebXML is needed, because we need an XML
>>>        encoding which preserves MOM semantics, for easy
>>>        interoperability, but JAXM is useless, since we already have
>>>        MOM apis...
>>>
>>>        Until now, interoperability was not the primary goal of JMS :
>>>        JMS made the interop possible, since no assumption was made on
>>>        encoding or transport. The result is that, except for JSM
>>>        bridges (for Tibco or MQSeries), interop is weak ! Using ebXML
>>>        as the encoding, and HTTP/SMTP the transport could make JMS
>>>        interop possible.
>>>        JMS-JMS interop would be great, but the fact that ebXML is API
>>>        agnostic is even better : it would allow anyone with HTTP/SMTP
>>>        libraries and an XML parser to send messages to your JMS
>>>        server ! It would allow JAXM - JMS interop, and commercial
>>>        ebXML implementations - JMS interop...
>>>
>>>        I think JMS is *the* MOM API for J2EE, not JAXM...
>>>        And ebXML should be *the* interoperable encoding for MOM
>>>        implementations.
>>>
>>>        But I don't recommend implementing a JMS provider on top of
>>>        Hermes : one solution is the use of an existing JMS
>>>        implementation, and the implementation of the ebXML layer as a
>>>        JMS client...
>>>        A servlet can wait for ebXML messages, create a temp queue for
>>>        the reply, send the ebXML message to a JMS queue...
>>>        Message Beans can handle messages, and post their reply to the
>>>        reply-to queue.
>>>        The servlet can then send the response (it was blocking on the
>>>        temps queue until now)...
>>>
>>>        To send an ebXML message, you'll just post the payload and
>>>        some JMS headers (like the recepient of the message) to a JMS
>>>        queue...
>>>        A queue listener will then build the ebXML message and send
>>>        it, using some of the JMS message headers for the ebXML
>>>        header... The ebXML implementation could take care of signing,
>>>        choosing the right transport, etc... the ebXML layer would be
>>>        focused on what is does best : interop !
>>>
>>>        JMS will take care of acknoledgement, transaction support,
>>>        persistence, etc...
>>>        The MSH will just be a relay !
>>>        That's one possible implementation (well, deep thinking is
>>>        needed here, I admit :-)...
>>>
>>>        Another one would be to take an existing JMS implementation
>>>        (like JBoss'es), and add an ebXML/HTTP and ebXML/SMTP
>>>        transport. This implementation would work only for that JMS
>>>        implementation, but might offer greater support for MOM
>>>        semantics (because it would be linked with the implementation
>>>        of the JMS server)...
>>>
>>>        I know all of this is heretic, since JAXM exists and is an
>>>        endorsed standard... but sometimes standards die, sometimes
>>>        they are abandonned... I would prefer to see JAXM die instead
>>>        of ebXML : we need ebXML !
>>>        Chris
>>>
>>>        Tripathi, Ajit (GXS) wrote:
>>>
>>>      
>>>
>>>>        Chris,
>>>>
>>>>                The ebXML messaging spec (ebMS2) seeks to be
>>>>        independent of application transport. As per the spec, JMS
>>>>        can be incorporated into msh products, alongwith http and
>>>>        smtp but that is an implementation decision.
>>>>
>>>>                Clearly, messaging is only one aspect of ebXML. The
>>>>        spec broadly seeks to enable business processes between
>>>>        trading partners using XML (vis-a-vis EDI) . However,
>>>>        inter-enterprise collaboration requires much more
>>>>        sophisticated messaging than SOAP spec accounts for.
>>>>
>>>>                While ebXML messaging is built on top of SOAP-Attach,
>>>>        security and reliability are two key messaging requirements
>>>>        not mentioned in the set of specs known as "web-services".
>>>>        ebXML also seeks to bridge that gap through msh.
>>>>
>>>>        regards,
>>>>        Ajot
>>>>
>>>>        -----Original Message-----
>>>>        From: Christophe Hartwig-Peillon
>>>>        [mailto:chr...@re...]
>>>>        Sent: Friday, October 31, 2003 2:19 PM
>>>>        To: ebx...@li...
>>>>        Subject: [ebxmlms-general] idea : use ebXML to bridge the
>>>>        gap, through
>>>>        JMS
>>>>
>>>>
>>>>        Hi all,
>>>>
>>>>        At the beginning, I considered ebXML as an alternative to Web
>>>>        Services...
>>>>        But this mistake was due to my lack of understanding.
>>>>
>>>>        My understanding now is that ebXML is a MOM protocol, but
>>>>        this kind of
>>>>        assertion is found nowhere, hence the ambiguity with Web
>>>>        Services. So
>>>>        assertions like "Web services will take over ebXML" are just
>>>>        plain
>>>>        nonsense : you can't compare MOM with RPC.
>>>>        Then JAXM has added its load of ambiguity, since it has added
>>>>        one more
>>>>        API in the Java world, despite the existence of a proven API
>>>>        for MOMs,
>>>>        JMS...
>>>>
>>>>        Don't you think that there would be a place in the ebXML for
>>>>        a JMS based
>>>>        implementation of ebXML MSH for its encoding and transport ?
>>>>        I can imagine implementing ebXML on top of an existing JMS
>>>>        implementation would make things easier : JMS already has
>>>>        reliable
>>>>        messaging semantics, and already offers transactional
>>>>        
>>>>
>persistent
>  
>
>>>>        messages, etc... Many features of Hermes are already
>>>>        supported by JMS
>>>>        implementations... And JMS supports temporary queues (and
>>>>        reply-to) for
>>>>        request-response messages... And JMS already offers Message
>>>>        Beans
>>>>        integration... and JMS is most often clusterable... and ... I
>>>>        like that
>>>>        idea :-)
>>>>
>>>>        I think such an implementation would make the use of ebXML
>>>>        simpler,
>>>>        better integrated with J2EE environments, would reduce the
>>>>        learning
>>>>        curve, would make ebXML an obvious choice for reliable
>>>>        messaging...
>>>>
>>>>        Your thoughts ?
>>>>
>>>>        Bye
>>>>        Chris
>>>>
>>>>        PS : I think my idea means a new implementation, not just an
>>>>        adaptation
>>>>        of Hermes...
>>>>
>>>>        
>>>>

[ebxmlms-general] time-to-live wrong format error

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

Hi,

I'm playing a little with time-to-live from the monitor application. 
When I send a message with a time-to-live of 1d (one day) which is of 
course in the wrong format. I get a nice error message back with a 
"ValueNotRecognized" error:

    <eb:ErrorList 
xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" 
soap-env:mustUnderstand="1" eb:version="2.0" eb:highestSeverity="Error">
      <eb:Error eb:errorCode="ValueNotRecognized" eb:severity="Error">
        <eb:Description xml:lang="en-US">
          Value cannot be parsed / recognized
        </eb:Description>
      </eb:Error>
    </eb:ErrorList>

IMHO there are two things wrong with this error. The long description of 
"ValueNotRecognized"  according to the specs is:

Although the document is well formed and valid, the element/ attribute 
contains a value that could not be recognized and therefore could not be 
used by the ebXML Message Service.

According to the ebxml-ms schema type of TimeToLive is dateTime:

    <element name="TimeToLive" type="dateTime"/>

But... all the long descriptions in the ebxml specs mention "well formed 
and valid". Probably because they expect a schema-check to have taken 
place before the document will be parsed by an MSH.  So I do not know 
what is the correct error to return in a situation like this.  So making 
the error more specific and/or including the location in the form of an 
xpath statement.

But shouldn't we also do a validation check before sending out the 
message? Since the error comes back from the MSH, the creation of the 
message in the Monitor probably does not include a validation of the 
message. I think we should include at least one of these (use the 
location in the error, or validate the message on creation) . The code 
that generates the message is in MessageServiceHandler.java:

            if (ttlString != null) {
                final Date timestamp = Utility.fromUTCString(ttlString);
                EbxmlMessage errorMessage = null;

                if (timestamp == null) {
                    String err = ErrorMessages.getMessage(
                        ErrorMessages.ERR_HERMES_DATA_ERROR,
                        "cannot recognize TTL value in message");
                    logger.warn(err);
                    errorMessage = generateErrorMessage
                        (ebxmlMessage, ErrorList.CODE_VALUE_NOT_RECOGNIZED,
                         ErrorList.SEVERITY_ERROR,
                         "Value cannot be parsed / recognized");
                }

I think we should use the errorstring  (err, or at least the 
"cannot.....message" part) be used instead of the "Value cannot be 
parsed / recognized" or the other signature of generateErrorMessage 
which includes the location?

Ronald

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

[Frankie L. <fr...@mi...>]

Sounds like an interesting thread =)

I believe that using JMS API as the standard API is a great idea; it allows
developers that have JMS experience to use ebXML messaging facility
immediately. It should be a lot better than designing another set of
standard API for ebXML messaging.

As Patrick said, currently the biggest problem is mapping the
ebxmlms-specific functions to JMS API. Creating a new JSR for JMS 2.0 to
cater for the features that are supported by ebXML MS is hard and
time-consuming. Moreover, when JMS 2.0 is available, the messaging service
specification may reach 3.0 / 4.0 already =) So there will always be a
mismatch between the functionality provided by JMS and ebXML MS.

I am no JMS expert (or even a beginner). But would it be better if we
implement JMS API using ebxml MS, while allowing the users to take advantage
of ebxmlms-specific functionalities by setting some provider-specific
properties?

Frankie

----- Original Message ----- 
From: "Ronald van Kuijk" <rv...@ab...>
To: <ebx...@li...>
Sent: Sunday, November 02, 2003 1:39 AM
Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through
JMS


>
> Hi all,
>
> After some real busy weeks I finally got back to working with/on Hermes
> again.
>
> I love this new discussion for several reasons and totally agree with
> Patrick.  Nice to see some new people with good ideas on this mailinglist.
>
> Using JMS with some extentions as the basis for an api for ebMS could
> prove interesting since at least three (afaik) JMS servers, the ones
> that come with Websphere, Bea and JBoss support some extentions on JMS
> that make it even easier to implement  a ebMS backend based on JMS. They
> support time-to-live, retry-interval and maximum number of retries. And
> last, but certainly not least, for HA/Failover one could use the
> functionality provided by the JMS servers to achieve this.
>
> I'd therefor love to see the JMS specs get to version 2.0 (or 1.3 or
> whatever) and have the ttl, retry-interval and number of retries in that
> new spec. Hmmm....I almost start thinking of creating a new JSR within
> the JCP for JMS2.0 specs. The similarityies go even further. JMS has an
> defined property called JMSXGroupID en JMSXGroupSeq. There is however no
> defined functionality for these properties and why not specify in the
> JMS specs that they should be used for orderd delivery when present.
>
> I'm currently looking into the possibility of using the packaging etc
> from Hermes and use JMS with MDB's or MessageListeners (not sure which
> one to use yet) as the processing layer. All of this on JBoss,
> unfortunately currently without failover.
>
> Ronald
>
>
>
> Patrick Yee wrote:
>
> > Chris & Ajit,
> >
> > Thanks. I mean we long for this kind of discussions so as to make
> > ebXML messaging more usable.
> >
> > Personally, I like JMS too. The good thing is that it decouples the
> > application logic with the choice of MOM provider. If I am a hard core
> > open source supporter, I can use JBoss. Or if I become rich later, I
> > can buy a MQ. This concept is proven to be useful, so we all can see
> > the success of JDBC and JNDI.
> >
> > Obviously we need the same in ebXML messaging. Theorectically by
> > conforming to the spec, MSHs are interoperable. But still,
> > applications are not permitted to switch the vendor of MSH if the
> > interface between MSH and application is proprietary to the MSH. This
> > is a sad thing especially when we compare this with the successful
> > JDBC and JNDI.
> >
> > JAXM seems to be the one we need. But it's not that easy to map to the
> > function of ebXML MS. So you mentioned JMS, which is a widely accepted
> > API standard. However, I would say that it's not easy to map to ebXML
> > MS too. Implementing a JMS provider is not an easy task, especially
> > because the mapping between JMS functions and ebXML MS functions is
> > not intuitive.
> >
> > So Chris's idea is cool. However, afterall it's still proprietary.
> > What we need is a commonly accepted API, endorsed by most MSH vendors.
> > We agreed very much with Ajit's point as well. Java is all we need.
> > Many MSHs are written in Java, that's perfectly fine. But that doesn't
> > mean that the backend application that "uses" MSH should be in Java too.
> >
> > To sum up, we need a common ebMS API. And we need an API which is
> > endorsed by MSH vendors. At the end, it's not purely technical. It's
> > not going to be easy, but we see no choice.
> >
> > Lastly, we are forming a group which gathers people with the same
> > vision to work that out. If you are interested, please send us an email.
> >
> > Sorry for the long mail. Happy Halloween!
> >
> > Regards, -Patrick
> >
> >
> >
> >     ----- Original Message -----
> >     *From:* Tripathi, Ajit (GXS) <mailto:Aji...@gx...>
> >     *To:* 'ebx...@li...'
> >     <mailto:%27e...@li...%27>
> >     *Sent:* Friday, October 31, 2003 6:41 PM
> >     *Subject:* RE: [ebxmlms-general] idea : use ebXML to bridge the
> >     gap, through JMS
> >
> >     Chris,
> >
> >         I see what you are saying ... you are not alone ...  BEA and
> >     IBM don't want to see two different messaging models in J2EE
> >     either, one for MDBs and another for JAXM. Hence, JAXM was voted
> >     out of J2EE. However, XML/SOAP over HTTP can't be replaced by
> >     XML/SOAP over JMS.
> >
> >         However, ebXML is in no way restricted by the choice of
> >     messaging. You may want to use ebXML over a synchronous
> >     messaging protocol, as much as you can use it with HTTP, SMTP,
> >     JAXM and JMS. Hence common JMS features need to be reinvented by
> >     MSHs. ebXML cares about what _services _an MSH provides. How it
> >     does that is in a large degree, left to MSHs.
> >
> >          Implementation independence is a goal for a very good reason
> >     - ebXML without interoperability would be useless.  Never forget
> >     Microsoft - Java isn't the only thing in the integration world.
> >
> >     regards,
> >     Ajit
> >
> >         -----Original Message-----
> >         *From:* Christophe Hartwig-Peillon
> >         [mailto:chr...@re...]
> >         *Sent:* Friday, October 31, 2003 3:50 PM
> >         *To:* ebx...@li...
> >         *Subject:* Re: [ebxmlms-general] idea : use ebXML to bridge
> >         the gap, through JMS
> >
> >         Hi,
> >
> >         I'm not talking about using JMS as the transport... It's the
> >         opposite : I'm talking about using JMS as the API and
> >         architecture, and using ebXML over (choose your favorite
> >         transport) for the encoding and transport.
> >
> >         ebXML wants to be independant (of transport, apis, etc...) :
> >         the net result is lack of adoption, lack of integration.
> >         ebXML is not considered a "solution", just an encoding :-(
> >
> >         If sending an ebXML message was as easy as sending a JMS
> >         message with a toParty header, and receiving an ebXML message
> >         was as easy as writing a message bean, ebXML would be easier
> >         to adopt !
> >
> >         I tend to think of ebXML as an encoding for MOM semantics. JMS
> >         has no encoding protocol : JMS assumes the transport layer
> >         also takes care of the encoding. The protocol stack would be,
> >         from top to bottom :
> >         - JMS
> >         - ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME
> >         mini-stack)
> >         - HTTP, SMTP, or whatever protocol the MSH could support
> >
> >         If you prefer : ebXML is needed, because we need an XML
> >         encoding which preserves MOM semantics, for easy
> >         interoperability, but JAXM is useless, since we already have
> >         MOM apis...
> >
> >         Until now, interoperability was not the primary goal of JMS :
> >         JMS made the interop possible, since no assumption was made on
> >         encoding or transport. The result is that, except for JSM
> >         bridges (for Tibco or MQSeries), interop is weak ! Using ebXML
> >         as the encoding, and HTTP/SMTP the transport could make JMS
> >         interop possible.
> >         JMS-JMS interop would be great, but the fact that ebXML is API
> >         agnostic is even better : it would allow anyone with HTTP/SMTP
> >         libraries and an XML parser to send messages to your JMS
> >         server ! It would allow JAXM - JMS interop, and commercial
> >         ebXML implementations - JMS interop...
> >
> >         I think JMS is *the* MOM API for J2EE, not JAXM...
> >         And ebXML should be *the* interoperable encoding for MOM
> >         implementations.
> >
> >         But I don't recommend implementing a JMS provider on top of
> >         Hermes : one solution is the use of an existing JMS
> >         implementation, and the implementation of the ebXML layer as a
> >         JMS client...
> >         A servlet can wait for ebXML messages, create a temp queue for
> >         the reply, send the ebXML message to a JMS queue...
> >         Message Beans can handle messages, and post their reply to the
> >         reply-to queue.
> >         The servlet can then send the response (it was blocking on the
> >         temps queue until now)...
> >
> >         To send an ebXML message, you'll just post the payload and
> >         some JMS headers (like the recepient of the message) to a JMS
> >         queue...
> >         A queue listener will then build the ebXML message and send
> >         it, using some of the JMS message headers for the ebXML
> >         header... The ebXML implementation could take care of signing,
> >         choosing the right transport, etc... the ebXML layer would be
> >         focused on what is does best : interop !
> >
> >         JMS will take care of acknoledgement, transaction support,
> >         persistence, etc...
> >         The MSH will just be a relay !
> >         That's one possible implementation (well, deep thinking is
> >         needed here, I admit :-)...
> >
> >         Another one would be to take an existing JMS implementation
> >         (like JBoss'es), and add an ebXML/HTTP and ebXML/SMTP
> >         transport. This implementation would work only for that JMS
> >         implementation, but might offer greater support for MOM
> >         semantics (because it would be linked with the implementation
> >         of the JMS server)...
> >
> >         I know all of this is heretic, since JAXM exists and is an
> >         endorsed standard... but sometimes standards die, sometimes
> >         they are abandonned... I would prefer to see JAXM die instead
> >         of ebXML : we need ebXML !
> >         Chris
> >
> >         Tripathi, Ajit (GXS) wrote:
> >
> >>         Chris,
> >>
> >>                 The ebXML messaging spec (ebMS2) seeks to be
> >>         independent of application transport. As per the spec, JMS
> >>         can be incorporated into msh products, alongwith http and
> >>         smtp but that is an implementation decision.
> >>
> >>                 Clearly, messaging is only one aspect of ebXML. The
> >>         spec broadly seeks to enable business processes between
> >>         trading partners using XML (vis-a-vis EDI) . However,
> >>         inter-enterprise collaboration requires much more
> >>         sophisticated messaging than SOAP spec accounts for.
> >>
> >>                 While ebXML messaging is built on top of SOAP-Attach,
> >>         security and reliability are two key messaging requirements
> >>         not mentioned in the set of specs known as "web-services".
> >>         ebXML also seeks to bridge that gap through msh.
> >>
> >>         regards,
> >>         Ajot
> >>
> >>         -----Original Message-----
> >>         From: Christophe Hartwig-Peillon
> >>         [mailto:chr...@re...]
> >>         Sent: Friday, October 31, 2003 2:19 PM
> >>         To: ebx...@li...
> >>         Subject: [ebxmlms-general] idea : use ebXML to bridge the
> >>         gap, through
> >>         JMS
> >>
> >>
> >>         Hi all,
> >>
> >>         At the beginning, I considered ebXML as an alternative to Web
> >>         Services...
> >>         But this mistake was due to my lack of understanding.
> >>
> >>         My understanding now is that ebXML is a MOM protocol, but
> >>         this kind of
> >>         assertion is found nowhere, hence the ambiguity with Web
> >>         Services. So
> >>         assertions like "Web services will take over ebXML" are just
> >>         plain
> >>         nonsense : you can't compare MOM with RPC.
> >>         Then JAXM has added its load of ambiguity, since it has added
> >>         one more
> >>         API in the Java world, despite the existence of a proven API
> >>         for MOMs,
> >>         JMS...
> >>
> >>         Don't you think that there would be a place in the ebXML for
> >>         a JMS based
> >>         implementation of ebXML MSH for its encoding and transport ?
> >>         I can imagine implementing ebXML on top of an existing JMS
> >>         implementation would make things easier : JMS already has
> >>         reliable
> >>         messaging semantics, and already offers transactional
persistent
> >>         messages, etc... Many features of Hermes are already
> >>         supported by JMS
> >>         implementations... And JMS supports temporary queues (and
> >>         reply-to) for
> >>         request-response messages... And JMS already offers Message
> >>         Beans
> >>         integration... and JMS is most often clusterable... and ... I
> >>         like that
> >>         idea :-)
> >>
> >>         I think such an implementation would make the use of ebXML
> >>         simpler,
> >>         better integrated with J2EE environments, would reduce the
> >>         learning
> >>         curve, would make ebXML an obvious choice for reliable
> >>         messaging...
> >>
> >>         Your thoughts ?
> >>
> >>         Bye
> >>         Chris
> >>
> >>         PS : I think my idea means a new implementation, not just an
> >>         adaptation
> >>         of Hermes...
> >>
>
  ---------------------------------------------------------------------
> >
> > Christophe HARTWIG - Interface Technologies   cha...@re...
> > 17, avenue Andre Roussin                    http://www.reservit.com
> > ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
> > 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
> >--------------------------------------------------------------------- 
> >
> >
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> 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...>]

Hi all,

After some real busy weeks I finally got back to working with/on Hermes 
again.

I love this new discussion for several reasons and totally agree with 
Patrick.  Nice to see some new people with good ideas on this mailinglist.

Using JMS with some extentions as the basis for an api for ebMS could 
prove interesting since at least three (afaik) JMS servers, the ones 
that come with Websphere, Bea and JBoss support some extentions on JMS 
that make it even easier to implement  a ebMS backend based on JMS. They 
support time-to-live, retry-interval and maximum number of retries. And 
last, but certainly not least, for HA/Failover one could use the 
functionality provided by the JMS servers to achieve this.

I'd therefor love to see the JMS specs get to version 2.0 (or 1.3 or 
whatever) and have the ttl, retry-interval and number of retries in that 
new spec. Hmmm....I almost start thinking of creating a new JSR within 
the JCP for JMS2.0 specs. The similarityies go even further. JMS has an 
defined property called JMSXGroupID en JMSXGroupSeq. There is however no 
defined functionality for these properties and why not specify in the 
JMS specs that they should be used for orderd delivery when present.

I'm currently looking into the possibility of using the packaging etc 
from Hermes and use JMS with MDB's or MessageListeners (not sure which 
one to use yet) as the processing layer. All of this on JBoss, 
unfortunately currently without failover.

Ronald



Patrick Yee wrote:

> Chris & Ajit,
>  
> Thanks. I mean we long for this kind of discussions so as to make 
> ebXML messaging more usable.
>  
> Personally, I like JMS too. The good thing is that it decouples the 
> application logic with the choice of MOM provider. If I am a hard core 
> open source supporter, I can use JBoss. Or if I become rich later, I 
> can buy a MQ. This concept is proven to be useful, so we all can see 
> the success of JDBC and JNDI.
>  
> Obviously we need the same in ebXML messaging. Theorectically by 
> conforming to the spec, MSHs are interoperable. But still, 
> applications are not permitted to switch the vendor of MSH if the 
> interface between MSH and application is proprietary to the MSH. This 
> is a sad thing especially when we compare this with the successful 
> JDBC and JNDI.
>  
> JAXM seems to be the one we need. But it's not that easy to map to the 
> function of ebXML MS. So you mentioned JMS, which is a widely accepted 
> API standard. However, I would say that it's not easy to map to ebXML 
> MS too. Implementing a JMS provider is not an easy task, especially 
> because the mapping between JMS functions and ebXML MS functions is 
> not intuitive.
>  
> So Chris's idea is cool. However, afterall it's still proprietary. 
> What we need is a commonly accepted API, endorsed by most MSH vendors. 
> We agreed very much with Ajit's point as well. Java is all we need. 
> Many MSHs are written in Java, that's perfectly fine. But that doesn't 
> mean that the backend application that "uses" MSH should be in Java too.
>  
> To sum up, we need a common ebMS API. And we need an API which is 
> endorsed by MSH vendors. At the end, it's not purely technical. It's 
> not going to be easy, but we see no choice.
>  
> Lastly, we are forming a group which gathers people with the same 
> vision to work that out. If you are interested, please send us an email.
>  
> Sorry for the long mail. Happy Halloween!
>  
> Regards, -Patrick
>  
>  
>
>     ----- Original Message -----
>     *From:* Tripathi, Ajit (GXS) <mailto:Aji...@gx...>
>     *To:* 'ebx...@li...'
>     <mailto:%27e...@li...%27>
>     *Sent:* Friday, October 31, 2003 6:41 PM
>     *Subject:* RE: [ebxmlms-general] idea : use ebXML to bridge the
>     gap, through JMS
>
>     Chris,
>      
>         I see what you are saying ... you are not alone ...  BEA and
>     IBM don't want to see two different messaging models in J2EE
>     either, one for MDBs and another for JAXM. Hence, JAXM was voted
>     out of J2EE. However, XML/SOAP over HTTP can't be replaced by
>     XML/SOAP over JMS.
>      
>         However, ebXML is in no way restricted by the choice of
>     messaging. You may want to use ebXML over a synchronous
>     messaging protocol, as much as you can use it with HTTP, SMTP,
>     JAXM and JMS. Hence common JMS features need to be reinvented by
>     MSHs. ebXML cares about what _services _an MSH provides. How it
>     does that is in a large degree, left to MSHs.
>      
>          Implementation independence is a goal for a very good reason
>     - ebXML without interoperability would be useless.  Never forget
>     Microsoft - Java isn't the only thing in the integration world.
>      
>     regards,
>     Ajit
>
>         -----Original Message-----
>         *From:* Christophe Hartwig-Peillon
>         [mailto:chr...@re...]
>         *Sent:* Friday, October 31, 2003 3:50 PM
>         *To:* ebx...@li...
>         *Subject:* Re: [ebxmlms-general] idea : use ebXML to bridge
>         the gap, through JMS
>
>         Hi,
>
>         I'm not talking about using JMS as the transport... It's the
>         opposite : I'm talking about using JMS as the API and
>         architecture, and using ebXML over (choose your favorite
>         transport) for the encoding and transport.
>
>         ebXML wants to be independant (of transport, apis, etc...) :
>         the net result is lack of adoption, lack of integration.
>         ebXML is not considered a "solution", just an encoding :-(
>
>         If sending an ebXML message was as easy as sending a JMS
>         message with a toParty header, and receiving an ebXML message
>         was as easy as writing a message bean, ebXML would be easier
>         to adopt !
>
>         I tend to think of ebXML as an encoding for MOM semantics. JMS
>         has no encoding protocol : JMS assumes the transport layer
>         also takes care of the encoding. The protocol stack would be,
>         from top to bottom :
>         - JMS
>         - ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME
>         mini-stack)
>         - HTTP, SMTP, or whatever protocol the MSH could support
>
>         If you prefer : ebXML is needed, because we need an XML
>         encoding which preserves MOM semantics, for easy
>         interoperability, but JAXM is useless, since we already have
>         MOM apis...
>
>         Until now, interoperability was not the primary goal of JMS :
>         JMS made the interop possible, since no assumption was made on
>         encoding or transport. The result is that, except for JSM
>         bridges (for Tibco or MQSeries), interop is weak ! Using ebXML
>         as the encoding, and HTTP/SMTP the transport could make JMS
>         interop possible.
>         JMS-JMS interop would be great, but the fact that ebXML is API
>         agnostic is even better : it would allow anyone with HTTP/SMTP
>         libraries and an XML parser to send messages to your JMS
>         server ! It would allow JAXM - JMS interop, and commercial
>         ebXML implementations - JMS interop...
>
>         I think JMS is *the* MOM API for J2EE, not JAXM...
>         And ebXML should be *the* interoperable encoding for MOM
>         implementations.
>
>         But I don't recommend implementing a JMS provider on top of
>         Hermes : one solution is the use of an existing JMS
>         implementation, and the implementation of the ebXML layer as a
>         JMS client...
>         A servlet can wait for ebXML messages, create a temp queue for
>         the reply, send the ebXML message to a JMS queue...
>         Message Beans can handle messages, and post their reply to the
>         reply-to queue.
>         The servlet can then send the response (it was blocking on the
>         temps queue until now)...
>
>         To send an ebXML message, you'll just post the payload and
>         some JMS headers (like the recepient of the message) to a JMS
>         queue...
>         A queue listener will then build the ebXML message and send
>         it, using some of the JMS message headers for the ebXML
>         header... The ebXML implementation could take care of signing,
>         choosing the right transport, etc... the ebXML layer would be
>         focused on what is does best : interop !
>
>         JMS will take care of acknoledgement, transaction support,
>         persistence, etc...
>         The MSH will just be a relay !
>         That's one possible implementation (well, deep thinking is
>         needed here, I admit :-)...
>
>         Another one would be to take an existing JMS implementation
>         (like JBoss'es), and add an ebXML/HTTP and ebXML/SMTP
>         transport. This implementation would work only for that JMS
>         implementation, but might offer greater support for MOM
>         semantics (because it would be linked with the implementation
>         of the JMS server)...
>
>         I know all of this is heretic, since JAXM exists and is an
>         endorsed standard... but sometimes standards die, sometimes
>         they are abandonned... I would prefer to see JAXM die instead
>         of ebXML : we need ebXML !
>         Chris
>
>         Tripathi, Ajit (GXS) wrote:
>
>>         Chris,
>>
>>                 The ebXML messaging spec (ebMS2) seeks to be
>>         independent of application transport. As per the spec, JMS
>>         can be incorporated into msh products, alongwith http and
>>         smtp but that is an implementation decision.
>>
>>                 Clearly, messaging is only one aspect of ebXML. The
>>         spec broadly seeks to enable business processes between
>>         trading partners using XML (vis-a-vis EDI) . However,
>>         inter-enterprise collaboration requires much more
>>         sophisticated messaging than SOAP spec accounts for.
>>
>>                 While ebXML messaging is built on top of SOAP-Attach,
>>         security and reliability are two key messaging requirements
>>         not mentioned in the set of specs known as "web-services".
>>         ebXML also seeks to bridge that gap through msh.
>>
>>         regards,
>>         Ajot
>>
>>         -----Original Message-----
>>         From: Christophe Hartwig-Peillon
>>         [mailto:chr...@re...]
>>         Sent: Friday, October 31, 2003 2:19 PM
>>         To: ebx...@li...
>>         Subject: [ebxmlms-general] idea : use ebXML to bridge the
>>         gap, through
>>         JMS
>>
>>
>>         Hi all,
>>
>>         At the beginning, I considered ebXML as an alternative to Web
>>         Services...
>>         But this mistake was due to my lack of understanding.
>>
>>         My understanding now is that ebXML is a MOM protocol, but
>>         this kind of
>>         assertion is found nowhere, hence the ambiguity with Web
>>         Services. So
>>         assertions like "Web services will take over ebXML" are just
>>         plain
>>         nonsense : you can't compare MOM with RPC.
>>         Then JAXM has added its load of ambiguity, since it has added
>>         one more
>>         API in the Java world, despite the existence of a proven API
>>         for MOMs,
>>         JMS...
>>
>>         Don't you think that there would be a place in the ebXML for
>>         a JMS based
>>         implementation of ebXML MSH for its encoding and transport ?
>>         I can imagine implementing ebXML on top of an existing JMS
>>         implementation would make things easier : JMS already has
>>         reliable
>>         messaging semantics, and already offers transactional persistent
>>         messages, etc... Many features of Hermes are already
>>         supported by JMS
>>         implementations... And JMS supports temporary queues (and
>>         reply-to) for
>>         request-response messages... And JMS already offers Message
>>         Beans
>>         integration... and JMS is most often clusterable... and ... I
>>         like that
>>         idea :-)
>>
>>         I think such an implementation would make the use of ebXML
>>         simpler,
>>         better integrated with J2EE environments, would reduce the
>>         learning
>>         curve, would make ebXML an obvious choice for reliable
>>         messaging...
>>
>>         Your thoughts ?
>>
>>         Bye
>>         Chris
>>
>>         PS : I think my idea means a new implementation, not just an
>>         adaptation
>>         of Hermes...
>>
>         ---------------------------------------------------------------------
>
> Christophe HARTWIG - Interface Technologies   cha...@re...
> 17, avenue Andre Roussin                    http://www.reservit.com
> ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
> 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
>--------------------------------------------------------------------- 
>      
>

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

[Ganga S. <gan...@ya...>]

I would agree with Patrick that it would not be easy
to replace JAXM(as used in Hermes) with JMS API but it
should be possible to add JMS as a tranport in
addition to currently existing transports of HTTP and
MAIL, although ebXML MSH may not be specifc about usng
JMS as alternative transport. Apache
Axis(JAX-RPC/SOAP) has added support to use JMS
transport in addition to HTTP,MAIL etc.
thanks,
ganga
--- Patrick Yee <kc...@ce...> wrote:
> Chris & Ajit,
> 
> Thanks. I mean we long for this kind of discussions
> so as to make ebXML messaging more usable.
> 
> Personally, I like JMS too. The good thing is that
> it decouples the application logic with the choice
> of MOM provider. If I am a hard core open source
> supporter, I can use JBoss. Or if I become rich
> later, I can buy a MQ. This concept is proven to be
> useful, so we all can see the success of JDBC and
> JNDI.
> 
> Obviously we need the same in ebXML messaging.
> Theorectically by conforming to the spec, MSHs are
> interoperable. But still, applications are not
> permitted to switch the vendor of MSH if the
> interface between MSH and application is proprietary
> to the MSH. This is a sad thing especially when we
> compare this with the successful JDBC and JNDI.
> 
> JAXM seems to be the one we need. But it's not that
> easy to map to the function of ebXML MS. So you
> mentioned JMS, which is a widely accepted API
> standard. However, I would say that it's not easy to
> map to ebXML MS too. Implementing a JMS provider is
> not an easy task, especially because the mapping
> between JMS functions and ebXML MS functions is not
> intuitive.
> 
> So Chris's idea is cool. However, afterall it's
> still proprietary. What we need is a commonly
> accepted API, endorsed by most MSH vendors. We
> agreed very much with Ajit's point as well. Java is
> all we need. Many MSHs are written in Java, that's
> perfectly fine. But that doesn't mean that the
> backend application that "uses" MSH should be in
> Java too.
> 
> To sum up, we need a common ebMS API. And we need an
> API which is endorsed by MSH vendors. At the end,
> it's not purely technical. It's not going to be
> easy, but we see no choice. 
> 
> Lastly, we are forming a group which gathers people
> with the same vision to work that out. If you are
> interested, please send us an email.
> 
> Sorry for the long mail. Happy Halloween!
> 
> Regards, -Patrick
> 
> 
>   ----- Original Message ----- 
>   From: Tripathi, Ajit (GXS) 
>   To: 'ebx...@li...' 
>   Sent: Friday, October 31, 2003 6:41 PM
>   Subject: RE: [ebxmlms-general] idea : use ebXML to
> bridge the gap, through JMS
> 
> 
>   Chris,
> 
>       I see what you are saying ... you are not
> alone ...  BEA and IBM don't want to see two
> different messaging models in J2EE either, one for
> MDBs and another for JAXM. Hence, JAXM was voted out
> of J2EE. However, XML/SOAP over HTTP can't be
> replaced by XML/SOAP over JMS.
> 
>       However, ebXML is in no way restricted by the
> choice of messaging. You may want to use ebXML over
> a synchronous messaging protocol, as much as you can
> use it with HTTP, SMTP, JAXM and JMS. Hence common
> JMS features need to be reinvented by MSHs. ebXML
> cares about what services an MSH provides. How it
> does that is in a large degree, left to MSHs.
> 
>        Implementation independence is a goal for a
> very good reason - ebXML without interoperability
> would be useless.  Never forget Microsoft - Java
> isn't the only thing in the integration world.
> 
>   regards,
>   Ajit
>     -----Original Message-----
>     From: Christophe Hartwig-Peillon
> [mailto:chr...@re...]
>     Sent: Friday, October 31, 2003 3:50 PM
>     To: ebx...@li...
>     Subject: Re: [ebxmlms-general] idea : use ebXML
> to bridge the gap, through JMS
> 
> 
>     Hi,
> 
>     I'm not talking about using JMS as the
> transport... It's the opposite : I'm talking about
> using JMS as the API and architecture, and using
> ebXML over (choose your favorite transport) for the
> encoding and transport.
> 
>     ebXML wants to be independant (of transport,
> apis, etc...) : the net result is lack of adoption,
> lack of integration. 
>     ebXML is not considered a "solution", just an
> encoding :-(
> 
>     If sending an ebXML message was as easy as
> sending a JMS message with a toParty header, and
> receiving an ebXML message was as easy as writing a
> message bean, ebXML would be easier to adopt !
> 
>     I tend to think of ebXML as an encoding for MOM
> semantics. JMS has no encoding protocol : JMS
> assumes the transport layer also takes care of the
> encoding. The protocol stack would be, from top to
> bottom :
>     - JMS
>     - ebXML encoding of MOM semantics (ie. ebXML /
> SOAP w/A / MIME mini-stack)
>     - HTTP, SMTP, or whatever protocol the MSH could
> support
> 
>     If you prefer : ebXML is needed, because we need
> an XML encoding which preserves MOM semantics, for
> easy interoperability, but JAXM is useless, since we
> already have MOM apis...
> 
>     Until now, interoperability was not the primary
> goal of JMS : JMS made the interop possible, since
> no assumption was made on encoding or transport. The
> result is that, except for JSM bridges (for Tibco or
> MQSeries), interop is weak ! Using ebXML as the
> encoding, and HTTP/SMTP the transport could make JMS
> interop possible.
>     JMS-JMS interop would be great, but the fact
> that ebXML is API agnostic is even better : it would
> allow anyone with HTTP/SMTP libraries and an XML
> parser to send messages to your JMS server ! It
> would allow JAXM - JMS interop, and commercial ebXML
> implementations - JMS interop...
> 
>     I think JMS is *the* MOM API for J2EE, not
> JAXM...
>     And ebXML should be *the* interoperable encoding
> for MOM implementations.
> 
>     But I don't recommend implementing a JMS
> provider on top of Hermes : one solution is the use
> of an existing JMS implementation, and the
> implementation of the ebXML layer as a JMS client...
>     A servlet can wait for ebXML messages, create a
> temp queue for the reply, send the ebXML message to
> a JMS queue...
>     Message Beans can handle messages, and post
> their reply to the reply-to queue.
>     The servlet can then send the response (it was
> blocking on the temps queue until now)...
> 
>     To send an ebXML message, you'll just post the
> payload and some JMS headers (like the recepient of
> the message) to a JMS queue...
>     A queue listener will then build the ebXML
> message and send it, using some of the JMS message
> headers for the ebXML header... The ebXML
> implementation could take care of signing, choosing
> the right transport, etc... the ebXML layer would be
> focused on what is does best : interop !
> 
>     JMS will take care of acknoledgement,
> transaction support, persistence, etc...
>     The MSH will just be a relay !
>     That's one possible implementation (well, deep
> thinking is needed here, I admit :-)... 
> 
>     Another one would be to take an existing JMS
> implementation (like JBoss'es), and add an
> ebXML/HTTP and ebXML/SMTP transport. This
> implementation would work only for that JMS
> implementation, but might offer greater support for
> MOM semantics (because it would be linked with the
> implementation of the JMS server)...
> 
>     I know all of this is heretic, since JAXM exists
> and is an endorsed standard... but sometimes
> standards die, sometimes they are abandonned... I
> would prefer to see JAXM die instead of ebXML : we
> need ebXML !
>     Chris
> 
>     Tripathi, Ajit (GXS) wrote:
> 
>       Chris, 
> 
>               The ebXML messaging spec (ebMS2) seeks
> to be independent of application transport. As per
> the spec, JMS can be incorporated into msh products,
> alongwith http and smtp but that is an
> implementation decision. 
> 
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

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

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

Chris & Ajit,

Thanks. I mean we long for this kind of discussions so as to make ebXML =
messaging more usable.

Personally, I like JMS too. The good thing is that it decouples the =
application logic with the choice of MOM provider. If I am a hard core =
open source supporter, I can use JBoss. Or if I become rich later, I can =
buy a MQ. This concept is proven to be useful, so we all can see the =
success of JDBC and JNDI.

Obviously we need the same in ebXML messaging. Theorectically by =
conforming to the spec, MSHs are interoperable. But still, applications =
are not permitted to switch the vendor of MSH if the interface between =
MSH and application is proprietary to the MSH. This is a sad thing =
especially when we compare this with the successful JDBC and JNDI.

JAXM seems to be the one we need. But it's not that easy to map to the =
function of ebXML MS. So you mentioned JMS, which is a widely accepted =
API standard. However, I would say that it's not easy to map to ebXML MS =
too. Implementing a JMS provider is not an easy task, especially because =
the mapping between JMS functions and ebXML MS functions is not =
intuitive.

So Chris's idea is cool. However, afterall it's still proprietary. What =
we need is a commonly accepted API, endorsed by most MSH vendors. We =
agreed very much with Ajit's point as well. Java is all we need. Many =
MSHs are written in Java, that's perfectly fine. But that doesn't mean =
that the backend application that "uses" MSH should be in Java too.

To sum up, we need a common ebMS API. And we need an API which is =
endorsed by MSH vendors. At the end, it's not purely technical. It's not =
going to be easy, but we see no choice.=20

Lastly, we are forming a group which gathers people with the same vision =
to work that out. If you are interested, please send us an email.

Sorry for the long mail. Happy Halloween!

Regards, -Patrick


  ----- Original Message -----=20
  From: Tripathi, Ajit (GXS)=20
  To: 'ebx...@li...'=20
  Sent: Friday, October 31, 2003 6:41 PM
  Subject: RE: [ebxmlms-general] idea : use ebXML to bridge the gap, =
through JMS


  Chris,

      I see what you are saying ... you are not alone ...  BEA and IBM =
don't want to see two different messaging models in J2EE either, one for =
MDBs and another for JAXM. Hence, JAXM was voted out of J2EE. However, =
XML/SOAP over HTTP can't be replaced by XML/SOAP over JMS.

      However, ebXML is in no way restricted by the choice of messaging. =
You may want to use ebXML over a synchronous messaging protocol, as much =
as you can use it with HTTP, SMTP, JAXM and JMS. Hence common JMS =
features need to be reinvented by MSHs. ebXML cares about what services =
an MSH provides. How it does that is in a large degree, left to MSHs.

       Implementation independence is a goal for a very good reason - =
ebXML without interoperability would be useless.  Never forget Microsoft =
- Java isn't the only thing in the integration world.

  regards,
  Ajit
    -----Original Message-----
    From: Christophe Hartwig-Peillon [mailto:chr...@re...]
    Sent: Friday, October 31, 2003 3:50 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, =
through JMS


    Hi,

    I'm not talking about using JMS as the transport... It's the =
opposite : I'm talking about using JMS as the API and architecture, and =
using ebXML over (choose your favorite transport) for the encoding and =
transport.

    ebXML wants to be independant (of transport, apis, etc...) : the net =
result is lack of adoption, lack of integration.=20
    ebXML is not considered a "solution", just an encoding :-(

    If sending an ebXML message was as easy as sending a JMS message =
with a toParty header, and receiving an ebXML message was as easy as =
writing a message bean, ebXML would be easier to adopt !

    I tend to think of ebXML as an encoding for MOM semantics. JMS has =
no encoding protocol : JMS assumes the transport layer also takes care =
of the encoding. The protocol stack would be, from top to bottom :
    - JMS
    - ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME =
mini-stack)
    - HTTP, SMTP, or whatever protocol the MSH could support

    If you prefer : ebXML is needed, because we need an XML encoding =
which preserves MOM semantics, for easy interoperability, but JAXM is =
useless, since we already have MOM apis...

    Until now, interoperability was not the primary goal of JMS : JMS =
made the interop possible, since no assumption was made on encoding or =
transport. The result is that, except for JSM bridges (for Tibco or =
MQSeries), interop is weak ! Using ebXML as the encoding, and HTTP/SMTP =
the transport could make JMS interop possible.
    JMS-JMS interop would be great, but the fact that ebXML is API =
agnostic is even better : it would allow anyone with HTTP/SMTP libraries =
and an XML parser to send messages to your JMS server ! It would allow =
JAXM - JMS interop, and commercial ebXML implementations - JMS =
interop...

    I think JMS is *the* MOM API for J2EE, not JAXM...
    And ebXML should be *the* interoperable encoding for MOM =
implementations.

    But I don't recommend implementing a JMS provider on top of Hermes : =
one solution is the use of an existing JMS implementation, and the =
implementation of the ebXML layer as a JMS client...
    A servlet can wait for ebXML messages, create a temp queue for the =
reply, send the ebXML message to a JMS queue...
    Message Beans can handle messages, and post their reply to the =
reply-to queue.
    The servlet can then send the response (it was blocking on the temps =
queue until now)...

    To send an ebXML message, you'll just post the payload and some JMS =
headers (like the recepient of the message) to a JMS queue...
    A queue listener will then build the ebXML message and send it, =
using some of the JMS message headers for the ebXML header... The ebXML =
implementation could take care of signing, choosing the right transport, =
etc... the ebXML layer would be focused on what is does best : interop !

    JMS will take care of acknoledgement, transaction support, =
persistence, etc...
    The MSH will just be a relay !
    That's one possible implementation (well, deep thinking is needed =
here, I admit :-)...=20

    Another one would be to take an existing JMS implementation (like =
JBoss'es), and add an ebXML/HTTP and ebXML/SMTP transport. This =
implementation would work only for that JMS implementation, but might =
offer greater support for MOM semantics (because it would be linked with =
the implementation of the JMS server)...

    I know all of this is heretic, since JAXM exists and is an endorsed =
standard... but sometimes standards die, sometimes they are =
abandonned... I would prefer to see JAXM die instead of ebXML : we need =
ebXML !
    Chris

    Tripathi, Ajit (GXS) wrote:

      Chris,=20

              The ebXML messaging spec (ebMS2) seeks to be independent =
of application transport. As per the spec, JMS can be incorporated into =
msh products, alongwith http and smtp but that is an implementation =
decision.=20

              Clearly, messaging is only one aspect of ebXML. The spec =
broadly seeks to enable business processes between trading partners =
using XML (vis-a-vis EDI) . However, inter-enterprise collaboration =
requires much more sophisticated messaging than SOAP spec accounts for.=20

              While ebXML messaging is built on top of SOAP-Attach, =
security and reliability are two key messaging requirements not =
mentioned in the set of specs known as "web-services". ebXML also seeks =
to bridge that gap through msh.

      regards,=20
      Ajot=20

      -----Original Message-----=20
      From: Christophe Hartwig-Peillon [mailto:chr...@re...]=20
      Sent: Friday, October 31, 2003 2:19 PM=20
      To: ebx...@li...=20
      Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, =
through=20
      JMS=20



      Hi all,=20

      At the beginning, I considered ebXML as an alternative to Web =
Services...=20
      But this mistake was due to my lack of understanding.=20

      My understanding now is that ebXML is a MOM protocol, but this =
kind of=20
      assertion is found nowhere, hence the ambiguity with Web Services. =
So=20
      assertions like "Web services will take over ebXML" are just plain =

      nonsense : you can't compare MOM with RPC.=20
      Then JAXM has added its load of ambiguity, since it has added one =
more=20
      API in the Java world, despite the existence of a proven API for =
MOMs,=20
      JMS...=20

      Don't you think that there would be a place in the ebXML for a JMS =
based=20
      implementation of ebXML MSH for its encoding and transport ?=20
      I can imagine implementing ebXML on top of an existing JMS=20
      implementation would make things easier : JMS already has reliable =

      messaging semantics, and already offers transactional persistent=20
      messages, etc... Many features of Hermes are already supported by =
JMS=20
      implementations... And JMS supports temporary queues (and =
reply-to) for=20
      request-response messages... And JMS already offers Message Beans=20
      integration... and JMS is most often clusterable... and ... I like =
that=20
      idea :-)=20

      I think such an implementation would make the use of ebXML =
simpler,=20
      better integrated with J2EE environments, would reduce the =
learning=20
      curve, would make ebXML an obvious choice for reliable =
messaging...=20

      Your thoughts ?=20

      Bye=20
      Chris=20

      PS : I think my idea means a new implementation, not just an =
adaptation=20
      of Hermes...=20

    =
---------------------------------------------------------------------

 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
---------------------------------------------------------------------=20

Re: [ebxmlms-general] Test service not available

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

Ajit,

I guess here we got some misunderstanding. The service =
(http://www.cecid.hku.hk/ebxml/service) is the parameter of ebXML MS. =
It's to be registered to Hermes. However, the error message you got in =
the log file said that the service is unavailable actually get nothing =
to do with that ebXML parameter. It's reported by the app server that =
the servlet service is not well configured and thus the app server =
cannot fulfil your request.

After you installed Hermes, you can try to confirm the success of =
installation by point your browser to
http://localhost/msh. (Of course, here I assume the port number is 8080, =
and Hermes is installed at the context path msh). If everything's =
correct, you should see a "MSH is alive.." message. By seeing that, you =
can pretty sure that Hermes is installed in the app server.

Regards, -patrick

  ----- Original Message -----=20
  From: Tripathi, Ajit (GXS)=20
  To: 'ebx...@li...'=20
  Sent: Friday, October 31, 2003 1:43 PM
  Subject: [ebxmlms-general] Test service not available


  Patrick,

      I can understand why  the service in loopback... String service =
=3D "http://www.cecid.hku.hk/ebxml/service"; may not be available but =
... just confirming. Would you have the source code for the service ... =
just in case?

  regards,
  Ajit



  INFO: Jk running ID=3D0 time=3D15/156  =
config=3DC:\hermes\tomcat\bin\..\conf\jk2.prope
  rties
  javax.xml.soap.SOAPException: Bad response: (503Service Unavailable
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.post(HttpSOA
  PConnection.java:267)
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection$PriviledgedP
  ost.run(HttpSOAPConnection.java:142)
          at java.security.AccessController.doPrivileged(Native Method)
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOA
  PConnection.java:115)
          at =
hk.hku.cecid.phoenix.message.transport.HttpServlet.send(Unknown Sourc
  e)
          at hk.hku.cecid.phoenix.message.handler.HttpSender.run(Unknown =
Source)
  javax.xml.soap.SOAPException: Bad response: (503Service Unavailable
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.post(HttpSOA
  PConnection.java:267)
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection$PriviledgedP
  ost.run(HttpSOAPConnection.java:142)
          at java.security.AccessController.doPrivileged(Native Method)
          at =
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOA
  PConnection.java:115)
          at =
hk.hku.cecid.phoenix.message.transport.HttpServlet.send(Unknown Sourc
    -----Original Message-----
    From: Patrick Yee [mailto:kc...@ce...]
    Sent: Thursday, October 30, 2003 7:47 PM
    To: ebx...@li...
    Subject: Re: [ebxmlms-general] SMTP Port not configurable


    Ajit,
    Ooops.. you are right. We will include it in our next release. =
Thanks for your suggestion.
    Regards, -Patrick

          By the way, why is the SMTP port not configurable in =
msh.properties.xml?=20

            <SMTP>
              <Host>localhost</Host>
              <User>ajitkt</User>
              <Password>nainital</Password>
            </SMTP>

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

[Tripathi, A. (GXS) <Aji...@gx...>]

Chris,
 
    I see what you are saying ... you are not alone ...  BEA and IBM don't
want to see two different messaging models in J2EE either, one for MDBs and
another for JAXM. Hence, JAXM was voted out of J2EE. However, XML/SOAP over
HTTP can't be replaced by XML/SOAP over JMS.
 
    However, ebXML is in no way restricted by the choice of messaging. You
may want to use ebXML over a synchronous messaging protocol, as much as you
can use it with HTTP, SMTP, JAXM and JMS. Hence common JMS features need to
be reinvented by MSHs. ebXML cares about what services an MSH provides. How
it does that is in a large degree, left to MSHs.
 
     Implementation independence is a goal for a very good reason - ebXML
without interoperability would be useless.  Never forget Microsoft - Java
isn't the only thing in the integration world.
 
regards,
Ajit

-----Original Message-----
From: Christophe Hartwig-Peillon [mailto:chr...@re...]
Sent: Friday, October 31, 2003 3:50 PM
To: ebx...@li...
Subject: Re: [ebxmlms-general] idea : use ebXML to bridge the gap, through
JMS


Hi,

I'm not talking about using JMS as the transport... It's the opposite : I'm
talking about using JMS as the API and architecture, and using ebXML over
(choose your favorite transport) for the encoding and transport.

ebXML wants to be independant (of transport, apis, etc...) : the net result
is lack of adoption, lack of integration. 
ebXML is not considered a "solution", just an encoding :-(

If sending an ebXML message was as easy as sending a JMS message with a
toParty header, and receiving an ebXML message was as easy as writing a
message bean, ebXML would be easier to adopt !

I tend to think of ebXML as an encoding for MOM semantics. JMS has no
encoding protocol : JMS assumes the transport layer also takes care of the
encoding. The protocol stack would be, from top to bottom :
- JMS
- ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME mini-stack)
- HTTP, SMTP, or whatever protocol the MSH could support

If you prefer : ebXML is needed, because we need an XML encoding which
preserves MOM semantics, for easy interoperability, but JAXM is useless,
since we already have MOM apis...

Until now, interoperability was not the primary goal of JMS : JMS made the
interop possible, since no assumption was made on encoding or transport. The
result is that, except for JSM bridges (for Tibco or MQSeries), interop is
weak ! Using ebXML as the encoding, and HTTP/SMTP the transport could make
JMS interop possible.
JMS-JMS interop would be great, but the fact that ebXML is API agnostic is
even better : it would allow anyone with HTTP/SMTP libraries and an XML
parser to send messages to your JMS server ! It would allow JAXM - JMS
interop, and commercial ebXML implementations - JMS interop...

I think JMS is *the* MOM API for J2EE, not JAXM...
And ebXML should be *the* interoperable encoding for MOM implementations.

But I don't recommend implementing a JMS provider on top of Hermes : one
solution is the use of an existing JMS implementation, and the
implementation of the ebXML layer as a JMS client...
A servlet can wait for ebXML messages, create a temp queue for the reply,
send the ebXML message to a JMS queue...
Message Beans can handle messages, and post their reply to the reply-to
queue.
The servlet can then send the response (it was blocking on the temps queue
until now)...

To send an ebXML message, you'll just post the payload and some JMS headers
(like the recepient of the message) to a JMS queue...
A queue listener will then build the ebXML message and send it, using some
of the JMS message headers for the ebXML header... The ebXML implementation
could take care of signing, choosing the right transport, etc... the ebXML
layer would be focused on what is does best : interop !

JMS will take care of acknoledgement, transaction support, persistence,
etc...
The MSH will just be a relay !
That's one possible implementation (well, deep thinking is needed here, I
admit :-)... 

Another one would be to take an existing JMS implementation (like JBoss'es),
and add an ebXML/HTTP and ebXML/SMTP transport. This implementation would
work only for that JMS implementation, but might offer greater support for
MOM semantics (because it would be linked with the implementation of the JMS
server)...

I know all of this is heretic, since JAXM exists and is an endorsed
standard... but sometimes standards die, sometimes they are abandonned... I
would prefer to see JAXM die instead of ebXML : we need ebXML !
Chris

Tripathi, Ajit (GXS) wrote:


Chris, 

        The ebXML messaging spec (ebMS2) seeks to be independent of
application transport. As per the spec, JMS can be incorporated into msh
products, alongwith http and smtp but that is an implementation decision. 

        Clearly, messaging is only one aspect of ebXML. The spec broadly
seeks to enable business processes between trading partners using XML
(vis-a-vis EDI) . However, inter-enterprise collaboration requires much more
sophisticated messaging than SOAP spec accounts for. 

        While ebXML messaging is built on top of SOAP-Attach, security and
reliability are two key messaging requirements not mentioned in the set of
specs known as "web-services". ebXML also seeks to bridge that gap through
msh.

regards, 
Ajot 

-----Original Message----- 
From: Christophe Hartwig-Peillon [ mailto:chr...@re...
<mailto:chr...@re...> ] 
Sent: Friday, October 31, 2003 2:19 PM 
To: ebx...@li...
<mailto:ebx...@li...>  
Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, through 
JMS 


Hi all, 

At the beginning, I considered ebXML as an alternative to Web Services... 
But this mistake was due to my lack of understanding. 

My understanding now is that ebXML is a MOM protocol, but this kind of 
assertion is found nowhere, hence the ambiguity with Web Services. So 
assertions like "Web services will take over ebXML" are just plain 
nonsense : you can't compare MOM with RPC. 
Then JAXM has added its load of ambiguity, since it has added one more 
API in the Java world, despite the existence of a proven API for MOMs, 
JMS... 

Don't you think that there would be a place in the ebXML for a JMS based 
implementation of ebXML MSH for its encoding and transport ? 
I can imagine implementing ebXML on top of an existing JMS 
implementation would make things easier : JMS already has reliable 
messaging semantics, and already offers transactional persistent 
messages, etc... Many features of Hermes are already supported by JMS 
implementations... And JMS supports temporary queues (and reply-to) for 
request-response messages... And JMS already offers Message Beans 
integration... and JMS is most often clusterable... and ... I like that 
idea :-) 

I think such an implementation would make the use of ebXML simpler, 
better integrated with J2EE environments, would reduce the learning 
curve, would make ebXML an obvious choice for reliable messaging... 

Your thoughts ? 

Bye 
Chris 

PS : I think my idea means a new implementation, not just an adaptation 
of Hermes... 

---------------------------------------------------------------------

 Christophe HARTWIG - Interface Technologies    cha...@re...
<mailto:cha...@re...> 

 17, avenue Andre Roussin                     http://www.reservit.com
<http://www.reservit.com> 

 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90

 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92

--------------------------------------------------------------------- 

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

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

Hi,

I'm not talking about using JMS as the transport... It's the opposite : 
I'm talking about using JMS as the API and architecture, and using ebXML 
over (choose your favorite transport) for the encoding and transport.

ebXML wants to be independant (of transport, apis, etc...) : the net 
result is lack of adoption, lack of integration.
ebXML is not considered a "solution", just an encoding :-(

If sending an ebXML message was as easy as sending a JMS message with a 
toParty header, and receiving an ebXML message was as easy as writing a 
message bean, ebXML would be easier to adopt !

I tend to think of ebXML as an encoding for MOM semantics. JMS has no 
encoding protocol : JMS assumes the transport layer also takes care of 
the encoding. The protocol stack would be, from top to bottom :
- JMS
- ebXML encoding of MOM semantics (ie. ebXML / SOAP w/A / MIME mini-stack)
- HTTP, SMTP, or whatever protocol the MSH could support

If you prefer : ebXML is needed, because we need an XML encoding which 
preserves MOM semantics, for easy interoperability, but JAXM is useless, 
since we already have MOM apis...

Until now, interoperability was not the primary goal of JMS : JMS made 
the interop possible, since no assumption was made on encoding or 
transport. The result is that, except for JSM bridges (for Tibco or 
MQSeries), interop is weak ! Using ebXML as the encoding, and HTTP/SMTP 
the transport could make JMS interop possible.
JMS-JMS interop would be great, but the fact that ebXML is API agnostic 
is even better : it would allow anyone with HTTP/SMTP libraries and an 
XML parser to send messages to your JMS server ! It would allow JAXM - 
JMS interop, and commercial ebXML implementations - JMS interop...

I think JMS is *the* MOM API for J2EE, not JAXM...
And ebXML should be *the* interoperable encoding for MOM implementations.

But I don't recommend implementing a JMS provider on top of Hermes : one 
solution is the use of an existing JMS implementation, and the 
implementation of the ebXML layer as a JMS client...
A servlet can wait for ebXML messages, create a temp queue for the 
reply, send the ebXML message to a JMS queue...
Message Beans can handle messages, and post their reply to the reply-to 
queue.
The servlet can then send the response (it was blocking on the temps 
queue until now)...

To send an ebXML message, you'll just post the payload and some JMS 
headers (like the recepient of the message) to a JMS queue...
A queue listener will then build the ebXML message and send it, using 
some of the JMS message headers for the ebXML header... The ebXML 
implementation could take care of signing, choosing the right transport, 
etc... the ebXML layer would be focused on what is does best : interop !

JMS will take care of acknoledgement, transaction support, persistence, 
etc...
The MSH will just be a relay !
That's one possible implementation (well, deep thinking is needed here, 
I admit :-)...

Another one would be to take an existing JMS implementation (like 
JBoss'es), and add an ebXML/HTTP and ebXML/SMTP transport. This 
implementation would work only for that JMS implementation, but might 
offer greater support for MOM semantics (because it would be linked with 
the implementation of the JMS server)...

I know all of this is heretic, since JAXM exists and is an endorsed 
standard... but sometimes standards die, sometimes they are 
abandonned... I would prefer to see JAXM die instead of ebXML : we need 
ebXML !
Chris

Tripathi, Ajit (GXS) wrote:

> Chris,
>
>         The ebXML messaging spec (ebMS2) seeks to be independent of 
> application transport. As per the spec, JMS can be incorporated into 
> msh products, alongwith http and smtp but that is an implementation 
> decision.
>
>         Clearly, messaging is only one aspect of ebXML. The spec 
> broadly seeks to enable business processes between trading partners 
> using XML (vis-a-vis EDI) . However, inter-enterprise collaboration 
> requires much more sophisticated messaging than SOAP spec accounts for.
>
>         While ebXML messaging is built on top of SOAP-Attach, security 
> and reliability are two key messaging requirements not mentioned in 
> the set of specs known as "web-services". ebXML also seeks to bridge 
> that gap through msh.
>
> regards,
> Ajot
>
> -----Original Message-----
> From: Christophe Hartwig-Peillon [mailto:chr...@re...]
> Sent: Friday, October 31, 2003 2:19 PM
> To: ebx...@li...
> Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, through
> JMS
>
>
> Hi all,
>
> At the beginning, I considered ebXML as an alternative to Web Services...
> But this mistake was due to my lack of understanding.
>
> My understanding now is that ebXML is a MOM protocol, but this kind of
> assertion is found nowhere, hence the ambiguity with Web Services. So
> assertions like "Web services will take over ebXML" are just plain
> nonsense : you can't compare MOM with RPC.
> Then JAXM has added its load of ambiguity, since it has added one more
> API in the Java world, despite the existence of a proven API for MOMs,
> JMS...
>
> Don't you think that there would be a place in the ebXML for a JMS based
> implementation of ebXML MSH for its encoding and transport ?
> I can imagine implementing ebXML on top of an existing JMS
> implementation would make things easier : JMS already has reliable
> messaging semantics, and already offers transactional persistent
> messages, etc... Many features of Hermes are already supported by JMS
> implementations... And JMS supports temporary queues (and reply-to) for
> request-response messages... And JMS already offers Message Beans
> integration... and JMS is most often clusterable... and ... I like that
> idea :-)
>
> I think such an implementation would make the use of ebXML simpler,
> better integrated with J2EE environments, would reduce the learning
> curve, would make ebXML an obvious choice for reliable messaging...
>
> Your thoughts ?
>
> Bye
> Chris
>
> PS : I think my idea means a new implementation, not just an adaptation
> of Hermes...
>
---------------------------------------------------------------------

 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
--------------------------------------------------------------------- 

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

[Tripathi, A. (GXS) <Aji...@gx...>]

Chris,

	The ebXML messaging spec (ebMS2) seeks to be independent of
application transport. As per the spec, JMS can be incorporated into msh
products, alongwith http and smtp but that is an implementation decision. 

	Clearly, messaging is only one aspect of ebXML. The spec broadly
seeks to enable business processes between trading partners using XML
(vis-a-vis EDI) . However, inter-enterprise collaboration requires much more
sophisticated messaging than SOAP spec accounts for. 

	While ebXML messaging is built on top of SOAP-Attach, security and
reliability are two key messaging requirements not mentioned in the set of
specs known as "web-services". ebXML also seeks to bridge that gap through
msh.

regards,
Ajot 

-----Original Message-----
From: Christophe Hartwig-Peillon [mailto:chr...@re...]
Sent: Friday, October 31, 2003 2:19 PM
To: ebx...@li...
Subject: [ebxmlms-general] idea : use ebXML to bridge the gap, through
JMS


Hi all,

At the beginning, I considered ebXML as an alternative to Web Services...
But this mistake was due to my lack of understanding.

My understanding now is that ebXML is a MOM protocol, but this kind of 
assertion is found nowhere, hence the ambiguity with Web Services. So 
assertions like "Web services will take over ebXML" are just plain 
nonsense : you can't compare MOM with RPC.
Then JAXM has added its load of ambiguity, since it has added one more 
API in the Java world, despite the existence of a proven API for MOMs, 
JMS...

Don't you think that there would be a place in the ebXML for a JMS based 
implementation of ebXML MSH for its encoding and transport ?
I can imagine implementing ebXML on top of an existing JMS 
implementation would make things easier : JMS already has reliable 
messaging semantics, and already offers transactional persistent 
messages, etc... Many features of Hermes are already supported by JMS 
implementations... And JMS supports temporary queues (and reply-to) for 
request-response messages... And JMS already offers Message Beans 
integration... and JMS is most often clusterable... and ... I like that 
idea :-)

I think such an implementation would make the use of ebXML simpler, 
better integrated with J2EE environments, would reduce the learning 
curve, would make ebXML an obvious choice for reliable messaging...

Your thoughts ?

Bye
Chris

PS : I think my idea means a new implementation, not just an adaptation 
of Hermes...

---------------------------------------------------------------------
 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
--------------------------------------------------------------------- 




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?   SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
ebxmlms-general mailing list
ebx...@li...
https://lists.sourceforge.net/lists/listinfo/ebxmlms-general

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

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

Hi all,

At the beginning, I considered ebXML as an alternative to Web Services...
But this mistake was due to my lack of understanding.

My understanding now is that ebXML is a MOM protocol, but this kind of 
assertion is found nowhere, hence the ambiguity with Web Services. So 
assertions like "Web services will take over ebXML" are just plain 
nonsense : you can't compare MOM with RPC.
Then JAXM has added its load of ambiguity, since it has added one more 
API in the Java world, despite the existence of a proven API for MOMs, 
JMS...

Don't you think that there would be a place in the ebXML for a JMS based 
implementation of ebXML MSH for its encoding and transport ?
I can imagine implementing ebXML on top of an existing JMS 
implementation would make things easier : JMS already has reliable 
messaging semantics, and already offers transactional persistent 
messages, etc... Many features of Hermes are already supported by JMS 
implementations... And JMS supports temporary queues (and reply-to) for 
request-response messages... And JMS already offers Message Beans 
integration... and JMS is most often clusterable... and ... I like that 
idea :-)

I think such an implementation would make the use of ebXML simpler, 
better integrated with J2EE environments, would reduce the learning 
curve, would make ebXML an obvious choice for reliable messaging...

Your thoughts ?

Bye
Chris

PS : I think my idea means a new implementation, not just an adaptation 
of Hermes...

---------------------------------------------------------------------
 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
--------------------------------------------------------------------- 

Re: [ebxmlms-general] Problem with resending of messages

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

Hi all,

I just discovered we don't ask for an Ack... not my code :-)
So it's normal we don't get reliable messaging...
Thanks for your reply !

Bye
Chris

Bob Koon wrote:

> Dear Chris,
> If your message has asked for Reliable Messaging (AckRequested), it is 
> truth that the message will be resent automatically by Hermes.
> I have just tried using the following scenario, and it resent the 
> message:
>
> MSH Monitor  ->  Hermes  ->  Mail Server
>
> I have set the Monitor to use toMshUrl : 
> "mailto:ad...@ma..." (an email address), and then properly 
> set the SMTP setting in the msh.properties.xml for Hermes. After the 
> registration, I try to send out the message with Reliable Messaging 
> checked and note that it must have email address on both from and to 
> party id (something like "mailto:ad...@ma..."), and I can 
> receive several retries on my mail account.
>
> See whether the above helps
>
> Regards,
> Bob Koon
>
> Christophe Hartwig-Peillon wrote:
>
>> Hi all,
>>
>> I currently use both SMTP and HTTP transports with Hermes, and I'm 
>> having problems with SMTP.
>> My understanding is that messages I send should be acknoledged by the 
>> receiver. Without acknoledgement, messages should be resent... Am I 
>> wrong ?
>> It appears messages are not resent automagically by hermes in my case...
>>
>> Any idea ?
>>
>> Thanks,
>> Chris
>>
>> ---------------------------------------------------------------------
>> Christophe HARTWIG - Interface Technologies   cha...@re...
>> 17, avenue Andre Roussin                    http://www.reservit.com
>> ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
>> 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
>> ---------------------------------------------------------------------
>>
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?   SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> ebxmlms-general mailing list
>> ebx...@li...
>> https://lists.sourceforge.net/lists/listinfo/ebxmlms-general
>>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> ebxmlms-general mailing list
> ebx...@li...
> https://lists.sourceforge.net/lists/listinfo/ebxmlms-general
>


-- 
---------------------------------------------------------------------
 Christophe HARTWIG - Interface Technologies   cha...@re...
 17, avenue Andre Roussin                    http://www.reservit.com
 ZAC de Saumaty-Seon                        Tel : + 33 4 91 03 64 90
 13016 MARSEILLE - FRANCE                   Fax : + 33 4 91 03 64 92
--------------------------------------------------------------------- 

[ebxmlms-general] Test service not available

[Tripathi, A. (GXS) <Aji...@gx...>]

Patrick,
 
    I can understand why  the service in loopback... String service = "
http://www.cecid.hku.hk/ebxml/service
<http://www.cecid.hku.hk/ebxml/service> "; may not be available but ... just
confirming. Would you have the source code for the service ... just in case?
 
regards,
Ajit

 
INFO: Jk running ID=0 time=15/156
config=C:\hermes\tomcat\bin\..\conf\jk2.prope
rties
javax.xml.soap.SOAPException: Bad response: (503Service Unavailable
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.post(HttpSOA
PConnection.java:267)
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection$PriviledgedP
ost.run(HttpSOAPConnection.java:142)
        at java.security.AccessController.doPrivileged(Native Method)
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOA
PConnection.java:115)
        at hk.hku.cecid.phoenix.message.transport.HttpServlet.send(Unknown
Sourc
e)
        at hk.hku.cecid.phoenix.message.handler.HttpSender.run(Unknown
Source)
javax.xml.soap.SOAPException: Bad response: (503Service Unavailable
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.post(HttpSOA
PConnection.java:267)
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection$PriviledgedP
ost.run(HttpSOAPConnection.java:142)
        at java.security.AccessController.doPrivileged(Native Method)
        at
com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnection.call(HttpSOA
PConnection.java:115)
        at hk.hku.cecid.phoenix.message.transport.HttpServlet.send(Unknown
Sourc

-----Original Message-----
From: Patrick Yee [mailto:kc...@ce...]
Sent: Thursday, October 30, 2003 7:47 PM
To: ebx...@li...
Subject: Re: [ebxmlms-general] SMTP Port not configurable


Ajit,
Ooops.. you are right. We will include it in our next release. Thanks for
your suggestion.
Regards, -Patrick
 

    By the way, why is the SMTP port not configurable in msh.properties.xml?

 
      <SMTP>
        <Host>localhost</Host>
        <User>ajitkt</User>
        <Password>nainital</Password>
      </SMTP>
 

Re: [ebxmlms-general] SMTP Port not configurable

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

Ajit,
Ooops.. you are right. We will include it in our next release. Thanks =
for your suggestion.
Regards, -Patrick

      By the way, why is the SMTP port not configurable in =
msh.properties.xml?=20

        <SMTP>
          <Host>localhost</Host>
          <User>ajitkt</User>
          <Password>nainital</Password>
        </SMTP>

[ebxmlms-general] SMTP Port not configurable

[Tripathi, A. (GXS) <Aji...@gx...>]

Patrick,
 
    Thanks a lot. So far I like what I see ... freebXML msh is significantly
simplifying our life down here. 
 
    By the way, why is the SMTP port not configurable in msh.properties.xml?

 
      <SMTP>
        <Host>localhost</Host>
        <User>ajitkt</User>
        <Password>nainital</Password>
      </SMTP>
 
    I am running a freeware smtp server on my machine for testing but port
25 has already been taken by some daemon process (windows)!!! It'd been nice
if the port was configurable!
 
regards,
Ajit

-----Original Message-----
From: Patrick Yee [mailto:kc...@ce...]
Sent: Thursday, October 30, 2003 7:25 PM
To: ebx...@li...
Subject: Re: [ebxmlms-general] bundled loopback client: question


Ajit,
We only have those 2 documents at the moment. :-)
Regards, -Patrick
 

    Any other hermes documentation available (other than dev. and install
guide) will be very useful!
 

Re: [ebxmlms-general] bundled loopback client: question

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

Ajit,
We only have those 2 documents at the moment. :-)
Regards, -Patrick

      Any other hermes documentation available (other than dev. and =
install guide) will be very useful!