Oracle SOA Infrastructure Deployment Models/Patterns

Transcription

1 Oracle SOA Infrastructure Deployment Models/Patterns by Kathiravan Udayakumar This article will introduce various SOA Infrastructure deployment patterns available with Oracle SOA Suite Choosing the right deployment pattern will aid in reducing the cost, provide better performance and scalability. The objective of this article is to introduce various deployment styles and patterns available under each SOA Layers and not to introduce various topologies that suites your environment. Different patterns provided in this article below can be mixed and matched to derive right topology for your environment to suite your environment. 1. Integrated Messaging Layer Deployment Pattern (JMS and Oracle SOA Components in same Weblogic Runtime) 2. Isolated Messaging Layer Deployment Pattern (JMS and Oracle SOA Components in different Weblogic Runtime) 3. Integrated B2B Deployment Pattern (B2B and Oracle SOA Components in same Weblogic Runtime) 4. Isolated B2B Deployment Pattern (B2B and Oracle SOA Components in different Weblogic Runtime) 5. Integrated BAM Deployment Pattern (BAM and Oracle SOA Components in same Weblogic Runtime) 6. Isolated BAM Deployment Pattern (BAM and Oracle SOA Components in different Weblogic Runtime) 7. Integrated Service Bus Deployment Pattern (OSB and Oracle SOA Components in same Weblogic Runtime) 8. Isolated Service Bus Deployment Pattern (OSB and Oracle SOA Components in different Weblogic Runtime) 9. DR with WSM Deployment Pattern (Whole Server Migration Enabled Weblogic Servers for Disaster Recovery and Highly Available) 10. Exa* based Deployment Pattern (Oracle ExaData as Meta Data Store; Oracle Weblogic for Weblogic Runtime) 11. Cloud Based Process Deployment Pattern (SOA Infra as Service (Cloud Based Environments AWS, Oracle Cloud)) 12. Virtual SOA Deployment Pattern (SOA as Virtualized Environments)

2 Integrated Messaging Layer Deployment Pattern Integrated Messaging Layer is most common pattern in deploying the Oracle SOA Components and JMS Infrastructures. This pattern is applicable to small and medium size Fusion Middleware deployments where the JMS messages process is least or minimally used and does not require a complex setup of file systems and hardware. Queue based communication is least in this pattern and it is also applicable for setting up non prod environment in cases where JMS message is used heavily in Production. Applicable Components: JMS and Oracle SOA Components in same Weblogic Runtime and they share the memory for process the SOA Process request and JMS Messages. This pattern is applicable when Oracle JMS is chosen as Service Messaging Layer. Implementing the SOA Infrastructure using this pattern is less scalable compared to other patterns to follow. If JMS or SOA Processes require more memory for process than the predicted amount during the implementation it may not be able scale-up higher due fight for resources constraints. Easily maintainable due to less over-head in the architecture and less redundant nodes. of message delivery is higher in this pattern as JMS and SOA Components are deployed in same web-logic runtime. Additional overhead in configuring SFAs (Store and Forward Agents) not required in this case SOA and JMS are always available as these components run together on same Weblogic runtime. could be lower when messages of huge size and heavy process requirements are introduced by the end applications. SOA Processing power could be reduced due to this. Caution: This Pattern is recommended for Development and Test Environments. Implementing this style of deployment for Production needs to be carefully sized for future growth of the message persistence needs and SOA Process. 2

3 Isolated Messaging Layer Deployment Pattern Isolated Messaging Layer is specialised pattern in deploying the Oracle SOA Components and JMS Infrastructures. This pattern is applicable to medium and large size Fusion Middleware deployments where the JMS messages process is heavy used and. Queue based communication is maximum in this pattern and it is also applicable for setting up prod environment. Applicable Components: JMS and Oracle SOA Components in different Weblogic Runtime and they don t share the memory to process the SOA Process request or JMS Messages. This pattern is applicable when Oracle JMS is chosen as Service Messaging Layer. Implementing the SOA Infrastructure using this pattern helps to scale your SOA Infrastructure in multi-fold. If JMS or SOA Processes require more memory for process than the predicted amount during the implementation it possible for scaling up higher by adding additional hardware and memory to the respective machines in which they are hosted. Weblogic also provides options to tune JMS server for optimal process as it will not interrupted by other processes Increases the cost in maintenance as this pattern utilizes different hardware and infrastructure for hosting the JMS and SOA Components. of message delivery is still higher in this pattern as JMS and SOA Components. SFAs (Store and Forward Agents) can be used if required to forward the message between different server sites. As SOA Components and JMS components run on two different runtimes; they could be possibility either one of them is not available; however high availability architecture can be utilized to make them always available. of SOA and JMS Services can be scaled and tuned independent of each. Caution: This Pattern requires additional and complex setup of file systems and hardware for JMS Message Processing.

