Thursday Dec 18, 2014

SOA Suite 12c: Topology Suggestions

In this article, I make some suggestions and provide opinions on topologies for SOA Suite 12c that is commonly used and supported. Only the EDG topology is thoroughly tested by Oracle though.

  • One consideration when deciding on topologies is that Upgrade is always domain wide. All products deployed to the domain must release in the same release train and you should be willing to upgrade all of them at the same time.
  • Centralized administration is one factor but should not be the only reason to put two different products in the same domain. EM Cloud Control could be used as a solution for that. 
  • Typically Service Bus and SOA Suite belong in different tiers in an end to end architecture so they would be in separate domains. This is true if Service Bus is being used on an enterprise scale routing to multiple SOA domains and other services. However if Service Bus is used primarily for mediating and providing routing for SOA Suite Composites in a domain, it would be in the same domain, but typically in separate clusters for optimum performance and scalability. However it  is possible starting in 12c to have Service Bus and SOA Suite in the same cluster.  The only possible reason for this is reducing memory and is uncommon.
  • Governance products like OER and UDDI should not be in a SOA Suite or Service Bus domain. They should be in a separate domain. OER should be in a separate domain from UDDI. UDDI is a third party product and putting it in the same domain may cause upgrade issues.
  • You can target multiple products to the same cluster by targeting the appropriate user extensible server group to  the servers in the cluster.
    1. SOA Suite is targeted to a server by targeting either the user extensible server group SOA-MGD-SVRS or SOA-MGD-SVRS-ONLY.
    2. Service Bus is targeted to a server by targeting either the user extensible server group OSB-MGD-SVRS-COMBINED or OSB-MGD-SVRS-ONLY.
    3. BAM is targeted to a server by targeting either the user extensible server group BAM12-MGD-SVRS or BAM12-MGD-SVRS-ONLY.
    4. MFT is targeted to a server by targeting either the user extensible server group MFT-MGD-SVRS or MFT-MGD-SVRS-ONLY.
    5. ESS is targeted to a server by targeting the user extensible server group ESS-MGD-SVRS. .
  •  BAM sometimes is used outside of SOA Suite and in this case it is typically in a separate domain from SOA Suite. However BAM should be in a separate cluster in the same domain as SOA Suite if it is primarily used with that SOA Suite instance. In BAM 12c, integration between SOA Suite and BAM is a tight integration and is best done in the same domain. BAM and SOA Suite should not be co-located in the same cluster because BAM uses Automatic Service Migration for HA while SOA Suite uses Whole Server Migration. 
  • OWSM Policy Manager must be deployed to only one cluster in a domain. However SOA Suite, OSB, BAM and MFT templates target OWSM PM by default to their own clusters.
    1.  In a domain with such different clusters, put OWSM PM in its own cluster like the EDG suggests. You can target the JRF and the two OWSM PM related user extensible server groups to this cluster.
    2. OWSM PM is automatically targeted to the SOA cluster when you target the user extensible server group SOA-MGD-SVRS which is the default. However if OWSM PM  is already targeted to a separate cluster then you should target SOA Suite to the SOA cluster by targeting the user extensible server group SOA-MGD-SVRS-ONLY.

    3. OWSM PM is automatically targeted to the BAM cluster when you target the user extensible server group BAM12-MGD-SVRS which is the default. However if OWSM PM  is already targeted to a separate cluster then you should target BAM to the BAM cluster by targeting the user extensible server group BAM12-MGD-SVRS-ONLY.

    4. OWSM PM is automatically targeted to the Service Bus cluster when you target the user extensible server group OSB-MGD-SVRS-COMBINED which is the default. However if OWSM PM  is already targeted to a separate cluster then you should target Service Bus to the Service Bus cluster by targeting the user extensible server group OSB-MGD-SVRS-ONLY.

    5. OWSM PM is automatically targeted to the MFT cluster when you target the user extensible server group MFT-MGD-SVRS which is the default. However if OWSM PM  is already targeted to a separate cluster then you should target MFT to the MFT cluster by targeting the user extensible server group MFT-MGD-SVRS-ONLY.
    6. ESS requires that OWSM PM be present somewhere in the domain but itself does not target OWSM PM.
  • Follow the following guidelines for ESS targeting.
    1. In a domain with Service Bus only ESS is typically targeted to the Service Bus cluster.
    2. In a domain with SOA Suite only, ESS is typically targeted to the SOA Suite cluster.
    3. However in a domain with both SOA Suite and Service Bus in different clusters, the best practice is to target ESS to its own cluster. 
    4. MFT always has a private copy of ESS deployed to its cluster independent of any additional deployment of ESS for use by SOA Suite and Service Bus.
    5. ESS currently is positioned not as a standalone scheduler, but a scheduler for SOA Suite and Service Bus and should be in the same domain.
  • MFT is typically in a separate domain from SOA Suite or Service Bus, but could be in the same domain but in a separate cluster.
  • The best practice is to use separate domains for Healthcare and B2B and separate domains for SOA Suite and B2B. This is documented in the B2B and Healthcare documentation.

Saturday Jan 26, 2013

Making Enterprises More Human: Removing the Complexity in Event Processing


Human beings have a very unique differentiation compared to all other living creatures. It is the power to discriminate, giving them freedom of choice. This is possible because humans minds are sophisticated and high performing event processing engines, constantly optimizing for survival and gain, while functioning in extremely complex scenarios.

Man creates an optimal environment for himself to thrive, by filtering and correlating a high volume of events from very disparate sources, across time and boundaries. In fact all types of events are incorporated as feedback through all senses, constantly gauging, judging, filtering and correlating events. For example consider what you do every morning: turn on the news for traffic re-routing to gauge if you will make it on time to a meeting, sanity-check your gas tank to know far you can go, stop to grab a bite when you see a coffee drive-through. And all this while driving, which in itself requires processing events arriving from other automobiles on the road, traffic conditions and regulations. Humans are designed to continuously filter, correlate and process events in real-time.

The one technology that is so unique in adding this human quality of discrimination to inanimate software and hardware systems, is referred to commonly as "Complex Event Processing". To the uninitiated, the term "Complex" can sound like the technology is difficult, when really it inidicates that the event processing can happen in very complex scenarios, much like humans. In fact, a good event processing solution would remove the complexity and interpret accurate meaning in seemingly unconnected events.

Event processing can add the power of discrimination, providing intelligence and a dynamic responsiveness to everything it pairs with. Added to Business Process Management (BPM), Event Processing can make business processes very responsive and dynamic, even capable of handling unexpected exceptions. Added to Service Oriented Architecture (SOA), Event Processing can be a powerful ally in building a responsive IT infrastructure. Added to data integration, Event Processing can provide the capacity to discriminate against streams and volume of different kinds of data. The possibilities on what technologies Event Processing can be paired with are really limitless. When you want to think dynamic and add an edge to any technology solution, you want a good event processing engine added to your solution. 

Oracle Event Processing (OEP) is exactly this power of discrimination that can be added to any solution to result in extremely intelligent systems that respond in real-time. Keep your eyes peeled to hear about our new initiatives with OEP across our fusion middleware product lines in our upcoming release.
About

Find Us on facebook Follow us on twitter Oracle SOA Suite forum
SOA PM team
Welcome to the Oracle SOA Suite team blog. We'll use this site for news and information that did not make it into our official documentation for a reason or another.

Search

Archives
« March 2015
SunMonTueWedThuFriSat
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
    
       
Today