Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

SOA for the real world

Transform your SOA experiment into an enterprise-grade implementation

By Ash Parikh and Murty Gurajada, JavaWorld.com, 11/29/06

Page 3 of 3

Components of an enterprise-grade SOA

The following section provides an overview of the necessary components for enabling an enterprise-grade SOA.

Service layer and registry

The focus of most SOA implementations today is on the service layer and often extends to the registry to publish and discover services. This approach to SOA is easy to comprehend. As mentioned previously, the concept of exposing services is not a new one. Most software architects and engineers have years of experience building services and should be comfortable applying their knowledge to expose services using the newer Web and XML technologies. Once the services are implemented, registry products based on UDDI (Universal Description, Discovery, and Integration) are used to publish and discover them.

With this architecture in place, enterprises already have much better visibility than was ever possible before WSDL (Web Services Description Language) and UDDI standards emerged on the scene. Unfortunately, it is because of this pleasing ROI that most implementations stop short in their tracks—that is, until it becomes apparent when trying to scale their model that a service layer with a registry is simply not enough for true SOA ROI.

More to SOA than meets the eye

When the typical SOA implementation based on the service layer and registry begins to see some success, the IT department and the business groups push to put more and more services on it. The volume of Web services published and consumed increases dramatically. This immediately puts focus on critical features that were not anticipated earlier.

The first feature requirement is the need for federated information management. Service consumers are suddenly exposed to hundreds, if not thousands, of services and need a federated view of the data and services to comprehend them.

The second requirement is the need for SOA data caching. The vast amounts of data resulting from a well-adopted SOA implementation cannot be accessed in a fast and reliable manner without some kind of caching.

The third requirement arises out of a painful realization that the data and services need an unprecedented level of governance to ensure their validity. SOA governance is the process of defining and enforcing organizational policies and standards. These policies are geared towards the business requirements of managing liabilities and dependencies, ensuring continuity of business operations, and reducing costs. They also benefit the IT departments by defining controls for service proliferation within the enterprise, incorporating evolving standards, and promoting interoperability.

The typical reflexive response of organizations is to address these issues in an ad-hoc manner, as they begin to surface. However, true SOA ROI is achieved only when organizations take a systematic and well-crafted approach to fulfilling these requirements.

SOA repository

Enter the SOA repository. The repository has the capability to provide a much richer set of services than a registry would, since it not only has access to the metadata around the services, but also the actual SOA data. Therefore, the metadata plus data-based discovery services provided by a repository are much more powerful than the registry's simple metadata-based services. The repository can also provide integrated policy management and transformation, federation, abstraction, and caching of SOA artifacts. Business processes and composite data services could be deployed and managed on an SOA repository to ensure that they are centralized, transparent, and therefore, easily governed.

For all the above reasons, the SOA repository is the core component of a well-designed SOA.

Workflow and business process management

A critical SOA goal that we talked about is achieving process visibility and flexibility. The service layer addresses this goal best, using workflow or business process management systems, which is emerging as a fast-growing segment of SOA. The vendors in this market range from pure-play BPM and workflow companies to EAI (enterprise application integration) and application server companies. The products vary in terms of price and maturity, but there is no doubt that we will see many excellent, cost-effective solutions for SOA implementations over the next few years.

A well-rounded workflow or BPM product should be both business-user and IT-department friendly. It should offer zero-code process modeling, simulation, execution, monitoring, and debugging. Ideally, the product should be nicely integrated with an SOA repository so that the workflows and business processes can be deployed as metadata for central governance. It should also support the development, deployment, and consumption of reusable composite data services.

Implementing SOA the right way

The figure below depicts a well-designed SOA.

A well-designed SOA should use a native XML database-powered metadata repository and data orchestration engine at its core. Click on thumbnail to view full-sized image.

A full-featured SOA repository is the core component of a well-designed service-oriented architecture. It should not only contain all the data and metadata relevant to an organization's functioning, but also provide a comprehensive set of features to manage these artifacts effectively.

A good SOA repository natively embeds data administration and governance services. It provides a comprehensive dictionary with semantic reconciliation capabilities. It allows the organization of data and services into meaningful taxonomies as well as provides lifecycle management and versioning services. It provides a full set of data services to perform quality management, validation, transformation, federation, governance, and caching.

These services are also automatically available to your business-process- and workflow-related artifacts, customized composite data services, and third-party services when you deploy them onto the SOA repository.

The other component featuring prominently in the diagram is the BPM/workflow platform. The application layer may discover and consume services directly from the service registry/repository layer, or it may go through the workflow/business process management platform for more flexibility.

While the BPM/workflow platform provides one set of services to applications, an external service layer could simultaneously register services for clients to discover and consume.

The importance of an SOA repository is not lost on most registry vendors. Today, many SOA registries have some sort of repository feature bundled into them. However, the richness of the feature set as well as the underlying implementation of the repository is critical to its success. Indeed, one reason repositories are being relegated to the back burner is because few implementations meet the rigorous functionality and performance requirements.

Native XML database and XQuery

