On Aug 7, 2008, at 9:56 AM, Scott Ferguson wrote:

> On Aug 7, 2008, at 9:22 AM, Chris Chen wrote:
>> Quick question which I cannot find the answer to on the BAM page.
>> How reliable is the BAM service?  Does it provide a persistent
>> subscription feature like JMS?  In critical services where packets  
>> are
>> sent and must be processed by a subscriber without losing that
>> information, does BAM take care of this?  Is there also a transaction
>> feature to BAM where a message could either be put back into the  
>> queue
>> to be retried if transaction fails and rolls back?
> Not yet.  The current queue capability is a simple memory-based
> queue.  Since we only added/cleaned-up the queue at the last minute,
> there wasn't time to also add the persistent capabilities.  It's
> definitely in the plan.  (I just added a bug report at 
> http://bugs.caucho.com/view.php?id=2826
>  to make it concrete.)
> The subscriber issue is interesting since Jabber defines persistence
> as one of their "XEP" capabilities (XEP are mini-specs, basically
> defining mixin capabilities.)  I haven't quite figured out how to make
> those capabilities work in a generic fashion, i.e. available for
> anyone, not just tied to a specific chat implementation.

I wrote an open source jabber client library before so JEP/XEPs are  
quite familiar to me. :)

I don't have a fully concrete idea either but there are two sides to  
this subscription feature - client and server.  The server side may be  
similar to how JMS EJB beans or Jabber Server side components work.   
The EJB side has a defined set of beans listening to a particular  
topic/queue.  This is considered a subscription.  As for persistent  
subscriptions, it can be similar to how JMS works as well.  A client  
registers as a subscriber for a particular topic.  Unless the client  
unsubscribes, the system will continue to store messages for this  
subscriber when the subscriber is offline.  Of course, this comes with  
its own set of challenges.  Fiorano MQ and ESB has a setting to  
periodically flush out any persistent messages.

XMPP by nature has persistence message supported in some sense (ie. I  
get chat messages that were sent when I wasn't logged on).  I wonder  
if a Jini-like persistence capability may be something to model after  
or even relevant in this case.  Either way, persistent and  
subscription do go hand in hand.

>> it may be that BAM is currently geared towards the chat architecture
>> such as twitter/IM/comet/etc so this may not apply, but I'd like to
>> know the options available.
> The persistence and XA does fit into the architecture.  It's
> interesting, as I work more with BAM examples, it's really more
> capable than the lightweight IM/comet framework that we'd initially
> envisioned.  In the 3.2.1 timeframe, I'm planning on some ESB/SOA
> experiments to see how well it works in that space.
>> What's the plan for Resin's BAM and JMS implementation?  Separate or
>> may be integrated into one?
> I'm going to try to integrate them.  It'll be interesting, since BAM
> is a slightly lower layer than JMS, since its payload is just a
> Serializable and the only meta information are the "to" and "from".
> So the JMS Message classes may define a JMS layer on top of BAM.
> It'll take some experimentation to see how that will work.
> A nice thing about developing in BAM is that it's so stripped-down,
> that you can consider more use-case combinations than a more
> complicated model like JMS.

I think integration is interesting, but more relevant are the use  
cases surrounding each type of system.

*) BAM - lightweight for super fast and scalable message brokering for  
things such as stock market price streaming (no need for persistence)  
or twittering type messages.  The main thing here is "as fast as  
computerly possible".

*) JMS/persistent subscriptions - These are for those that broker  
highly mission-critical data.  The primary interest here is "as  
reliable as possible".  Speed is less of a concern compared to the  
data.  Inherently, this type of use conflicts with BAM.  Transactions  
will bog down the speed.

*) ESB/SOA activities - these, in my view, are for those that require  
high data/service compatibility and integration.  The message here is  
"as promiscuous as possible".  The focus is on the adapters and being  
able to communicate and connect to many different systems.

I think all of them centers around a hub-spoke model.  It's possible  
to integrate all of them together through layers.  The lowest layer  
(in this case, BAM) focuses entirely on speed.  A secondary layer can  
add the reliability that can be similar to XEP persistence.  Possibly  
a persistence component that subscribes and listens to any topic/queue  
that requires such a service and separately deals with reliability.  A  
third component can create a set of adapters to connect to different  
systems.  This third component mainly focuses on data/message  

