Finding the Compromise – the Adapter Framework - Applied SOA Patterns on the Oracle Platform - page 360

Chapter 6. Finding the Compromise - the
Adapter Framework
This chapter concludes our discussion on the core compulsory SOA frameworks, present-
ing the last framework (ABCS according to AIA notations) and all the SOA patterns asso-
ciated with it. This framework is also optional and probably even more undesirable for pure
(theoretical) SOA, but it is still one of the most extensive and heavier layers in most tech-
nical infrastructures of modern enterprises. Why? Because of all the legacy applications en-
terprises have? Let's check our calendar—the concepts of unified standard contracts and ca-
nonical APIs (Official Endpoint, Canonical Schema, Canonical Expression, and Canonical
Protocol SOA Patterns) weren't invented yesterday; they are more than ten years old and
have been cornerstones of contemporary SOA since 1999. With an average lifespan of any
core ERP/CRM/SCM bundle in an enterprise of about six years, all that dinosaurs requiring
adapters for smooth plugging to the EBS framework (Service Bus) should be as good as
gone. So, what are the reasons to keep this layer irrationally thick nowadays? Integration
efforts are considerable not only on domain edges, but also within domains, and that raises
questions about domain boundaries in general.
How can we minimize our integration efforts and focus mostly on services/components
collaboration? Can we avoid building adapters? What SOA Patterns could help us over-
come the interfaces disparity? Are there any ways of reusing adapters? We will try to cover
these and some other questions in this chapter. We will continue developing the transport
adapter framework attached to the Adapter Factory, as discussed in Chapter 4 , From Tradi-
tional Integration to Composition - Enterprise Business Services . We will also touch upon
more traditional ways of establishing adapters using BPEL/SCA, but our main objective is
to demonstrate some ways of making applications more service-oriented in order to avoid
creating extensive Adapter frameworks, and here we will utilize some service metadata
taxonomies developed in the previous chapter.