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

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

Ng Chi Yuen [Cyng] wrote:

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

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

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

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

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

Ronald

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