Monday Apr 27, 2015

Comparison of inplace and side by side upgrade

This article compares in-place upgrade with side by side upgrade to SOA 12c.What are the advantages and disadvantages? What are the prerequisites?

In in-place upgrade you install SOA 12c in a new oracle home and upgrade the domain and DB in-place. This is what is documented in the upgrade guide. In side by side upgrade, you install SOA 12c in a new oracle home and create a new SOA 12c domain and DB. You then deploy all the composites and configure the 12c domain fully. You then cut over from 11g to 12c.

Side by Side upgrade does not apply if you have long running instances and you cannot guarantee that all inbound messages have been drained and there are no active instances when you cut over to 12c. Even if this is not true, you could still keep the 11g system up (with no new messages) until all messages are drained and all active instances complete. We will briefly cover this option at the end but ignore it for the rest of the article. 

 The advantages of in-place upgrade over side by side are the following.

  • You do not have to take the effort of configuring a new enterprise deployment which could take a long time. You do not have to replicate the SOA configuration after the upgrade. You do not have to configure your custom adapters, adapter configurations, JMS queues/topics, datasources, non SOA J2EE Apps, etc. All the configurations and deployments carries over. In side by side, all this configurations have to be done from scratch. It is basically a new deployment done by following the install guide or EDG.
  • Long running instances continue after upgrade where they left off. As mentioned in side by side, long running instances do not move over to the new deployment.
  • You retain the history of completed instances after upgrade. In side by side, the history of completed instances do not over over to the new deployment.
  • You don't need new licenses. You should check with Oracle if new licenses are needed if you don't put the 12c domain on the same CPUs as the 11g domain in a side by side upgrade. if your 11g production system does not have a lot of spare capacity to colocate the 12c deployment, you will probably have to buy new hardware for the 12c deployment.
  • All inbound addresses are the same so clients don't need to be modified. This includes JMS queues/topics, file directories, etc. For side by side, inbound HTTP traffic can be redirected without impacting clients by switching at the load balancer, but others may require changes to the clients.

The disadvantages of in-place upgrade over side by side upgrade are the following.

  • There are limitations and prerequisites documented in the upgrade guide for in-place upgrade. For example the starting version must be 11.1.1.6 or 11.1.1.7. If you are not meeting these requirements, you have to fix it (for example upgrade to 11.1.1.7 first) before you start the 12c upgrade or not do the in-place upgrade since it is not supported with your current configuration (for example you created your production system with T2P before 11.1.1.6).  For side by side, you can create the 12c domain and migrate your composites without this problem. If you are migrating from a version before 11.1.1.6, first migrate your jdeveloper projects to 11.1.1.7 then migrate the jdeveloper  projects to 12c. 
  • The down time during upgrade could be quite long. You need to shut down your 11g production system, take a complete backup, perform the upgrade, and then test and tune your upgraded domain, before making it live. Cutting over to 12c for side by side could be fast with minimum down time since everything in 12c has been tested and tuned while the 11g system was live.
  • If you have BAM in your domain, BAM does not support in-place upgrade and you have a much more complex in-place upgrade path. In side by side, creating a new 12c domain with SOA and BAM is straight forward.
  • Doing an in-place upgrade is a very demanding requirement and Oracle has tested it thoroughly to provide a smooth experience. However there is a possibility that your particular special deployment encounters issues. This may cause delays in your testing of in-place upgrade. Issues are much less likely if you create a new domain as in side by side.
  • The focus of in-place upgrade is backwards compatibility and a silent automatic upgrade. Sometimes this means new 12c features may be disabled after upgrade and you may have to enable these gradually some time after going live on 12c. . For example the key store technology has changed from JKS to KSS. However after upgrade you are still left with JKS since it is not possible to auto migrate to KSS. Another example is the XML XDK is configured for backwards compatibility after upgrade disabling new features. This is not a problem with side by side. With side by side, you have plenty of time to modify your composites if you want to, to take advantage of new features.
  • Rolling back the upgrade if you encounter problems during or after upgrade requires you to restore from full backup. With side by side, you would have had plenty of time to thoroughly test so it is very unlikely you have to go back to 11g.

If you continue running the 11g system after the 12c system goes live then things like Human Workflow approvals and EM management have to be done in two places, and clients sending messages to a running process may not work.



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
« May 2015
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
29
30
31
      
Today