Frank Leymann wrote: > Anne, > what do you do when your business processes must change? If process > logic is scattered across business objects you have all the known > governance/management problems (find the affected objects, change them, > redistribute them etc).
One of the primary things about SOA is that you have "services". If you're using a wide number of varied clients of the services, and you have to update lots of clients, then you've not predicted and accounted for your architecture very well. Instead, if you use technologies such as Java's mobile code, then you can simply update the downloaded client jar(s) with the right code, and the next invocation gets the new updated version. If you properly version your jar files, then you'll even be able to let the old clients run, indefinately with that old code if that is needed. You might also choose to use a smart proxy which performs service discovery automatically, and it might take note of the client codebase change, and activate access to the new service endpoint without the "client" ever knowing that the service was switched out. If you choose this path, then you magically, also have support for automatic service failover as well. Typically people use this for automatic service failover, and get automatic versioning as an extra bonus for that choice. However, if you are using a different programing platform, or choosing not to use mobile code at the level that Java provides (and Jini extends), then yes, you will likely have all kinds of issues related to clients knowing too much about the the orchestration and choreography, and then presto, you out in the middle of the whitewater, sideways with no paddle. Gregg Wonderly
