The Official AIA Blog

Welcome to our blog! We are the development team responsible for the Oracle Application Integration Architecture (AIA). Being the Oracle SOA Implementation for integrating all our applications (not a simple feat, considering the number of acquisitions), we obviously have a strong view point on SOA and Enterprise Application Integrations in general.

Through this blog we will discuss these perspectives, and provide practical guidance on architecture, development and implementation of AIA. We will do this through regular feature articles on the various components, best practices and design patterns, and implementation tips and tricks. The blog will also allow us to share with you interesting viewpoints from other blogs, which we hope you will find relevant. If you have any specific topics you would like us to discuss, do communicate that through the comments.  And for those who are wondering what AIA is all about, read about it here.

This blog is just one of the ways we would like to connect with the AIA community. For detailed technical discussions, you can visit our discussion forum; and to discuss innovative ideas, experiences, project or strategy questions, join the AIA group on Oracle Mix.

- The AIA Team

Note: The authors of this blog follow the code of ethics set forth by Oracle, as well as our other blogging colleagues. The views expressed on this blog are those of the authors and do not necessarily reflect the views of Oracle.

The AIA Enterprise Business Services (EBS) represent the core business functions of an enterprise as they interact with the wider ecosystem of enterprises as part of day to day business interactions. They are not web services exposed by any business software application implemented in an enterprise.

Let me elaborate further. In any enterprise, we always find multitude of software applications implemented. This is mostly by design. Running a business is complicated and it is challenging to keep up with the competitors. In their quest to excel, enterprises seek best of the breed software applications evaluating their core functionalities. Thus an enterprise ends up with different software applications catering to Customer Management, Product Management, Asset Management, Order Management, Financial Management and so on. The stove pipes of applications are more narrower in scope, in reality.

The web services or APIs exposed by these software applications are granular in nature and represent their core functionalities. These applications need to be integrated in order for the enterprise to carry out the core business functions. For each of these business functions or tasks to be accomplished, multiple applications with their granular services need to participate.

The AIA Enterprise Business Services, representing these business functions or tasks, mediate the invocation of the granular web services between various participating applications.

Needless to say, the payloads of the AIA Enterprise Business Services are Enterprise Business Messages (EBM) and these represent the canonical data models of the industry in which the enterprise is doing business. They are not hostage to the participating application data models.

More on Enterprise Business Messages and Enterprise Business Objects (EBO) in next post.

On my way in from work this morning, I was stopped behind a car that had a bumper sticker that read oddly enough “NorCalBagels.com” and underneath the URL, “Bagel Rescue”. I readjusted my eyes and realized it actually said NorCalBeagles.com / Beagle Rescue. Phew, I was afraid there was serious bagel abuse taking place somewhere in Northern California.

I bring this up because it reminds me of an analyst article I read recently on Application Integration Architecture. In the article, the author asserted that because they had only been able to find one customer, AIA was not real. Had they taken a closer look, they would have found that what they thought was the case was actually quite the opposite.

Taken directly from the Oracle.com website -
“KPN Successfully Implements Oracle Application Integration Architecture” (Press release)

“Oracle Announces Implementation of Application Integration Architecture (AIA) with Trade Promotion Management System”
Excerpt: The J.M. Smucker Company is the first Oracle customer to deploy the new Application Integration Architecture (AIA) with Siebel CRM Integration Pack for Oracle Trade Promotion Management. (Press release)

“Post-integration ROI”
"Oracle Application Integration Architecture can dramatically simplify what I had assumed was going to turn into a very complex environment," says Martinelli. [Rackable Systems] (Profit Online article)

I guess the moral here is quite simply, if at first it doesn’t look right, it probably isn’t. Better look again through a different lens.

Now where did I put my bagel...

The SOA Design Patterns site (and book) has an interesting chapter on the topic of schema centralization.  The recommended solution is essentially the pattern used in AIA.

1. Establish your service inventory using a top-down business process model driven approach.

2. Identify the Enterprise Business Objects (EBO) and Enterprise Business Messages (EBM). 

3. Create the EBO Schema canonical definitions using the industry standards.

4. Create the Enterprise Business Services (EBS) utilizing the EBMs created above.

The Case Study section in the end is empty, but AIA could very well be its best case study!

As an architect explaining SOA concepts to developers of traditional enterprise applications, I encountered various analogies comparing the concepts of SOA to Lego^TM blocks, which are actually considered by some experts as being misleading and superficial. Therefore, recent analogies by Antony Reynolds and Richard Veryard comparing services to a laundry, brought back memories of yet another analogy I used a couple of years ago - comparing business process driven SOA to home construction.

Let’s pretend you want to build a house from the ground up. You hire a general contractor, who is responsible for the overall execution of the project. The contractor locates a provider of concrete and makes a phone call to ask for estimates and the schedule for pouring the foundation slab. Next, the contractor will call and coordinate the lumber delivery, following which the framers can come out to do their job. In parallel, the contractor gets estimates from electricians and has to decide on the one that not only has the best rates, but also someone who is certified as per city code and who can meet the schedule. And finally, the roofers, plumbers and painters are arranged to complete the job.

Let’s put this in the perspective of SOA technologies. The general contractor is a BPEL Process, whose purpose is to orchestrate all the Services from disparate heterogeneous systems. The services in this example are the different actors – the concrete provider, foundation company, lumber company, framers, electricians, roofers, plumbers and painters. The contractor found the providers by searching the Yellow Pages (UDDI) and found the phone listing (WSDL); communicated by voice (XML) over the phone (standards based Web Service) in English (Standardized Semantics). He got quote and availability information, without having to really understand much about the inner workings of the concrete business (Service Abstraction), and as long as the provider abides by the contract, the contractor does not care who the actual electrician is (Service Virtualization).

I found that this metaphor helped many a legacy developer understand the complex SOA technologies better than the overly simplistic Lego^TM blocks analogy. However, as recommended in the other blogs too, it is best to not push the metaphor too far. Once the SOA basics have been understood, its purpose is served; and no other simplistic metaphor can then explain every one of the prolific WS-<insert your favorite noun here> specifications.

UPDATE 07/30/2008: Richard points out a sequel to his laundry post: Services Not All Like Laundry. And just when we thought we had it all sorted out :)

The Enterprise Business Messages are the packets of data which the Enterprise Business Services accept from requesters and route to providers. They carry the pieces of data needed for the requests to be understood and serviced. Needless to say, these are unique to the industry the enterprise is in business and their structures have evolved over time. As I said before, they are hostage to no application.

An application finds its way into an enterprise because of its unique ability to address specific business requirements. In the process of developing this ability, the application comes up with unique data structures.

The Enterprise Business Messages (along with the Enterprise Business Objects) empower the enterprises to evaluate the applications and transform the disparate data structures (and underlying concepts) of these 'best of the breed' applications into enterprise concepts driving their business processes.

Thus an Order Capture application would have Order entities to capture the order while a Billing application may have ability to enable billing in Customer entities for the services rendered. A service industry specific Sales Order EBM would have the structure to represent the Order captured for a Customer in Order Capture system and turn it into Customer in a Billing system with billing enabled for the services rendered.