Why Alakai?

How practical is it really, to expect that your company will decompose all of its new and existing applications into stand-alone services so that they can then be re-assembled into new applications at some point in the future? Not very. This is, however, what the SOA approach would seem to imply.*

You should instead use a platform that allows you to employ the basic tenet of SOA as a best practice, i.e. the loose coupling of services in a language and platform agnostic fashion, while continuing to develop and maintain your services within the context of an application.

The alakai system allows you to expose the key pieces of functionality within an application by modeling the application as a top-level wsdl component. Consequently, the underlying services remain intact and remain an integral part of the underlying application. Your application's are, after all, coded as a single integrated unit for a good reason, i.e. because it's the most efficient way to design, test, deploy and maintain them.

This approach also makes coding the interaction between partners simpler and much more intuitive, i.e. by conceptualizing a partner as an application rather than as a set of unrelated endpoints. Please see the discussion on engine assignment which is located within the user guide and which highlights this simple and yet very powerful feature.

So this, in a nutshell, is what makes the alakai system such a compelling alternative to other SOA offerings. By being application rather than service focused, alakai effectively reduces the time and complexity involved in designing, testing and deploying your e-commerce applications, which ultimately translates into better quality applications which are delivered in less time.

* In practice, a stand-alone service would be appropriate in situations where the service provides utility type functionality, which, in alakai, would be modeled as a wsdl:application which exposes a single wsdl:role implemented by a single wsdl:actor .