4 Integrated B2B Layer Deployment Pattern SOA and B2B are bundled together in Oracle SOA Suite and most of the time we install both the components to same runtime. This architecture and deployment pattern might be suitable for development and cases in which the B2B is utilized to very less extent or never used but it may not be suitable for enterprise that choose the integrate with large number of trading partners. Applicable Components: B2B and Oracle SOA Components in same Weblogic Runtime and they share the memory for process the SOA Process request and B2B Messages. This pattern is applicable when Oracle B2B is chosen as Service Isolation Layer. Implementing the SOA Infrastructure using this pattern is less scalable compared to other patterns to follow. If B2B or SOA Processes require more memory for process than the predicted amount during the implementation it may not be able scale-up higher due fight for resources constraints. Easily maintainable due to less over-head in the architecture and less redundant nodes. of message delivery is higher in this pattern as B2B and SOA Components are deployed in same web-logic runtime. Additional overhead in configuring SFAs (Store and Forward Agents) not required in this case SOA and B2B are always available as these components run together on same Weblogic runtime. could be lower, when messages of huge size and heavy process requirements are introduced by the end applications. SOA and B2B Processing capabilities could be reduced due to this. Caution: This Pattern is recommended for Development and Test Environments. Implementing this style of deployment for Production needs to be carefully sized for future growth SOA Process or B2B Messages 4

5 Isolated B2B Deployment Pattern Isolated Messaging Layer is specialised pattern in deploying the Oracle SOA Components and B2B Infrastructures. This pattern is applicable to medium and large size Fusion Middleware deployments where the B2B messages process usage is heavy. Applicable Components: B2B and Oracle SOA Components are hosted in different Weblogic Runtime and they don t share the memory to process the SOA Process request or B2B Messages. This pattern is applicable when Oracle B2B is chosen as Service Externalization Layer. Implementing the SOA Infrastructure using this pattern helps to scale your SOA Infrastructure in multi-fold. If B2B or SOA Processes require more memory for process than the predicted amount during the implementation it possible for scaling up higher by adding additional hardware and memory to the respective machines in which they are hosted. Weblogic also provides options to tune JMS server for optimal process as it will not interrupted by other processes Increases the cost in maintenance as this pattern utilizes different hardware and infrastructure for hosting the B2B and SOA Components. of message delivery is still higher in this pattern as B2B and SOA Components. SFAs (Store and Forward Agents) can be used if required to forward the message between different server sites. As SOA Components and B2B components run on two different runtimes; they could be possibility either one of them is not available; however high availability architecture can be utilized to make them always available. of SOA and B2B Services can be scaled and tuned independent of each. Caution: This Pattern requires additional and complex setup of file systems and hardware for B2B Message Processing.

6 Integrated BAM Layer Deployment Pattern SOA and BAM are bundled together in Oracle SOA Suite and most of the time we install both the components to same runtime. This architecture and deployment pattern might be suitable for development and cases in which the BAM is utilized to very less extent or never used but it may not be suitable for enterprise that choose the integrate with large number of trading partners. Applicable Components: BAM and Oracle SOA Components in same Weblogic Runtime and they share the memory for process the SOA Process request and BAM Messages. This pattern is applicable when Oracle BAM is chosen as Service Monitoring Layer. Implementing the SOA Infrastructure using this pattern is less scalable compared to other patterns to follow. If BAM or SOA Processes require more memory for process than the predicted amount during the implementation it may not be able scale-up higher due fight for resources constraints. Easily maintainable due to less over-head in the architecture and less redundant nodes. of message delivery is higher in this pattern as BAM and SOA Components are deployed in same web-logic runtime. Additional overhead in configuring SFAs (Store and Forward Agents) not required in this case SOA and BAM are always available as these components run together on same Weblogic runtime. could be lower, when messages of huge size and heavy process requirements are introduced by the end applications. SOA and BAM Processing capabilities could be reduced due to this. Caution: This Pattern is recommended for Development and Test Environments. Implementing this style of deployment for Production needs to be carefully sized for future growth SOA Process or BAM Messages 6

