企业级应用程序是一个组织内部的日常事务和业务流程的信息系统。这些应用程序需要处理大量的数据，同时还需要具备高可用性、可扩展性和可靠性等特性。为了更好地运用这些应用程序，Oracle数据库的12c版本提供了SOA（面向服务的架构）容器数据库，它使得应用开发人员更容易的创建和管理自己的应用程序。
SOA容器数据库是一个标准的数据库实例，它是为了支持SOA部署应用程序而设计的。一个SOA容器数据库可以包含多个SOA服务器，每个服务器都包含了一个或多个应用程序。SOA容器数据库提供了许多功能，如负载均衡、自动故障转移、自动扩展和自动升级等，这些功能使得应用程序更具有可靠性和可扩展性，同时降低了维护和管理的成本。
为了创建一个SOA容器数据库，我们需要按照以下步骤：
之一步：创建一个空的数据库实例
在创建SOA容器数据库之前，我们需要先创建一个空的数据库实例。在安装Oracle 12c数据库时，将选择“创建一个新的数据库”选项。在创建过程中，用户需要指定实例名称、数据库类型、数据库字符集等参数。此外，用户还需要配置数据库的系统表空间、数据表空间和日志文件，以及设置管理员账户和密码等。
第二步：安装Oracle SOA Suite
安装Oracle SOA Suite是创建SOA容器数据库的第二个步骤。Oracle SOA Suite是一个完整的SOA架构解决方案，它提供了许多与SOA相关的工具和应用程序，如BPEL（业务流程执行语言）、ESB（企业服务总线）、ODI（数据集成）等等。SOA Suite的安装过程非常简单，用户只需要按照提示进行安装即可。
第三步：创建SOA容器数据库
创建SOA容器数据库是创建SOA应用程序的最后一步。在创建SOA容器数据库过程中，我们需要指定数据库实例名称、端口、用户名和密码等信息。此外，用户还需要配置JDBC数据源和SOA服务器等信息，以便将应用程序部署到SOA容器数据库中。
通过创建SOA容器数据库，我们可以更好地运用企业级应用程序。SOA容器数据库提供了许多强大的功能，使得应用程序更具有可靠性和可扩展性，同时降低了维护和管理的成本。尽管创建SOA容器数据库的过程较为繁琐，但是它将为企业级应用程序的开发和管理提供有力的支持和保障。
相关问题拓展阅读：
- SOA（面向服务架构）的有关知识
- 如何选择云计算管理平台
SOA（面向服务架构）的有关知识
面向服务的体系结构（Service-Oriented Architecture，SOA） 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定镇巧义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。
推荐阅读：
《基于服务的建模和架构——如何为你的 SOA 鉴别、指定和实御樱键现服务 》
作者 Ali Arsanjani, Ph.D. (), 首席架构师颂困, SOA and Web services Center of Excellence, IBM
原文地址：
SOA
面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。
这种具有中立的接口定义（没有强制绑定到特定的实现上丛裂逗）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。
对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙渗卖伴关系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务源桐为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。
虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。
然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。
Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。
此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。
最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。
我可以用面向服务的体系结构做什么？
对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。
下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。
另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店（store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。
为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。
垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从更底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。
正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用。NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。
SOA有以下特性
SOA服务具有平立的自我描述XML文档。Web服务描述语言（WSDL， Web Services Description Language）是用于描述服务的标准语言。
SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD， XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成（UDDI， Universal Description， Definition， and Integration）是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS， quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。
为什么选择SOA？
不同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务， 从而保护了现有的IT基础建设投资。
如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。
服务架构
为了实现SOA，企业需要一个服务架构，图2显示了一个例子：
在图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
SOA基础结构
要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。
SOAP， WSDL， UDDI
WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。
WS-I Basic Profile
WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。
J2EE 和 .Net
尽管J2EE和。NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如。NET）的服务互用。
服务品质
在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，系统对于一个促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将会讨论一些QoS服务和相关标准。
安全
Web服务安全规范用来保证消息的安全性。该规范主要包括认证交换， 消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。
可靠
在典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。
策略
服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。
控制
当企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。
管理
随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。
其它的qos特性，比如合作方之间的沟通和通讯，多个服务之间的事务处理，都在WS-Coordination 和 WS-Transaction 标准中描述， 这些都是OASIS 的工作。
SOA 不是Web服务
在理解SOA和Web服务的关系上，经常发生混淆。根据2023年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。
SOA的优势
SOA的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的影响；SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。
如何选择云计算管理平台
这个首先要看使用云管理平台的目标，有的是为了做云平台的运维管理，有的是为了做行业云的运营管理，有的是为了跨云做资源调度管坦消理。目前市场上大部分项目需求是做云平台的同意运维和费用管理。选择应该考虑几个维度：通用的功能，非功能指标，资质，特有的需求-如：运营管理，云迁移等。通用的功能应让行知考虑：云服务目录的管理功能（上架，下架），多云的调度对接（阿里云，华为云，Openstack，Vwmare等主流的公有云，私有云的兼容、纳带茄管），多云资源池之间的网络互联互通管理，云上资源的集中监控，统一告警，云资源的生命周期管理ADCI（申请，开通，变更,删除，查询），云费用和账单管理，预算管理，云成本优化。 非功能层面：作为管理平台，一般情况下没有大规模的访问压力，以系统的可靠性和安全性为主。资质可以考虑可信云.多云管理的资质认证。
国内的云计算管理平台厂商：云星数据，fit2cloud，骞云等都可以考虑。
随着云计算在企业的盛行，人们多数感受到云计算使信息系统资源实现了资源的随需分配的灵活性、可伸缩性及提高了服务器的利用率等。云计算架构在企业的引入，更能有效实现企业信息系统的技术标准化和管理规范化，为企业信息系统提供更好的支持。因为随着企业信息化程度越来越高、信息系统支持的业务越来越复杂，以往各自为政、缺乏统一的管理导致的管理成本高昂、人员需求众多且资源浪费严重的弊端无疑是个瓶颈，特别对大型信息系统的运营更是桎梏。如果将在云计算体系架构中的软硬件资源比做人的骨骼肌体的话，那么包括虚拟化、网格计算、效用计算等技术可以视作将这些资源串接起来的血脉筋络，而要使这些资源和技术真正发挥作用、对外提供优质服务，则还需要云计算架构中的“大脑”——云管理平台。云管理平台最重要的两个特质在于管理云资源和提供云服务。即通过构建基础架构资源池（IaaS）、搭建企业级应用/开发/数据平台（PaaS），以及通过SOA架构整合服务（SaaS）来实现全服务周期的一站式服务，构建多层级、全方位的云资源管理体系。云管理平台功能架构在IaaS云中，云管理平台需要在虚拟化、网格计算、效用计算、分布式等技术的支撑下，对包括计算资源、存储资源、网络资源等在内的基础架构通过API接口进行管理，实现按需的、可计量的对基础架构资源进行分配，同时，实现对资源使用情况和健康情况的监控以及对事件的捕获和处理。在PaaS云中，云管理平台应该可以通过抽象管理来将用户需求翻译成平台相关属性需求，通过平台管理和接口API编程来实现针对平台需求的资源切割和快速部署，并同样需要在此过程中姿衫实现平台资源的计量、监渣昌控，以及事件的捕获和处理。在SaaS云层面中，云管理平台也需对实际业务需求进行抽象处理，形成应用服务管理的通用架构。要构建这样的通用架构中，还需云管理平台实现基于SOA服务的注册、注销、配置、流程设计、调度以及服务的部署迹梁腔等管理功能，同时在此过程中还需对服务质量和性能进行监控，并以此为依据进行服务级别（SLA）和服务计量的管理。此外，云管理平台还需要面向用户和面向管理的统一门户来改善管理效率和提高用户体验。同时，在云管理平台的设计中，应考虑使用面向整个云管理平台的数据库，使所有的管理操作、用户使用情况、性能、事件等可回溯，同时可以此为基础进行数据分析、行为分析和决策支持，以提高整个云体系架构的服务水平和资源利用率。主流云平台管理比较当前业界主流的云平台管理软件包括OpenStack和CloudStack等，凭借其开源所带来的活力以及各主流芯片厂商和虚拟软件厂商的支持，迅速地在云计算领域占据领先地位，包括英国电信、塔塔集团、韩国电信等在内的大型企业都是其用户。但是，作为云管理平台解决方案，其面向的领域和提供的服务仍需进一步扩充和完善。主要体现在如下三方面：其一，无论是OpenStack还是CloudStack，他们关注的领域是基础设架构云，即IaaS云，对于PaaS云和SaaS云，这两种产品当前并未提供成熟的解决方案。而正如上节所述，一个完善的云管理平台应该是对包含IaaS、PaaS和SaaS在内的全方位、全流程、全生命周期的管理平台。其二，OpenStack和CloudStack对基于x86的硬件架构及相关虚拟化软件实现IaaS云有良好的解决方案和众多成功案例，但对于以非x86芯片为基础的小型机尚无法有效在虚拟化、资源调度等方面进行管理。在此，必须说明的是在业界往往把云计算和x86画等号，认为x86化是云计算的基础和必要条件。诚然，x86架构以其标准化、开放平台以及较高的性价比在云计算实现资源的统一管理、调度方面有着天然的优势。但这并不意味着小型机平台不能进行云计算，相反，作为云计算的核心支撑技术的虚拟化技术，在以Power芯片和SPARC芯片为代表的非x86架构上更早得到实现并得到了广泛的应用。更需要强调的是，其虚拟化的实现往往是基于固件的，效率远高于各种基于操作系统的虚拟化软件。小型机以其单独物理节点的高性能、高RAS特性、高虚拟化效率等仍在关键业务领域占据重要地位，在进行IaaS云建设中，尤其是针对大型企业关键应用的私有云中，云管理平台的核心工作往往是非x86架构的小型机的云计算化。其三、无论是OpenStack的Nova、Glance还是CloudStack Orchestration Engine，对于计算资源和存储资源的管理核心是通过虚拟化来屏蔽底层硬件的异构。这有利于创建通用的硬件架构资源池，但是，在屏蔽底层硬件异构的同时，同样屏蔽了各种硬件的独有功能和特性。对于上述问题，究其根本原因还是因为各厂商的软硬件产品并未遵循统一的标准，而是有各自独立的体系。对于标准不统一、接口不开放的系统，想要做到资源的统一调度、各自特性的完全体现无异于缘木求鱼。但是各厂商对自身产品是完全支持和开放的，因此也形成了面向自身产品的云计算解决方案。目前，包括IBM和ORACLE公司在内，都推出了各自的云计算管理平台。它们共有的特点是其产品全线覆盖从底层硬件到上层应用。因此，其云计算解决方案也全线支持从IaaS到PaaS乃至SaaS。IBM公司的云计算解决方案是所谓的SmartCloud Foundation,其中包括SmartCloud Entry（SCE）解决方案、IBM SmartCloud Provisioning（SCP）软件，以及IBM SmartCloud Monitoring。以用于搭建私有云的解决方案SCE为例，在SCE架构中，PowerVM技术是Power系列小型机虚拟化的基础，提供共享处理器、微分区、活动内存共享和虚拟I/O共享等虚拟化特性，同时在SCE架构中，支持包括VMWare、Xen、KVM等基于x86架构的虚拟化；System Director及其插件VMControl以底层PowerVM等虚拟化技术为基础实现系统池整合管理、自动化虚拟镜象迁移、优化虚拟化环境的性能、可靠性和能源管理等功能，除服务器外，还可以通过TPC和SVC实现存储虚拟化整合功能；在此之上，SEC提供SKC Core Framework平台，以此平台为基础部署监控、资源分配、用户管理、安全管理、模版管理、计量计费等多种功能插件，实现自服务门户（SelfService Portal），形成一套完整的、基于Power芯片和x86芯片的IaaS云解决方案。在此基础上，通过SCP和SCM，可以更进一步整合IBM的数据库产品和中间产品，形成PaaS云和SaaS云的解决方案。ORACLE公司的云计算解决方案统一在产品Enterprise Manager（EM）中实现，尤其是在EM 12c版本中，从IaaS、PaaS到SaaS，都提供了对于云计算架构良好的支持。如前文所述，ORACLE和IBM的产品从硬件到软件乃至解决方案全线覆盖，这是其可以实现PaaS和SaaS云的重要基础。
ZKEYS公有漏昌云管理系统是一个可以管理计算、网络、存储在内的各项资源，有云服务器、虚拟主机、裸金属服务等热门云业务，并且集成了财拍搜租务、工单、袭兆备案、会员、业务等多种板块的智能化系统，可以管理IDC企业所需的各个业务流程，节省成本，提高效益。
云管理平台最重要的两个特质在于管理云资源和提供隐冲隐云服务。即通过构建基础架判链构资源池（IaaS）、搭建企业级应用/开发/数据平台（PaaS），以及通过SOA架构整合服务（SaaS）来实现全服务周期的一站式服务，构建多层级、全方位的云资源管理体系。
选择云计算管理平台的四种考量:
1. 是否可以保障系统的灶厅稳定性、可靠性和安全性。这是IT决策者在选择云管理平台时最重要的衡量标准之一。
2. 是否可以和现在的虚拟化平台兼容。采用现有的虚拟化供应商升级云计算，不失为一种选择，但是考虑到成本以及供应商锁定的问题，也可以选择一种可以兼容现有虚拟化基础的云计算管理平台。
3. 是否有完整的生命周期管理。现在虚拟机泛滥的问题很普通，导致IT管理者不清楚哪些应用在哪些虚拟机上、无法及时回收资源等等问题，多数应用不能按照不同需求定义虚拟机的服务等级。
4. 是否便于管理。云计算的一个重要的优势是减少IT管理成本。
通过实际测试选型，光看宣传不好选。我们家测下了用的ZStack
关于12c创建soa容器数据库的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。
