SOA is an ill-defined and much over touted term. However, regardless of definition it is widely accepted that one of the benefits of adopting a service oriented approach is to increase flexibility. To date though this flexibility has been pretty much limited to coarse grained web service wrapping of existing systems.
As a developer you should expect to be able to obtain flexibility with a much more fine grained approach, right down to the business objects level. Until recently this has been difficult, if not impossible, to achieve. There is however a significant move towards delivering this fine-grained flexibility, making it easier to build applications, and making you much more productive. Two standards are helping to realize this goal, namely OSGi™ and SCA, and they are both backed by most of the big names in the industry including IBM, Oracle (and BEA Systems), Red Hat, SAP and SpringSource, to name a few.
OSGi makes it easy to realize composite application development and achieve true component re-use. Providing comprehensive component lifecycle management, OSGi makes it easy to install, start, stop, update and uninstall components and allows for 'zero' down-time patching/upgrading and the ability to add functionality on-demand. OSGi also addresses the management issues caused by components evolving at different rates (a.k.a. DLL/Jar hell), as OSGi allows components of the same type, but of different versions, to be used in the same JVM runtime.
SCA allows you to easily mix and match your network and implementation strategies without complicating your business objects. Under the stewardship of OASIS, SCA provides a way of describing how to create a composite application by defining which components are required and how they should be wired together . SCA is implementation neutral; neither protocol or application infrastructure is mandated and connectivity between composites is defined using SCA bindings.
SCA uses SCDL ( Service Component Definition Language), an XML-based description, to provide a structural description of the composite application. This can include the required application and infrastructure components, their configurations, and which bindings to use. This loose coupling of components and bindings makes it very flexible. For example, to change two composites that communicate via SOAP to use JMS instead, is simply achieved by changing the relevant SOAP SCA bindings to the appropriate JMS SCA bindings.
Infiniflow leverages both OSGi and SCA and offers the opportunity to focus on writing the business logic as components, which can be reused for many different requirements, and letting the runtime automatically take care of the resilience and scalability that the application requires. |
