Different SOA Domain Configurations

In this blog entry I would like to introduce three different configurations for a SOA environment.  I have omitted load balancers and OTD/OHS as they introduce a whole new round of discussion.  For each possible deployment architecture I have identified some of the advantages.

Super Domain

This is a single EDG style domain for everything needed for SOA/OSB.   It extends the standard EDG slightly but otherwise assumes a single “super” domain.

This is basically the SOA EDG.  I have broken out JMS servers and Coherence servers to improve scalability and reduce dependencies.

Key Points

• Separate JMS allows those servers to be kept up separately from rest of SOA Domain, allowing JMS clients to post messages even if rest of domain is unavailable.
• JMS servers are only used to host application specific JMS destinations, SOA/OSB JMS destinations remain in relevant SOA/OSB managed servers.
• Separate Coherence servers allow OSB cache to be offloaded from OSB servers.
• Use of Coherence by other components as a shared infrastructure data grid service.
• Coherence cluster may be managed by WLS but more likely run as a standalone Coherence cluster.

Benefits

• Single Administration Point (1 Admin Server)
• Closely follows EDG with addition of application specific JMS servers and standalone Coherence servers for OSB caching and application specific caches.
• Coherence grid can be scaled independent of OSB/SOA.
• JMS queues provide for inter-application communication.

Drawbacks

• Patching is an all or nothing affair.
• Startup time for SOA may be slow if large number of composites deployed.

Multiple Domains

This extends the EDG into multiple domains, allowing separate management and update of these domains.  I see this type of configuration quite often with customers, although some don't have OWSM, others don't have separate Coherence etc.

SOA & BAM are kept in the same domain as little benefit is obtained by separating them.

Key Points

• Separate JMS allows those servers to be kept up separately from rest of SOA Domain, allowing JMS clients to post messages even if other domains are unavailable.
• JMS servers are only used to host application specific JMS destinations, SOA/OSB JMS destinations remain in relevant SOA/OSB managed servers.
• Separate Coherence servers allow OSB cache to be offloaded from OSB servers.
• Use of Coherence by other components as a shared infrastructure data grid service.
• Coherence cluster may be managed by WLS but more likely run as a standalone Coherence cluster.

Benefits

• Follows EDG but in separate domains and with addition of application specific JMS servers and standalone Coherence servers for OSB caching and application specific caches.
• Coherence grid can be scaled independent of OSB/SOA.
• JMS queues provide for inter-application communication.
• Patch lifecycle of OSB/SOA/JMS are no longer lock stepped.
• JMS may be kept running independently of other domains allowing applications to insert messages fro later consumption by SOA/OSB.
• OSB may be kept running independent of other domains, allowing service virtualization to continue independent of other domains availability.
• All domains use same OWSM policy store (MDS-WSM).

Drawbacks

• Multiple domains to manage and configure.
• Multiple Admin servers (single view requires use of Grid Control)
• Multiple Admin servers/WSM clusters waste resources.
• Additional homes needed to enjoy benefits of separate patching.
• Cross domain trust needs setting up to simplify cross domain interactions.
• Startup time for SOA may be slow if large number of composites deployed.

Shared Service Environment

This model extends the previous multiple domain arrangement to provide a true shared service environment.

This extends the previous model by allowing multiple additional SOA domains and/or other domains to take advantage of the shared services.  Only one non-shared domain is shown, but there could be multiple, allowing groups of applications to share patching independent of other application groups.

Key Points

• Separate JMS allows those servers to be kept up separately from rest of SOA Domain, allowing JMS clients to post messages even if other domains are unavailable.
• JMS servers are only used to host application specific JMS destinations, SOA/OSB JMS destinations remain in relevant SOA/OSB managed servers.
• Separate Coherence servers allow OSB cache to be offloaded from OSB servers.
• Use of Coherence by other components as a shared infrastructure data grid service
• Coherence cluster may be managed by WLS but more likely run as a standalone Coherence cluster.
• Shared SOA Domain hosts
• Human Workflow Tasks
• BAM
• Common "utility" composites
• Single OSB domain provides "Enterprise Service Bus"
• All domains use same OWSM policy store (MDS-WSM)

Benefits

• Follows EDG but in separate domains and with addition of application specific JMS servers and standalone Coherence servers for OSB caching and application specific caches.
• Coherence grid can be scaled independent of OSB/SOA.
• JMS queues provide for inter-application communication.
• Patch lifecycle of OSB/SOA/JMS are no longer lock stepped.
• JMS may be kept running independently of other domains allowing applications to insert messages fro later consumption by SOA/OSB.
• OSB may be kept running independent of other domains, allowing service virtualization to continue independent of other domains availability.
• All domains use same OWSM policy store (MDS-WSM).
• Supports large numbers of deployed composites in multiple domains.
• Single URL for Human Workflow end users.
• Single URL for BAM end users.

Drawbacks

• Multiple domains to manage and configure.
• Multiple Admin servers (single view requires use of Grid Control)
• Multiple Admin servers/WSM clusters waste resources.
• Additional homes needed to enjoy benefits of separate patching.
• Cross domain trust needs setting up to simplify cross domain interactions.
• Human Workflow needs to be specially configured to point to shared services domain.

Summary

The alternatives in this blog allow for patching to have different impacts, depending on the model chosen.  Each organization must decide the tradeoffs for itself.  One extreme is to go for the shared services model and have one domain per SOA application.  This requires a lot of administration of the multiple domains.  The other extreme is to have a single super domain.  This makes the entire enterprise susceptible to an outage at the same time due to patching or other domain level changes.  Hopefully this blog will help your organization choose the right model for you.