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. +
