The realities of project deadlines, team skills, and tight budgets mean that building a Web services SOA (service-oriented
architecture) is less about choosing a technology than it is about spotting opportunities for maximum return on software investment.
Here are some core design principles to help you concoct a plan that will pay off soon and, with luck, over the long haul.
Start small.To gain experience and early wins, begin by “wrapping” existing interfaces with SOAP and WSDL to achieve one-way, point-to-point
integration. These first Web services should mimic current, data-centric APIs. Core, stable applications running on legacy
systems or established, well-defined trading partner applications are good candidates.
Read the road map.Don't let the relative ease of implementing Web services integration obscure the architectural vision. Plan for three stages
of sophistication and maturity: 1) read-only, data-centric services that mimic existing APIs; 2) two-way, transactional models
that leverage emerging standards and product capabilities; and 3) asynchronous, document-centric models that reflect the business
process focus of service-oriented design.
Let the business process lead.In each stage of SOA maturity, take a “business service” perspective. Design each Web service as a coarsely grained, discrete
task with business process inputs and outputs before specifying data types or APIs. The SOAP interface and its WSDL descriptor
should reflect this same process-centric approach, not the minutiae that many programming tools auto-generate.
Target high maintenance costs.Look for manual processes hidden in distributed functions such as field sales or customer support. Applications with high
costs of integration and management are good candidates for strategic investment in service-oriented design. Target systems
that require specialized skills to operate and develop, that demand dedicated hardware to function, or that need specially
licensed add-ons and adapters for interoperability.
Identify your core services platform.Most companies will start with work they've already done on J2EE or Windows servers. Others may want to choose another core
Web services platform. For example, SAP is slowly integrating Web services standards into its BAPI (Business API); companies
that rely heavily on SAP software may wish to wrap BAPI applications in SOAP and WSDL and go with SAP's definitions of common
business documents. Whatever you choose as your core platform, make sure the vendor embraces independent standards and can
prove solid interoperability. Membership in the WS-I standards organization is a good sign.
Build shared infrastructure services.An SOA composed of heterogeneous systems must draw on its own special set of services to ensure everything is reliable, manageable,
and secure. Web services management products help address these needs by providing functions such as version control and QoS,
but other core needs such as authentication likely will be assembled from existing infrastructure such as identity management
systems. Basic application utilities such as logging and data transformation are also good candidates for shared services.
Finally, remember that the perfect is the enemy of the good. In IT, too many projects ultimately fail because managers refuse
to make practical compromises or harbor religious convictions about one architectural vision or another. Don’t let the evolving
set of Web services standards for security or complex transactions scare you from starting work. In many ways, pragmatism
defines the philosophical core of SOA. Web services standards and software solutions will continue to mature. But the goal
of service-oriented computing is feasible today.
E-mail
Printer Friendly
Reprints
(InfoWorld) - In the litigious world we live in, deploying a unified communications platform in your enterprise could...