7 Isolated BAM Deployment Pattern Isolated Messaging Layer is specialised pattern in deploying the Oracle SOA Components and BAM Infrastructures. This pattern is applicable to medium and large size Fusion Middleware deployments where the BAM messages process usage is heavy. Applicable Components: BAM and Oracle SOA Components are hosted in different Weblogic Runtime and they don t share the memory to process the SOA Process request or BAM Messages. This pattern is applicable when Oracle BAM is chosen as Service Monitoring Layer. Implementing the SOA Infrastructure using this pattern helps to scale your SOA Infrastructure in multi-fold. If BAM or SOA Processes require more memory for process than the predicted amount during the implementation it possible for scaling up higher by adding additional hardware and memory to the respective machines in which they are hosted. Weblogic also provides options to tune JMS server for optimal process as it will not interrupted by other processes Increases the cost in maintenance as this pattern utilizes different hardware and infrastructure for hosting the BAM and SOA Components. of message delivery is still higher in this pattern as BAM and SOA Components. SFAs (Store and Forward Agents) can be used if required to forward the message between different server sites. As SOA Components and BAM components run on two different runtimes; they could be possibility either one of them is not available; however high availability architecture can be utilized to make them always available. of SOA and BAM Services can be scaled and tuned independent of each. Caution: This Pattern requires additional and complex setup of file systems and hardware for BAM Message Processing.

8 Integrated Service Bus Deployment Pattern SOA and OSB are bundled together in Oracle SOA Suite and most of the time we install both the components to same runtime. This architecture and deployment pattern might be suitable for development and cases in which the OSB is utilized to very less extent or never used but it may not be suitable for enterprise that choose the integrate with large number of trading partners. Applicable Components: OSB and Oracle SOA Components in same Weblogic Runtime and they share the memory for process the SOA Process request and OSB Messages. This pattern is applicable when Oracle Service Bus is chosen as Service Monitoring Layer. Implementing the SOA Infrastructure using this pattern is less scalable compared to other patterns to follow. If OSB or SOA Processes require more memory for process than the predicted amount during the implementation it may not be able scale-up higher due fight for resources constraints. Easily maintainable due to less over-head in the architecture and less redundant nodes. of message delivery is higher in this pattern as OSB and SOA Components are deployed in same web-logic runtime. Additional overhead in configuring SFAs (Store and Forward Agents) not required in this case SOA and OSB are always available as these components run together on same Weblogic runtime. could be lower, when messages of huge size and heavy process requirements are introduced by the end applications. SOA and OSB Processing capabilities could be reduced due to this. Caution: This Pattern is recommended for Development and Test Environments. Implementing this style of deployment for Production needs to be carefully sized for future growth SOA Process or OSB Messages 8

9 Isolated Service Bus Deployment Pattern Isolated Messaging Layer is specialised pattern in deploying the Oracle SOA Components and OSB Infrastructures. This pattern is applicable to medium and large size Fusion Middleware deployments where the OSB messages process usage is heavy. Applicable Components: OSB and Oracle SOA Components are hosted in different Weblogic Runtime and they don t share the memory to process the SOA Process request or OSB Messages. This pattern is applicable when Oracle Service Bus is chosen as Service Monitoring Layer. Implementing the SOA Infrastructure using this pattern helps to scale your SOA Infrastructure in multi-fold. If OSB or SOA Processes require more memory for process than the predicted amount during the implementation it possible for scaling up higher by adding additional hardware and memory to the respective machines in which they are hosted. Weblogic also provides options to tune JMS server for optimal process as it will not interrupted by other processes Increases the cost in maintenance as this pattern utilizes different hardware and infrastructure for hosting the OSB and SOA Components. of message delivery is still higher in this pattern as OSB and SOA Components. SFAs (Store and Forward Agents) can be used if required to forward the message between different server sites. As SOA Components and OSB components run on two different runtimes; they could be possibility either one of them is not available; however high availability architecture can be utilized to make them always available. of SOA and OSB Services can be scaled and tuned independent of each. Caution: This Pattern requires additional and complex setup of file systems and hardware for OSB Message Processing.

