Thomas Plunkett - SOA with Java: Realizing Service-Orientation with Java Technologies

NovoBank has successfully completed the first roll-out of their next-generation banking system. The SOA architects at NovoBank were able to achieve the three main objectives of their transformation program as follows:

Improve Time-to-Market NovoBank was able to build a layer of business, utility, task, and entity services to help decouple their channel applications from the core legacy banking systems. With the availability of a reusable set of business services, enhancing existing channel applications is much easier than before. None of the channels are tightly coupled with any of the core systems. NovoBank was able to optimize their business processes and drive greater automation through the use of new orchestration services composed of different business, utility, and task services. The availability of different services affords the IT staff the ability to compose in different contexts in different business processes.

Reduce Operational Costs The technical costs of ongoing application maintenance or system integration efforts have been reduced by 20%. The bulk of cost savings were realized by leveraging the new services and avoiding one-off, custom developments in channel applications. However, the original target of 30% cost reduction in the IT maintenance budget was not met as some of the up-front costs of building out an SOA landscape and introducing SOA infrastructure solutions, such as ESBs, partially offset the cost reductions seen in routine maintenance efforts. However, it is expected that an economy of scale can be achieved with the services as more applications within other divisions in the bank begin using those services to avoid ground-up custom development.

However, along the way, NovoBank encountered the following challenges:

Emergence of Mobile Computing The proliferation of mobile devices, such as smartphones and tablets, made it imperative for NovoBank to introduce online banking applications. However, building applications to consume SOAP-based Web services was complicated. NovoBank IT staff realized they must build, at least in the short-to-medium term, REST API wrappers over their existing Web services that can be easily consumed by mobile applications. The architecture team is evaluating popular API management platforms to manage expansion in the mobile computing domain.

Complexity of the Industry Standard Models NovoBank standardized their canonical schema models on industrial financial messaging standards, but the complexity of the financial message schemas resulted in significant overheads during message parsing in their Web service implementations. In the end, NovoBank simplified the schema models to avoid unacceptable implementation and performance overheads.

A.2 SmartCredit Co.

SmartCredit was successful in building a set of REST Web APIs allowing retail chain stores to submit credit card applications on behalf of their customers. Store clerks can submit the applications from different mobile devices using the mobile applications built for SmartCredit by a third-party contractor. The simplicity of the REST APIs and the ubiquity of the HTTP communications protocol and data formats (mostly JSON, some XML) have helped the mobile credit card application scale well. The widespread in-store usage has also led to an increase in business volume for the retail stores. The successful adoption of the applications and resulting business has been noticed by a competitive retail chain, which is in negotiations with SmartCredit to enter into a similar partnership.

Technical implementation considerations aside, the SmartCredit IT team followed the service design principles outlined in this book to ensure services are built modular, reusable, and lightweight to offer immediate value to a wide variety of service consumers. SmartCredit spent a significant amount of time building the REST service contracts by focusing on identifying the resources, the associated representations, the corresponding media-types, and the appropriate, semantically correct application of uniform interface HTTP operations on those resources. Even though the JAX-RS APIs proved to be an efficient tool to build REST APIs, the top-down design approach supported by SmartCredit was effective in the adoption of the APIs.

As with any other complex IT initiative, the implementation was not without challenges. SmartCredit made a conscious up-front decision not to make use of any custom media types, as they were initially skeptical of introducing additional coupling through non-standard media types. However, the impending partnership with another retail chain and the need to accommodate slightly different forms of credit applications with different resource schemas resulted in the need to introduce custom media types. Rather than using the generic application/json or application/xml media type, SmartCredit is looking at using the following custom types:

application/vnd.com.smartcredit.creditapp+json

application/vnd.com.smartcredit.creditapp+xml

The custom media types will be able to communicate semantics about the resources in question and will help better enforce the service contract. SmartCredit will follow this approach for their next round of implementation.

Appendix B. Service-Orientation Principles Reference

This appendix provides profile tables for the eight design principles that are documented in SOA Principles of Service Design, a title that is part of this book series.

Every profile table contains the following sections:

Short Definition A concise, single-statement definition that establishes the fundamental purpose of the principle.

Long Definition A longer description of the principle that provides more detail as to what it is intended to accomplish.

Goals A list of specific design goals that are expected from the application of the principle. Essentially, this list provides the ultimate results of the principles realization.

Design Characteristics A list of specific design characteristics that can be realized via the application of the principle. This provides some insight as to how the principle ends up shaping the service.

Implementation Requirements A list of common prerequisites for effectively applying the design principle. These can range from technology to organizational requirements.

Note that these tables provide only summarized content from the original publication. Information about service-orientation principles is also published online at SOAPrinciples.com and ServiceOrientation.com.

Table B.1 A profile for the Standardized Service Contract principle

Table B.2 A profile for the Service Loose Coupling principle