Breaking the system up in these parts seems more logical to me.   
Otherwise, there'd probably be duplication of effort.  For example,  
there is an adapter for BAM-JMS.  Why not break down JMS into two  
parts - the bam component (message brokering) and persistence/ 
transaction.  Then separate out the BAM-JMS into the third part as an  
adapter system.  There'd be fewer duplication happening.  In fact, it  
may even be possible to do some sort of cluster management through  
this system (ie. resin monitoring).

These are just some thoughts.  But I do think a BAM model is more  
useful than JMS.  Put another way, I prefer a more simplified JMS  
system.  One reason why I like XMPP over JMS.  I had quite a bit of  
trouble when I tried to deal with JMS persistent subscriptions back  
then when I was working with Fiorano MQ and ESB software.

My Two Cents,

> -- Scott
>> -Chris
>> On Aug 7, 2008, at 8:58 AM, Scott Ferguson wrote:
>>> Resin 3.2.0 is now available at the usual download 
>>> http://caucho.com/download
>>> .  Release notes are at http://caucho.com/resin/changes/resin-3.2.0.xtp
>>> .
>>> Resin 3.2.x is the development branch.  We have a full roadmap of
>>> stuff to add to 3.2.x, so 3.2.x will be changing considerably for
>>> each
>>> release.  For sites that don't want that kind of code-upheaval, use
>>> the 3.1.x stable branch.
>>> Much of the 3.2.0 work was underlying refactoring and distribution/
>>> release refactoring.  Jars have been merged, so resin.jar and
>>> javaee-16.jar are the only needed jars for Resin OpenSource.  Resin
>>> Pro also needs pro.jar.  Also, the resin.xml replaces resin.conf (to
>>> make editors/mail happy), and a bunch of smaller changes in the
>>> distribution layout.
>>> The 3.2.0 release now includes a 32-bit debian package at the
>>> download
>>> site, which will make installation easier for Debian Linux sites
>>> including Ubuntu.
>>> For administration, the /resin-admin has been reworked and enhanced.
>>> New capabilities include:
>>> * graphing of critical statistics
>>> * revised and enhanced summary page
>>> * monitoring and display of slow requests
>>> * new JMX page displaying all MBeans and attributes in the system
>>> * revised web-app page including start/stop/restart
>>> For alerts, we've added a "mail:" log-handler, which can email you a
>>> compilation of the severe and critical log messages (this is very
>>> handy.)
>>> The threading and socket management has been refactored to better
>>> handle comet and jabber connections.  During the checkout process,  
>>> we
>>> loaded it with 25,000 simultaneous comet connections as a stress
>>> test.
>>> The distributed sessions have been reworked to use BAM as the
>>> underlying transport, and the database restructured to handle  
>>> planned
>>> distributed object enhancements like distributed caching, and better
>>> startup performance.   Both the threading and session refactorings
>>> are
>>> major changes, so sites relying on them should do their own stress
>>> testing.
>>> Our JSF implementation now includes a handy debugging page, to  
>>> better
>>> show the state of the JSF system.  The example at 
>>> http://caucho.com/resin/examples/jsf-webbeans.xtp
>>> shows this capability (see the bottom right corner.)
>>> BAM (http://caucho.com/resin/doc/bam.xtp) has been refactored and
>>> cleaned up.  It can now act as a SEDA/queue replacement for memory-
>>> based JMS queues.  The client and service have been simplified, so
>>> the
>>> housekeeping overhead is now minimal.  In addition, you can now
>>> program to BAM using PHP, which is a very cool feature.
>>> Share and Enjoy!
>>> -- Scott
>>> _______________________________________________
>>> resin-interest mailing list
>>> resin-interest@caucho.com
>>> http://maillist.caucho.com/mailman/listinfo/resin-interest
>> _______________________________________________
>> resin-interest mailing list
>> resin-interest@caucho.com
>> http://maillist.caucho.com/mailman/listinfo/resin-interest
> _______________________________________________
> resin-interest mailing list
> resin-interest@caucho.com
> http://maillist.caucho.com/mailman/listinfo/resin-interest

resin-interest mailing list

Reply via email to