We have noted that the repository deals with an immense amount of data, and therefore, it should be designed with a focus on performance and flexibility. The problem with most repository implementations is that they are based on traditional relational databases, which are simply not agile enough to handle the query loads generated even by a mid-sized SOA implementation. All SOA data—the artifacts as well as the messages—are in XML and have a hierarchical representation, which is not well suited for the rigidity of an RDBMS (relational database management system). This problem exacerbates as the SOA implementation grows to include more endpoints/providers, orchestrations, and subscribers. The lack of a powerful repository also complicates governance and administration. For instance, if you want to apply a change to a set of WSDLs in the registry, it is easier to do that with the powerful query capabilities of XQuery, which can select the right artifacts based on the query criteria and update them. Since most of the artifacts in an SOA are XML, native processing of all of the SOA XML data is needed. A truly responsive SOA repository must thus be implemented on a native XML database (XDMS) with XQuery for data management.

XQuery is a flexible and powerful language for XML data retrieval and management. Coupled with a native XDMS (XML database management system), you have an elegant, high-performance option to the complex and sluggish middle-tier conversions of your XML data using the traditional parsing approach with an RDBMS SOA artifacts store.

An XDMS supercharges the implementation of SOA by enabling data to be stored and manipulated as native XML. Of course, not all native XML databases are built the same way, nor do they offer the same features. A good XDMS should handle any type of XML data without prior knowledge of the XML Schema structure. This functionality proves highly advantageous when handling XML documents from federated systems with disparate datastructures. Powerful composite data services can then be built on top of such a platform.

Benefits of the correct approach

Using SOA in the right manner enables business efficiency, agility, and innovation through information on demand, service reuse, process optimization, and incorporation of innovative third-party Web services. Making the SOA registry and repository the cornerstone of the SOA ensures optimal administration, management, and governance of an enterprise's SOA infrastructure. SOA leads to a flexible architecture where several third-party Web services can be used to provide specialized functionality to a business process.

SOA can empower a wide variety of use cases, spanning a variety of systems across different geographical locations and trading partners. Going back to one of the examples we used earlier, many pharmaceutical companies use the National Drug Code (NDC) as part of their supply chain and regulatory processes. This NDC database is constantly updated as new drugs are added, recalled, or when patent protection on prescription drugs expire. An SOA-enabled enterprise can subscribe to a widely available NDC database Web service, which keeps this data current, and thus effectively use the data to flexibly evolve as new products are introduced or recalled products are removed from the pharmaceutical supply chain.

Similarly, for various regulatory reporting requirements that constantly evolve, data must be gathered from different IT systems. An SOA-based approach solves the problem elegantly, where several versions of similar Web services can be maintained in an SOA repository and dynamically chosen based on data parameters.

Conclusion

There are many challenges to implementing a successful, enterprise-grade SOA. The critical mistake most companies make lies in the gap between organizational goals and the actual investment in the right components and technologies to achieve those goals. Much effort is spent on the service layer, but the core component of the architecture, the SOA registry and repository, is not designed well enough to scale effectively. Moreover, organizations tend to forget about effective data management and governance services until it is too late.

Most of the enterprise data flowing within and between organizations is XML. The full potential of SOA can be realized if the implementation is built around the infrastructure that is best suited for the management of such data. A good native XML database coupled with XQuery as the basis for comprehensive data services provides a rock-solid foundation for a flexible, scalable, enterprise-grade SOA registry and repository.

We would like to thank Ajay Ramachandran, CTO, and vice president, XML-Centric Applications and Platforms group, and Premal Parikh, engineering manager and lead architect, XML-Centric Applications and Platforms group, at Raining Data for technically reviewing this article.

About the author

Murty Gurajada is a senior software architect in the XML-Centric Applications and Platforms team at Raining Data Corporation. He has been developing enterprise software for 11 years and has spent the last several years building and evangelizing innovations around SOA, BPM, and workflow platforms. He is a regular contributor of articles on SOA, BPM, and XML published in JavaWorld and other magazines. Gurajada is an active participant in OASIS technical committees and is a contributing member of the BIAS specification. His past experience also includes developing software for insurance, brokerage, and financial companies.

Ash Parikh is the director of technology and development for the XML-Centric Applications and Platform group at Raining Data Corporation. He is a named expert in the field of SOA and distributed computing and has presented and authored abstracts for OASIS Symposium 2005, Delphi BPX Summit 2004, Delphi Enterprise On-Demand 2004, JavaOne 2004, JavaOne 2003, BEA e-World 2002, and JavaOne 2002. Parikh has more than 15 years of IT experience and is an active member on a number of Java Specification Requests in the Java Community Process and in OASIS technical committees. He is also the president of the Bay Area Chapter of the Worldwide Institute of Software Architects and the co-chair of the SDForum Web services SIG. Parikh has also authored several technical articles in journals such as JavaWorld, XML-Journal, Java Pro, Web Services Journal, ADTmag, Softwaremag.com, and Java Skyline.

Read more about Enterprise Java in JavaWorld's Enterprise Java section.