eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I noted in my June 12 letter my then-upcoming talk at that weeks Ziff Davis CIO Summit, where I discussed service-oriented architecture and the future-enabling of enterprise systems. I stressed in that talk the distinction between Web services (the technology) and SOA (the potential achievement). Con-Way Transportation Services, for example, built an integration bus and created an event-driven environment that addressed both its own needs and those of its customers—without waiting for Web services standards to define its approach. Conversely, todays compelling ease of exposing functions as services doesnt necessarily lead to SOA, any more than the use of an object-oriented language leads to taxonomies of semantically complete and broadly reusable business objects.
There are, I said in Napa, three key ways to do SOA wrong. You can allow each application silo to grow its own services stack, instead of defining one SOA environment and making applications conform to it. You can let service creation run wild instead of defining a governable process. You can make services easier to reinvent than reuse instead of stressing discoverability.
As is often the case, the technology most commonly available to developers makes it possible to do the right thing, but doesnt make it even the path of least resistance—let alone an enforceable discipline. I spoke last week about solving that problem with the management team at Systinet, which as of this past February has become a division of Mercury Interactive following a $105 million (cash) acquisition. On June 19, Version 2.0 of Systinets Policy Manager product will target that goal by improving the accessibility of enforceable policy creation. This major update will abstract low-level details to enable management-level policy statements, and will also provide both policy creation aids and out-of-the-box policy libraries that encode what the company considers best practices.
As we talked, I found myself thinking of todays bevy of increasingly affordable Global Positioning System receivers: They use the common infrastructure of the GPS satellites to provide generic location information, while also providing user memory for uploading custom maps—rather like any UDDI-based system that enables service discovery, enhanced by specific policies for process definition and deployment. It seems a useful analogy for anyone who needs to explain this to nontechnical management.
But even as Systinet offers greater rigor in defining and controlling infrastructure operations, Im also seeing creative application of a more ad hoc approach that tries things—and determines what doesnt work—and learns from that experience. The result is rapid evolution of an intelligent environment for the often-overlooked development bottleneck of building and rebuilding complex applications, using technology from Electric Cloud.
Its difficult to predict exactly what conflicts might arise in attempting to parallelize a nontrivial build, but Electric Cloud detects file dependencies by compiling against a virtual file system that yields precise information about file usage. The environment can then tailor the process accordingly to ensure that dependencies are not violated, with a new release last week making the resulting productivity gains available to users of Microsofts Visual Studio.
Tell me what youre trying, and how you decide what works, at [email protected].
Check out eWEEK.coms for the latest news, reviews and analysis in Web services.