The Dos and Don’ts of Oracle SOA

The do’s and don’ts of Oracle Service Oriented Architecture (SOA) Suite is a hard list to pin down. For every item listed there is, no doubt, an exception. This blog deals with the 98% of the use cases one will encounter on their SOA journey. This blog was written with Oracle SOA Suite 11g in mind, but most of the high-level concepts will apply to other versions and probably most SOA technologies.

Do – Use Enterprise objects

While developing a SOA strategy it is important to think about the enterprise and think about reuse. Many IT projects have a narrow focus and don’t always consider the big picture. With SOA, considering the big picture will often help develop a reusable, high-value solution for your client. Consider a customer developing an integration into Oracle EBS (Oracle’s main ERP product). The project could develop the integration to tightly couple with the application that is being integrated to, or they can plan for the future and build the integration in a reusable manner. The latter allows for future reuse as well as reduced support issues since the client’s team only has to support one integration.

Do – KISS the data models

Within Oracle’s AIA product there are expansive data models that accommodate almost all situations a customer may face. If the enterprise models are being developed in-house, they should be tailored to the needs of the business. It makes little sense to develop data models that are so generic that it makes it difficult for developers to use – because they won’t. The data models should be simple, agile, expandable and reusable. Trying to create the “one true model” will just result in a future model being created for the next project.

Don’t – Using SOA to replace JAVA (or PL/SQL)

Because SOA gives the developer many different programming constructs, the architect and the developer have to continuously fight the urge to use SOA for complex processing. All BPEL constructs should be used in support of an integration between systems, not as a program itself. For example, suppose a process is performing several complicated queries within a database. If that process isn’t calling out to any other system and performs complicated logic, (for loops, if statements, etc.) then it probably shouldn’t be implemented as a SOA composite. In this case, the endpoint should be a PL/SQL call with a SOA composite to proxy the call. The saying, “When all you have is a hammer, every problem looks like a nail” pertains here. If all the IT requirements start looking like nails, make sure you have more than one tool in the tool belt. SOA, like all tools, works best when it’s being used correctly.

Don’t – Use SOA to replace ETL jobs

ETL, or Extract Transform Load, is an application pattern for mass loading of data from one system to another. This is often seen in system synchronization or data warehousing. Although SOA could be used as an ETL tool, it isn’t the best for the job.  SOA should be mainly event driven; an event occurs and then certain processes need to happen. ETL is usually a batch job and is used on a large dataset. SOA can perform the task, but it may not be the best option.

DO – Take time to understand SOA Suite’s capabilities

Many customers I’ve worked with who haven’t used a SOA product usually don’t know the tool’s features/functions. Typically, SOA is brought into a company to fill an immediate need. If SOA Suite (and it’s capabilities) is properly socialized within a company, it will be quickly apparent there is a lot of built up demand. In many instances, I have visited clients who used and understood a subset of the features SOA Suite provides, but didn’t know anything about the rest of the product.  These holes in their knowledge led to the development of suboptimal solutions.

Did you find these do’s and don’ts useful? Let us know if you have any SOA related questions in the comments below.