10 DR (Disaster Recovery) with WSM (Whole Server Migration) Deployment Pattern Whole Server migration is feature provided by Oracle Weblogic to setup DR (Disaster Recovery Environments). Using this feature the DR Environment can be setup to the Applicable Components: Weblogic. This pattern is applicable when Oracle Weblogic is chosen as Service Container Layer. This pattern doesn t dictate scalability however whole server migration helps to increase in the number of backup sites that before and by using Weblogic HA architecture SOA Infra can be made highly scalable (Vertical and Horizontal) based on the server hardware and selected operating systems. Maintenance is very high and requires complex skill and highly advanced skilled resources in case of trouble shooting and setup. of message delivery is very higher. Very Highly available across different sites and whole server would migrate without lose in the business transaction. This pattern support better business performance by provide zero down time. Caution: This Pattern is recommended for highly complex environments with requirements for 24x7 availability. Implementing this style of deployment for Production needs to be carefully sized and cost is very higher for implementation and maintenance. 10

11 Exa* based Deployment Pattern Oracle Engineered System provides Exa-Technologies for better performance of Database, Middleware and Application. Oracle SOA Infrastructure can be deployed using Exa-Technologies (Oracle ExaData and ExaLogic Machines). It is very cost effective solution as the hardware and software are tuned and tested for better performance. This pattern of SOA Deployment reduces implementation time, cost and provide TCO (total cost of ownership). Applicable Components: Oracle Database and Oracle Weblogic. This pattern is applicable when Oracle ExaData is chosen for implementing Service Metadata Layer and ExaLogic for Service Container Layer Implementing the SOA Infrastructure using this pattern helps to scale your SOA Infrastructure in multi-fold. Lower the cost of Maintenance as the engineered systems are fine tuned for better performance. Highly reliable as the Engineered Database and Weblogic Container are tested in the controlled environments. N/A Specialized performance boost can be obtained by choosing Exa* technologies with Infi-band and customized hardware and software configurations.

12 DR (Disaster Recovery) with WSM (Whole Server Migration) Deployment Pattern Whole Server migration is feature provided by Oracle Weblogic to setup DR (Disaster Recovery Environments). Using this feature the DR Environment can be setup to the Applicable Components: OSB and Oracle SOA Components in same Weblogic Runtime and they share the memory for process the SOA Process request and OSB Messages. This pattern is applicable when Oracle Service Bus is chosen as Service Monitoring Layer. This pattern doesn t dictate scalability however whole server migration helps to increase in the number of backup sites that before and by using Weblogic HA architecture SOA Infra can be made highly scalable (Vertical and Horizontal) based on the server hardware and selected operating systems. Maintenance is very high and requires complex skill and highly advanced skilled resources in case of trouble shooting and setup. of message delivery is very higher. Very Highly available across different sites and whole server would migrate without lose in the business transaction. This pattern support better business performance by provide zero down time. Caution: This Pattern is recommended for highly complex environments with requirements for 24x7 availability. Implementing this style of deployment for Production needs to be carefully sized and cost is very higher for implementation and maintenance. 12

13 Cloud Based Process Deployment Pattern Middleware is no exception to Cloud, if you choose to run your middleware process for utilizing the common services provided by external service providers you can choose the runtime in private, public or hybrid cloud. Very high; inherit feature of cloud Very Lows as it supported by external or Service Provider Less and it should be well defined in the contract High; inherent feature of Cloud High; inherent feature of Cloud Caution: Wide numbers of deployments are unknown and may be risk to run your middleware in this model; however the industry is slowly moving towards this model.

14 Virtual SOA Deployment Pattern Oracle VM is upcoming technology and promoted by Oracle in Cloud Space. Virtual Machines can be used to deploy the SOA Components for easy rollouts to avoid wait period (building the environments). This pattern is currently used for Development and Test Environments. Production Deployment using this pattern is still unknown and not recommended. Very high; inherit feature of Virtualization Very Lows; inherit feature of Virtualization Low; as the Oracle VM Products are yet to stabilize. High and can be rebuilt in no time. Inherit feature of Virtualization Lower than the Physical Server of similar configuration. inherit feature of Virtualization Caution: Oracle doesn t support VMware which is disadvantage if you choose this pattern and you may need to procure additional license for Oracle VM if your eager to go down this path. 14