On 14/12/2010 4:10 PM, Brian Topping wrote:
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.
We were so lucky to get Spring early by hiring a strong architect to
help get us started.
I would recommend that managers of new projects look at Spring. It takes
a bit of getting used to if you have a history of development with
traditional tools but it is really a great approach.
JNDI is so simple, I would recommend getting site specific stuff there
as quickly as possible. We discovered the real use of JNDI late in the
project. We wasted a lot of time and energy developing alternative
solutions to simple configuration problems that JNDI and Spring solved
rather effortlessly. We read the JNDI documentation and spent a lot of
time wondering why we could not find the complex details when, in fact,
there weren't any.
Ron
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
