Serverless computing promises greater scalability, faster development, more efficient deployment, and lower cost.

But the benefits of going serverless can feel out of reach for companies that rely heavily on Oracle stored procedures: named PL/SQL blocks which perform specific tasks and are commonly used for building complex enterprise applications on top of relational databases.

Exposing stored procedures has traditionally been an arduous and time-consuming task. And conventional solutions tend to lead to a layered and complex architecture that creates challenges at both design time and runtime for serverless functions.

The Challenge: Complexity of the Application Development Framework

Exposing Oracle stored procedures to other applications as web services has typically resulted in an extremely layered architecture that increases the complexity of the application, leads to reliance on proprietary tools, and increases technical debt.

That’s because the traditional approach to exposing Oracle Stored Procedures has been to wrap the PL/SQL in a proprietary Oracle Application Development Framework (ADF). Building the ADF Business Service, following the standard “Rules,” involves multiple manual steps, like:

• Creating a Domain layer for Entity Objects
• Defining View Objects
• Defining Query Objects
• Defining business rules and validation
• Binding Business Services with User Interface

This then requires the creation of an XML schema and the use of an XML process to access the ADF business component.

Teams that have gone down this route have typically found that the development process is slow and manual – even with developers with the specialized skills necessary to expose Oracle stored procedures. Relying on external consultants is costly, both upfront and for ongoing maintenance. And either way, this approach results in proprietary vendor lock-in.

#cloud #serverless architecture #stored procedures #oracle soa #serverless benefits #serverless api #serverless integration