OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [ebxml-dev] Open source client implementation of ebms

I’d probably have a nice long think before integrating a web browser into a Java app using JNI (which is how you do what David is saying).  That approach is pretty flawed from a performance perspective, and you would end up having lots of hassles communicating information back and forth between the parent application and the embedded web browser.


Developing a thin client layer yourself might end up being the least painful approach over  time.


matt mackenzie | sr. manager, engineering | adobe systems | +1 613.884.6843 | mattm@adobe.com | www.adobe.com


From: Roger Bass [mailto:roger@traxian.com]
Sent: Wednesday, July 28, 2010 11:34 AM
To: 'David RR Webber (XML)'
Cc: 'Pim van der Eijk'; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] Open source client implementation of ebms




Thanks again.  (Not sure if this discussion should stay on the list or not…)  I’d be interested to get a url for the 50k SOAP library you mention.  That said, while as a non-engineer, I may be missing something, but I’m not sure I see how this could easily retro-fit our EXISTING Java client app.  While the ability to run from a browser (vs a standalone client) is something we may want to address in future, it’s not a top priority now, and I’m certainly not looking to do a major rewrite.


We have a process now for polling our server every few minutes to get transaction files downloaded (https with some reliability features) from a repository on the server to a target directory on the client.  That’s all.  It works ok, but I’d consider plugging in alternate modules to do the job better.  If that involved a bigger platform shift on the server (message repository etc), it might still be worth doing, but I’d think about it for longer.






From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Wednesday, July 28, 2010 11:22 AM
To: Roger Bass
Cc: 'Pim van der Eijk'; ebxml-dev@lists.ebxml.org
Subject: RE: [ebxml-dev] Open source client implementation of ebms




If you are going Java - why do work?  Just embed the Java browser module from Firefox code base.


That way its self contained and already has the forms support, js and everything - write once deploy anywhere.


People can either download your Java app - or run hosted from web.  That 50k SOAP library in JS is killer BTW!


A project for the winter to add ebMS capability to it, unless we have a volunteer here to try that?


Thanks, DW

-------- Original Message --------
Subject: RE: [ebxml-dev] Open source client implementation of ebms
From: "Roger Bass" <roger@traxian.com>
Date: Wed, July 28, 2010 11:14 am
To: "'Pim van der Eijk'" <lists@sonnenglanz.net>,
<ebxml-dev@lists.ebxml.org>, "'David RR Webber (XML)'" <david@drrw.info>

Pim, David,


Thank you both for your thoughts.  Do you think this is something that the Holodeck or any other team might want to address in future?


With ebMS 3.0 addressing the client-pull model, there seemed to be an acknowledgment that this was an important pattern in making ebMS “SMB-friendly”.  Having easy, lightweight tools for doing that would be key for an SMB-focused developer like my company to adopt.


Even if no existing project includes a set of client comms libraries, I’d be interested in your thoughts as to what open source Java libraries or tools might make most sense.  (Our technology is a standalone java client – using JRE not JDK – so thanks David, but javascript probably isn’t the right technology).  That said, given other current priorities on this end, it’d have to be pretty much turnkey – not much appetite here for tweaking or ebMS-specific development I’m afraid.


Best regards,




From: Pim van der Eijk [mailto:lists@sonnenglanz.net]
Sent: Wednesday, July 28, 2010 8:34 AM
To: 'Roger Bass'; ebxml-dev@lists.ebxml.org; 'David RR Webber (XML)'
Subject: RE: [ebxml-dev] Open source client implementation of ebms


Hello Roger,


I'm not aware of simpler ebMS 3.0 client-only implementations.  The implementations I know about support both the client and server functionality. If they offer a client-only option, it is a lower-cost commercial option with turned off functionality that doesn't reduce the code base size.   SOAP libraries for security and reliability needed to implement ebMS tend to depend on these larger SOAP frameworks. 


The AS4 profile doesn't require reliable messaging, but still does require WS-Security.  I agree that an ebMS 3.0 client profile that drops even that requirement (and just uses TLS) seems very simple to implement.





From: Roger Bass [mailto:roger@traxian.com]
Sent: 15 July 2010 05:02
To: ebxml-dev@lists.ebxml.org; 'David RR Webber (XML)'
Subject: [ebxml-dev] Open source client implementation of ebms

David, (or perhaps Jacques / Pim?)


My company, Traxian, is looking at some updates to our product to improve reliability of the client-pull mechanism.  The client software polls our server to retrieve messages from a user’s mailbox (i.e. it’s entirely internal to us).  Most likely a small, proprietary enhancement will fit the bill, but this prompted me again to look at possible ebMS open source products / libraries for implementing this.  Since I noted ebMS 3.0 now extends to the client-pull message pattern, I wondered if code implementing that might now be available.  (Code that included an embedded data store for transactions using a lightweight embedded database on the client side might also be a plus, though it’s not a critical requirement right now).


I’m not finding anything quite like that – does it exist?


What I do see is the fairly recently released Holodeck project (May 2010) – but despite being ebMS 3.0 based, it seems not to include any client-side implementation (with tomcat and axis2 as prerequisites, even for the ‘light’ version).


The Hermes / freebxml project includes the ebMail GUI client, but it seems designed more as a real GUI with a plug-in model, rather than as a set of libraries to use as a new messaging core for an existing product.


BTW, for those interested, Traxian’s is an easy e-commerce integration solution for B2B and B2C transactions, initially focused on QuickBooks.  It includes a “social / viral” model for radically easy, low-friction setup.



Roger Bass

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]