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
David,
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.
Best,
Roger
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?
-------- 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>
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.
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.
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.
|