Scalability means different things to different people. It’s like a group of blindfolded people touching an elephant on different sides. Each person will have their own explanation and individual experience. Similarly, in the Oracle SOA Suite world, expansion and scalability of an Oracle SOA Suite environment means different things for everyone. For Administrators, it’s about adding more managed and admin servers to the existing Oracle SOA environment. For SOA Developers, it means adding more services and BPEL processes in the existing service repository. For IT Management, it is about how they can expand their initial Oracle SOA footprint to add more systems, attain further ROI and truly expand to a service oriented architecture framework for their enterprise.
From an Oracle SOA Suite middleware perspective, a detailed analysis of your current environment should be done. Ask yourself some of the following, when planning for Oracle SOA Suite scalability and expansion:
- How much additional traffic can my current Oracle SOA Suite instance handle?
- How easy is it to add more storage capacity?
- How many more transactions can be processed?
In this series of 3 blog posts, I will focus on a few different components from service design, infrastructure setup and management/governance, which can be used as reference when you are considering scaling out your Oracle SOA Suite environment.
When designing a service, think about decoupling first. The more decoupled the services are, the better scalable they are.
- Avoid dependencies between services: Services must be designed for appropriate granularities that offer greater flexibility to service requestors without impacting performance and security.
- Use Enterprise Bus: Use Enterprise Service Bus or a Mediator to achieve service virtualization rather than interacting with end services directly. An ESB acts as a message broker between consumers and services.
- Think of reusability: Reusability is also another aspect that should be considered when designing the granular services to implement generic and reusable logic.
- Asynchronous vs synchronous:
a) Services invocation must be independent of the state of other services and each service invocation has all the required information from one request to another. This is acceptable as long as it occurs in the background and the principle can still be upheld for the specified service and its contract. By reducing resource consumption, the service can handle more requests in a reliable and scalable manner.
b) Do not call an asynchronous service from a synchronous service which may cause timeouts, thread blocks, etc.
- Oracle event delivery network (EDN): Use EDN if possible which provides maximum decoupling between participants.
In the next post, I will cover another important aspect: Sensible Oracle SOA Suite Infrastructure Setup, which plays a key role when considering scalability and expansion of your Oracle SOA Suite environment.