river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [River Wiki] Update of "JavaBasedSOA" by GregTrasuk
Date Tue, 02 Aug 2011 19:52:59 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "River Wiki" for change notification.

The "JavaBasedSOA" page has been changed by GregTrasuk:
http://wiki.apache.org/river/JavaBasedSOA?action=diff&rev1=4&rev2=5

  Looking at this from a Jini/River perspective, we can make a few observations:
   * By decoupling service location through the registrar, and allowing for dynamically downloaded
proxies that implement whatever protocol the service wants, Jini makes most of the ESB functionality
(a magic connectivity cloud)  unnecessary.
   * Standard SOA's concept of adapters could be seen as a variant of the Surrogate architecture.
 The big difference is that Surrogate assumes that the non-Java service is an active participant
in the Jini network.  To implement the SOA adapter pattern, we need to be able to add a surrogate
without the non-Java service initiating it (not a big change to the Surrogate architecture).
+  * Jini/River services can be readily accessed from traditional Java user interface technologies,
both Swing and Web Apps.  The only sticking points are the need to run the client with a security
manager, and the difficulty of having the client export a codebase.  The security manager
is not a problem (e.g. Tomcat runs happily with a security manager) and the codebase issue
can be handled by careful design of the service interface, when the service is meant to be
called directly from a UI (basically make sure the API only uses platform classes that won't
require downloading bytecode; this is no different from what people do for EJB usage).
+  * As of August 2011, Jini/River doesn't have anything similar to a BPEL engine that would
automatically handle business process persistence, compensation, etc.  That functionality
would be convenient, however it is possible to implement a business process in plain Java.
 For short-lived processes (micro-flows), it's probably easier to use plain Java.
+  * The Service Registry/Repository in XML-based SOA is used for a different purpose from
Jini's registrar; it is more of a design-time repository of service metadata.  A user-friendly
front-end to an SCMS would do just as well for that purpose.
+  * Jini/River currently lacks "enterprise-y" features like deployment lifecycle governance,
centralized monitoring, centralized authorization, etc.  Centralized authentication and message-level
privacy is already built in to the JERI stack.
+  * We also lack a development environment that is friendly to "corporate-type" programmers.
 Although the overall complexity of Jini/River is arguably no greater than in the WS-* stack,
a WS-* organization has the option of just buying IBM's RAD or using the Weblogic stack. 
At the same time, these are expensive propositions.
  
+ With a little work on the deployment model, and perhaps a usable process engine, Jini/River
is an attractive SOA stack.
+ 

Mime
View raw message