Java Reference
In-Depth Information
NOTE
Many IT projects include a user-facing presentation layer. Often, only certain aspects of a project
should be written as a service on the backend. Service-oriented architects need to communicate with
project managers across projects or products to coordinate their efforts. This can be challenging in an
environment used to dedicated project teams.
Businesses that are relatively young, have few disparate systems, or are generally very for-
ward thinking might benefit most from this approach. It is easier for businesses to champion
SOA efforts in such a scenario, as they get new products delivered that have been on their
wish list.
A bottom-upapproach starts from the view of a legacy technology. It takes existing function-
ality and wraps it in a service in order to achieve more general business goals such as in-
creased agility, interoperability, or eased integration. This can sometimes be termed “service
enablement”: the basic functionality exists already, but you make it available as a first-class
citizen within a service-oriented architecture.
This approach starts by identifying “pain points” within the enterprise that could be usefully
addressed as a service. This is a common approach if you have had no architects doing forward
planning work with your systems integration, and find yourself with an “accidental architec-
ture” of rampant, undocumented, proprietary, or generally ugly point-to-point communica-
tions. If this is the case, you must approach such an effort with caution, taking care to under-
stand the processes that are already using this tightly coupled functionality.
The business realizes value with this approach by freeing up previously complicated intersec-
tions of technology for greater agility and flexibility going forward. This can translate directly
into shorter time to market.
This approach may work best for companies that have been in business for decades, have lots
of legacy systems, use a wide range of disparate platforms (possibly as the result of many mer-
gers or acquisitions), or have many existing point-to-point connections. But beware of simply
taking the existing interfaces of these legacy systems and then making a web service out of
them. A bad interface that runs with SOAP over HTTP is still a bad interface. Designing the
interfaces so that they will be usable going forward often means that you have to do some
overhaul within current state business models (that you might have defined using a top-down
approach for something else).
A bottom-up approach rarely works. IT can end up being the driver, which you don't want.
The business needs to be aware of SOA and assist in the governance and the definition of pro-
cesses. The interfaces of the future are not likely to be found in legacy code. Legacy code can
