These replies have been incredibly helpful, thanks especially to Ron and Stephen for your investment in them!
Very accidentally, I have fallen into the "MV-SOA" pattern. I am using Mule for the services container with the VM connector for speed and ease of iterative development, knowing that I can trade out the connector once the site scales into the datacenter and needs it. At the webapp level, what I've done is focus all command dispatches to a small class that either a) knows how to reach Mule or b) returns some mock objects. I've found developers who are good with both backend architecture and user interfaces are very rare. In "agile" environments, UI folks often are at the front line of working with business stakeholders though, and if they can't see the results of their work without also wiring the backend, they are quickly stuck. In small team situations, stakeholders respond to this by insisting that the architect is smoking something bad and being given an ultimatum to get the UI folks productive again or be replaced. As a response to this, I've found that making the command messages to the SOA core as a separate shared project between these realms as step one. Next, the web build is set up with a default implementation of the dispatcher that returns these command messages with mocked results. Practically, this is managed as a named Spring bean. Things change when a developer includes a single library that has the alternate implementation of the command dispatcher. When this library is loaded, it's alternate definition of the dispatcher overrides the mock dispatcher and is injected into the webapp accordingly. Now, when commands are dispatched, they transparently go to the SOA core instead of returning mocks. This could also be done with JNDI registrations and solves the same problem. This works at an organizational level because UI devs can create mock implementations in their own sandbox, then throw them over the fence to the core developers with very little documentation. A picture speaks a thousand words. All these artifacts are automatically deployed to Nexus by CI with sources after every checkin, so a developer that needs to trace source in the complimentary project need not have privileges on both projects. More restrictive environments are obviously possible. Along with Nexus, my svn repo is also slaved to LDAP, so authorization is easy to manage. One of the last things to note here: Spring or JNDI is not necessary for smaller projects, just use the classpath, whose namespace is naturally the sum of all loaded artifacts. If a build includes a new artifact and that artifact includes additional configuration, use it. Using the same name for the configuration file in all artifacts helps here, when doing a getResources() for a single filename, you'll be given a list of all classpath files that exist across your various jars. Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
