以下是对通过该考试合格人员能力的结构化说明，帮助清晰理解其岗位胜任力与职业定位_processing deployment springautodeployment-CSDN博客

本文链接：https://blog.csdn.net/blog_programb/article/details/106152799

本文详细介绍了SpringSource应用平台的部署和打包选项，包括原生OSGi包、Java EE WAR、Web模块、平台归档(PAR)等格式。文章还探讨了从标准WAR到Web模块的迁移路径，以及PAR格式如何提供应用范围内的模块隔离。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

以下是对通过该考试合格人员能力的结构化说明，帮助清晰理解其岗位胜任力与职业定位：

一、核心工作能力

1. 信息系统运行管理与操作

在指导下完成系统运维：能在信息系统管理工程师的指导下，安全、熟练地进行信息系统的日常运行管理，确保系统稳定运行。
设备安装与配置：掌握相关硬件设备（如服务器、网络设备等）的安装、调试及基础配置技能，熟悉标准操作流程。
信息处理与文档记录：
- 熟练使用办公软件及专业工具进行数据录入、整理、分析等信息处理操作。
- 规范记录信息系统运行日志、操作流程及状态变更等文档，确保文档完整、准确。

2. 异常识别与基础故障处理

异常情况描述与受理：能准确观察并描述系统运行中的异常现象（如性能下降、报错信息等），具备问题受理能力，可初步判断问题类型并及时反馈给上级。
常见故障排除：掌握信息系统运行中常见问题（如网络连接中断、软件运行错误、硬件指示灯异常等）的排查方法，能独立处理简单故障，如重启设备、配置参数检查、基础软件修复等。

二、职业定位与资质

1. 职称与能力对标

具备**助理工程师（或技术员）**的实际工作能力和业务水平，符合初级技术人员的职业标准。
可作为信息系统管理团队的基础执行角色，承担一线运维、操作及辅助支持工作。

2. 典型工作场景

企业IT部门：负责终端设备维护、用户权限管理、数据备份等基础运维任务。
政府或事业单位：参与信息系统日常操作、数据处理及简单故障响应，保障业务系统正常运转。
技术服务公司：在项目中协助工程师完成系统部署、调试及用户培训，提供现场技术支持。

三、延伸价值与发展路径

职业进阶基础：通过实践积累经验后，可进一步考取信息系统管理工程师等中级职称，向系统规划、高级运维或管理岗位发展。
技能拓展方向：
- 学习云计算、网络安全、数据库管理等进阶技术，提升综合能力。
- 培养沟通协调与项目协作能力，为参与复杂系统运维或团队管理奠定基础。

通过该考试的人员是信息系统运维体系中的基础力量，其能力聚焦于标准化操作、基础故障处理及文档管理，可有效保障系统的日常稳定运行，同时为自身职业发展提供了从技术执行向技术管理过渡的起点。
这段文字描述的是一类专业考试合格人员应具备的能力和素质，主要涉及信息系统运行管理、设备安装配置、信息处理操作、文档记录、问题受理与故障排除等方面。以下是对其内容的详细解读：

信息系统运行管理能力

在指导下开展工作：合格人员需要在信息系统管理工程师的指导下开展工作，这说明他们处于一个学习和积累经验的阶段，尚未具备完全独立承担复杂信息系统管理任务的能力，但需要能够理解并执行上级工程师的指令和计划。
熟练且安全地操作：强调“熟练地、安全地”进行信息系统运行管理，这表明合格人员不仅要掌握相关操作技能，还要确保操作过程符合安全规范，避免因操作失误导致信息安全问题或系统故障。

设备安装与配置能力

安装和配置相关设备：这是信息系统运行管理的重要环节。合格人员需要能够正确安装各类硬件设备（如服务器、网络设备、终端设备等），并根据系统需求进行合理的配置，使其能够正常运行并与其他设备协同工作。例如，安装一台新的服务器时，需要正确安装操作系统、配置网络参数、设置存储资源等，以确保服务器能够为信息系统提供稳定可靠的支持。

信息处理操作能力

熟练进行信息处理操作：信息处理是信息系统的核心功能之一，合格人员需要能够熟练地对各类信息进行收集、存储、处理、传输和分析等操作。例如，在企业资源规划（ERP）系统中，他们需要能够准确录入和处理订单数据、库存数据、财务数据等，确保信息的准确性和完整性；在数据分析系统中，能够运用数据分析工具对海量数据进行筛选、统计和分析，为企业的决策提供数据支持。

运行文档记录能力

记录信息系统运行文档：文档记录是信息系统管理的重要环节，合格人员需要能够详细、准确地记录系统运行过程中的各种信息，包括系统配置信息、操作日志、故障记录、维护记录等。这些文档不仅有助于系统管理人员对系统的运行状态进行监控和分析，还可以为后续的系统升级、优化和故障排查提供重要依据。例如，当系统出现故障时，通过查看操作日志可以快速定位问题发生的时间点和可能的操作原因。

问题受理与故障排除能力

正确描述异常情况：在信息系统运行过程中，可能会出现各种异常情况，如系统性能下降、数据丢失、网络连接中断等。合格人员需要能够准确地观察和描述这些异常情况，包括出现的时间、现象、可能的影响范围等。例如，当发现系统响应速度变慢时，能够详细记录是在什么时间、什么操作下出现的，是否伴随其他异常现象（如错误提示、网络丢包等）。
具备问题受理和故障排除能力：他们需要能够对用户反馈的问题进行受理，并根据问题的性质和严重程度进行初步判断和处理。对于一些常见的问题，如简单的软件故障、网络配置错误等，能够独立进行故障排除，恢复系统的正常运行。例如，当用户报告无法访问某个网络资源时，能够检查网络连接、防火墙设置等，快速定位并解决问题。
处理常见问题：强调其能够处理信息系统运行中出现的常见问题，这说明合格人员需要具备一定的实践经验和技术积累，能够应对日常工作中频繁出现的问题。例如，对于操作系统常见的蓝屏故障、数据库连接失败等问题，能够运用所学知识和经验进行快速排查和修复，减少系统停机时间，保障信息系统的稳定运行。

专业能力水平

具有助理工程师（或技术员）的实际工作能力和业务水平：这是对合格人员综合能力的总体要求，表明他们已经具备了一定的专业知识和实践技能，能够胜任信息系统运行管理相关的基础工作，并在实际工作中不断积累经验，逐步提升自己的技术水平和综合素质，向更高级别的专业技术人员发展。

总体来看，通过本考试的合格人员在信息系统运行管理领域具备较为全面的基础能力，能够满足企业或组织对信息系统日常运行维护的基本需求，并在经验积累和持续学习的过程中不断提升自己的专业水平。

SpringSource Application Platform Deployment Options 解析

一、SpringSource Application Platform 概述

SpringSource Application Platform（通常简称为 Spring 应用平台）是基于 Spring 框架构建的企业级应用开发和部署平台，旨在简化企业级应用的开发、部署和管理。其核心目标是提供标准化的开发模型、自动化的部署流程以及高效的运行时管理，适用于构建微服务架构、云原生应用等场景。

二、核心部署选项解析

SpringSource 应用平台支持多种部署方式，可根据企业的基础设施环境、应用架构需求和运维策略进行选择。以下是常见的部署选项及其特点：

（一）本地服务器部署（On-Premises）

1. 部署方式

物理服务器：将应用直接部署在企业自有数据中心的物理服务器上，通过本地网络访问。
虚拟服务器（VM）：基于虚拟化技术（如 VMware、KVM）创建虚拟机，在虚拟机中部署应用。

2. 适用场景

对数据安全性和可控性要求极高的企业（如金融、政府机构）。
网络环境复杂、无法直接访问公有云的场景。

3. 优势

完全可控：资源完全归企业所有，可自定义配置和安全策略。
低延迟：本地网络访问，适合对实时性要求高的应用。
合规性：满足特定行业的数据合规要求（如 GDPR、等保合规）。

4. 挑战

高成本：需自行采购、维护硬件设备，初期投入和运维成本高。
扩展性受限：硬件资源扩容需物理升级，灵活性较低。

（二）公有云部署（Public Cloud）

1. 支持的云服务商

主流云平台：AWS（Amazon Web Services）、Azure（微软云）、Google Cloud Platform（GCP）、阿里云、腾讯云等。
部署模式：
- IaaS（基础设施即服务）：在云服务商提供的虚拟机或容器实例中部署应用（如 AWS EC2、Azure VM）。
- PaaS（平台即服务）：通过云平台的 PaaS 服务（如 AWS Elastic Beanstalk、Azure Spring Apps）一键部署，平台自动管理底层基础设施。
- 容器服务（CaaS）：基于 Kubernetes 等容器编排工具，将应用打包为 Docker 容器后部署（如 AWS ECS/EKS、Google Kubernetes Engine）。

2. 适用场景

中小型企业、初创公司，或需要快速上线、弹性扩展的应用。
微服务架构、云原生应用的开发和测试环境。

3. 优势

弹性扩展：按需申请资源，自动应对流量高峰（如通过 Auto Scaling 自动增减实例）。
高可用性：云平台提供多区域容灾、负载均衡等服务，提升应用可靠性。
低成本：按需付费，无需前期硬件投入。
快速部署：利用云平台的 CI/CD 工具链（如 GitHub Actions、Jenkins）实现自动化部署。

4. 挑战

数据安全风险：数据存储在公有云，需依赖云服务商的安全措施。
网络延迟：跨区域访问可能导致延迟，需搭配 CDN 等优化手段。
供应商锁定：不同云平台的服务接口和工具链存在差异，迁移成本较高。

（三）私有云部署（Private Cloud）

1. 部署方式

基于 OpenStack、VMware vCloud 等私有云平台，在企业内部构建虚拟化资源池，实现类似公有云的自助服务和资源管理。

2. 适用场景

大型企业或对数据主权要求严格的行业（如医疗、电信），希望结合云的灵活性和本地控制能力。

3. 优势

安全可控：资源在企业内部隔离，符合数据合规要求。
灵活性高：可自定义云平台功能，适配企业现有架构。
混合云过渡：作为公有云与本地部署的中间方案，为未来混合云架构奠定基础。

4. 挑战

技术门槛高：需要专业团队搭建和维护私有云平台。
成本较高：硬件和软件 licenses 投入大，运维复杂度高于公有云。

（四）混合云部署（Hybrid Cloud）

1. 部署模式

将应用的不同组件或模块部署在公有云和本地/私有云环境中，通过网络实现数据和服务的互通。
典型场景：
- 前端服务部署在公有云（面向公网用户），数据库等敏感数据存储在本地数据中心。
- 开发测试环境使用公有云，生产环境使用私有云。

2. 适用场景

企业数字化转型过渡期，逐步迁移现有应用到云端，同时保留核心系统在本地。
需要平衡成本、性能和安全性的复杂业务场景。

3. 优势

灵活性与可控性结合：关键业务本地部署，非敏感业务上公有云，优化资源分配。
灾难恢复：通过混合云架构实现跨环境的数据备份和容灾切换。

4. 挑战

架构复杂度高：需解决跨环境的网络连通性、数据同步和服务调用问题。
管理难度大：需要统一的监控和运维工具链，协调不同环境的资源管理。

（五）容器化部署（Containerized Deployment）

1. 技术栈

容器化工具：Docker（打包应用及依赖）、Docker Compose（定义多容器应用）。
编排工具：Kubernetes（K8s）、Docker Swarm，实现容器的自动化部署、扩展和管理。

2. 适用场景

微服务架构的应用，需要快速迭代和弹性扩展。
跨环境一致性要求高的场景（如开发、测试、生产环境统一）。

3. 优势

环境一致性：容器封装应用及其依赖，避免“环境不一致”导致的问题。
高效资源利用：容器轻量级特性（相比虚拟机），提升服务器资源利用率。
DevOps 友好：与 CI/CD 流程深度集成，支持持续部署和滚动更新。

4. 挑战

学习成本高：需掌握 Kubernetes 等复杂编排工具的使用和运维。
监控与日志管理：多容器环境下需搭建集中式监控和日志系统（如 Prometheus、ELK Stack）。

（六）无服务器部署（Serverless）

1. 实现方式

FaaS（函数即服务）：通过云平台的 Serverless 服务（如 AWS Lambda、Azure Functions）运行应用逻辑，无需管理服务器。
BaaS（后端即服务）：集成云平台提供的数据库、存储、认证等后端服务（如 Firebase、AWS Amplify）。

2. 适用场景

事件驱动型应用（如消息队列处理、API 网关响应）。
轻量级应用或微服务中的独立功能模块（如数据清洗、文件处理）。

3. 优势

完全免运维：云平台自动管理服务器资源，开发人员只需关注代码逻辑。
按使用付费：仅按函数执行次数和资源消耗计费，成本极低。
高弹性：自动根据请求量扩展，无需手动配置 Auto Scaling。

4. 挑战

冷启动延迟：函数首次执行时可能存在启动延迟，影响实时性要求高的场景。
技术限制：不适用于需要长时间运行的进程或复杂状态管理的应用。
供应商锁定：依赖特定云平台的 Serverless 服务，迁移成本高。

三、部署选项对比表格

部署选项	成本	扩展性	安全性	运维复杂度	适用场景
本地服务器部署	高（初期投入）	低	高（可控）	高	敏感数据、合规性要求高的企业
公有云部署	低（按需付费）	高（弹性）	中（依赖云商）	中	快速迭代、弹性扩展的中小型应用
私有云部署	中高	中（自定义）	高	高	大型企业、数据主权要求高的场景
混合云部署	中	高（灵活）	高	极高	复杂业务架构、过渡期数字化转型
容器化部署	中	高（容器编排）	中	中高	微服务、云原生应用
无服务器部署	极低	极高	中	低	事件驱动、轻量级功能模块

四、选择部署选项的关键因素

业务需求：
- 应用类型（如 Web 应用、API 服务、大数据平台）和访问量规模。
- 是否需要全球化部署或多区域容灾。
技术架构：
- 单体应用或微服务架构，是否支持容器化改造。
- 依赖的中间件（如数据库、消息队列）是否支持目标部署环境。
合规与安全：
- 数据存储位置、传输加密、身份认证等合规要求。
- 企业是否需要自主管理安全策略（如防火墙、入侵检测）。
成本与运维：
- 预算限制（初期投入 vs 长期运维成本）。
- 团队技术能力（如是否熟悉 Kubernetes、云平台服务）。

五、趋势与建议

云原生优先：当前主流趋势是采用容器化（Docker + K8s）和公有云/混合云部署，尤其是微服务架构的应用。
分层部署策略：对敏感数据层（如数据库）采用本地或私有云部署，业务逻辑和前端层采用公有云，实现安全与效率的平衡。
自动化工具链：无论选择哪种部署方式，建议集成 CI/CD 工具（如 Jenkins、GitLab CI）和监控平台（如 Grafana、Prometheus），提升部署效率和可观测性。

通过综合评估企业需求和技术能力，选择合适的部署选项，可最大化 SpringSource 应用平台的优势，实现高效、可靠的应用交付和管理。
SpringSource Application Platform（SAP）提供了多种部署选项，以满足不同应用场景和需求。以下是对其主要部署选项的解析：

1. Raw OSGi Bundles（原始 OSGi 捆绑包）

特点：SAP 本质上是一个 OSGi 容器，因此任何符合 OSGi 规范的捆绑包都可以直接部署在平台上。
适用场景：适用于需要在 OSGi 容器中发布或消费服务的场景。

2. Java EE WAR（Java EE Web 应用程序归档）

标准 WAR：SAP 支持直接部署标准的 Java EE WAR 文件。在部署时，WAR 文件会被转换为 OSGi 捆绑包并安装到 Tomcat 中。这种方式允许用户无需修改现有的 WAR 文件即可在 SAP 上运行。
共享库 WAR：通过使用 OSGi 的 Import-Package 和 Require-Bundle 等标准清单头声明依赖关系，可以减少应用程序的部署大小，避免库膨胀。
共享服务 WAR：基于 Spring-DM 的强大功能，允许在 OSGi 捆绑包和 Web 应用程序之间共享服务。

3. Web Modules（Web 模块）

特点：Web 模块是一种专为 OSGi 兼容 Web 应用程序设计的部署格式，其结构类似于共享服务 WAR。它通过新的 OSGi 清单头（如 Web-DispatcherServletUrlPatterns 和 Web-FilterMappings）减少了 Spring MVC 基于应用程序的配置。
适用场景：适用于需要充分利用 OSGi 特性的 Spring MVC 基于 Web 应用程序。

4. Platform Archive (PAR)（平台归档）

特点：PAR 是一个标准的 JAR 文件，包含应用程序的所有模块（如服务、领域和基础设施捆绑包以及 Web 模块）。它允许将整个应用程序作为一个单一的部署单元进行部署、刷新和卸载。
优势：
- 简化部署：对于包含多个模块的企业级应用程序，PAR 格式大大简化了部署过程。
- 应用隔离：PAR 为应用程序提供了一个明确的范围，防止与其他应用程序发生冲突。
- 支持高级特性：PAR 支持诸如加载时织入等高级特性，确保一个应用程序的织入不会干扰另一个应用程序。
适用场景：推荐用于充分利用 SAP 和 OSGi 提供的所有功能的应用程序。

5. Plans（计划）

特点：计划是一种用于部署多个应用程序的高级部署选项。它允许开发者定义一组应用程序的部署顺序和依赖关系。
适用场景：适用于需要同时部署多个相关应用程序的复杂场景。

部署流程

当在 SAP 上部署应用程序时，每个部署工件（如单个捆绑包、WAR、PAR 或计划）都会通过一个部署管道。该管道支持特定于个性的部署程序，这些部署程序负责处理具有特定个性（即应用程序类型）的应用程序。
SpringSource Application Platform Deployment Options
Since we released the SpringSource Application Platform last Wednesday, numerous developers have downloaded the 1.0.0 beta and started taking the Platform for a test drive. As a result, people have begun asking, “How can I deploy my apps on the Platform, and what kind of deployment and packaging options do I have?” Moreover, developers are eagerly requesting to see working samples. In response, the S2AP team will be releasing several sample applications over the coming weeks demonstrating these features and more, but before you get your hands on these samples, I’d like to give you a high-level overview of the deployment and packaging options available in the Platform. After reading this post you’ll be ready to hit the ground running with the samples as well as with your own applications.
Overview

As Rob mentioned in his post last week, Introducing the SpringSource Application Platform, the Platform supports applications packaged in the following forms:

Raw OSGi Bundles
Java EE WAR
Web Modules
Platform Archive (PAR)

When you deploy an application to the Platform, each deployment artifact (e.g., a single bundle, WAR, or PAR) passes through a deployment pipeline. This deployment pipeline supports the notion of personality-specific deployers which are responsible for processing an application with a certain personality (i.e., application type). The 1.0.0 release of the Platform natively supports personality-specific deployers analogous to each of the aforementioned packaging options. Furthermore, the deployment pipeline can be extended with additional personality deployers, and future releases of the Platform will provide support for personalities such as Batch, Web Services, etc.

Let’s take a closer look now at each of the supported deployment and packaging options to explore which one is best suited for your applications.
Raw OSGi Bundles

At its core, the SpringSource Application Platform is an OSGi container. Thus any OSGi-compliant bundle can be deployed directly on the Platform unmodified. You’ll typically deploy an application as a single bundle or a set of stand-alone bundles if you’d like to publish or consume services globally within the container via the OSGi Service Registry. Please note, however, that due to the scoping nature of the PAR format, stand-alone bundles will not be able to consume services across application boundaries. In other words, a stand-alone bundle can not reference the services of modules deployed within a PAR.
WAR Deployment Options

For Web Application Archives (WAR), the SpringSource Application Platform provides support for the following three formats.

Standard Java EE WAR
Shared Libraries WAR
Shared Services WAR

Each of these formats plays a distinct role in the incremental migration path from a standard Java EE WAR to an OSGi-ified web application.
Standard WAR

As Rob has already pointed out, “Standard WAR files are supported directly in the Platform. At deployment time, the WAR file is transformed into an OSGi bundle and installed into Tomcat. All the standard WAR contracts are honoured, and your existing WAR files should just drop in and deploy without change.” Support for standard, unmodified WAR files allows you to try out the SpringSource Application Platform on your existing web applications and then gradually migrate toward the Shared Libraries WAR, Shared Services WAR, and Web Module formats.
Shared Libraries WAR

If you have experience with developing and packaging web applications using the standard WAR format, you’re certainly familiar with the pains of library bloat. So, unless you’re installing shared libraries in a common library folder for your Servlet container, you have to pack all JARs required by your web application in /WEB-INF/lib. Prior to the release of the Platform, such library bloat has essentially been the norm for web applications, but now there is a better solution! The Shared Libraries WAR format reduces your application’s deployment footprint and eradicates library bloat by allowing you to declare dependencies on libraries via standard OSGi manifest headers such as Import-Package and Require-Bundle. The Platform provides additional support for simplifying dependency management via the Import-Library and Import-Bundle manifest headers which are essentially macros that get expanded into OSGi-compliant Import-Package statements.

For detailed information on what kind of libraries you already have at your disposal, check out the SpringSource Enterprise Bundle Repository. In addition, Andy Wilkinson will be posting a blog later this week explaining how to make the most of the Bundle Repository within your applications and the SpringSource Application Platform. So stay tuned.
Shared Services WAR

Once you’ve begun taking advantage of declarative dependency management with a Shared Libraries WAR, you’ll likely find yourself wanting to take the next step toward reaping further benefits of an OSGi container: sharing services between your OSGi-compliant bundles and your web applications. By building on the power and simplicity of Spring-DM, the Shared Services WAR format puts the OSGi Service Registry at your fingertips. As a best practice you’ll typically publish services from your domain, service, and infrastructure bundles via <osgi:service … /> and then consume them in your web application’s ApplicationContext via <osgi:reference … />. Doing so promotes programming to interfaces and allows you to completely decouple your web-specific deployment artifacts from your domain model, service layer, etc., and that’s certainly a step in the right direction. Of the three supported WAR deployment formats, the Shared Services WAR is by far the most attractive in terms of modularity and reduced overall footprint of your web applications.
Web Modules

Above and beyond WAR-based deployment formats, the SpringSource Application Platform introduces a deployment and packaging option for OSGi-compliant web applications, the Web Module format. Web modules have a structure similar to a Shared Services WAR and can therefore take full advantage of all three WAR deployment formats. In addition, web modules benefit from reduced configuration for Spring MVC based applications via new OSGi manifest headers such as Web-DispatcherServletUrlPatterns and Web-FilterMappings. For further details on these and other Web-* manifest headers, please consult the Platform’s Programmer Guide. Upcoming releases of the Platform will also support web.xml fragments as well as the aforementioned manifest headers.

If you’re building a Spring MVC based web application as a web module, you won’t need to worry about configuring a root WebApplicationContext or an ApplicationContext for your DispatcherServlet. Based on metadata in your web module’s /META-INF/MANIFEST.MF, the Platform will auto-generate an appropriately configured web.xml for you on-the-fly, and your application will use the ApplicationContext created for your web module by Spring-DM. Future releases will add additional support to simplify configuration of Spring Web Flow based web applications as well.
Migration path from WAR to Web Module

The following diagram graphically depicts the migration path from a Standard WAR to a Web Module. As you can see, the libs move from within the deployment artifact to the Bundle Repository. Similarly, the services move from within the WAR to external bundles and are accessed via the OSGi Service Registry. In addition, the overall footprint of the deployment artifact decreases as you move towards a Web Module.

Migration path from WAR to Web Module
Platform Archives

The final piece of the puzzle is the PAR (Platform Archive) deployment format. A PAR is a standard JAR which contains all of the modules of your application (e.g., service, domain, and infrastructure bundles as well as a WAR or web module for web applications) in a single deployment unit. This allows you to deploy, refresh, and undeploy your entire application as a single entity. For those of you familiar with Java EE, a PAR can be considered a replacement for an EAR (Enterprise Archive) within the context of an OSGi container. As an added bonus, modules within a PAR can be refreshed independently and on-the-fly, for example via the SpringSource Application Platform Tool Suite (register for the beta program and check out the Eclipse tooling support).

Furthermore, PARs scope the modules of your application within the Platform. Scoping provides both a physical and logical application boundary, shielding the internals of your application from any other applications deployed within the Platform. This means your application doesn’t have to worry about clashing with other running applications (e.g., in the OSGi Service Registry). You get support for load-time weaving, classpath scanning, context class loading, etc., and the Platform does the heavy lifting for you to make all this work seamlessly in an OSGi environment. If you want to take full advantage of all that the SpringSource Application Platform and OSGi have to offer, packaging and deploying your applications as a PAR is definitely the recommend choice.
Where to go from here

If you haven’t already done so, I encourage you to join the beta program and take the SpringSource Application Platform for a test drive yourself.

You’ll find up-to-date documentation in the user guide and programmer guide, and if you happen to run into any issues deploying your applications or have recommendations on how we can improve the Platform, please don’t hesitate to create a JIRA issue.

And last but not least, be sure to check out upcoming posts on the SpringSource Team Blog to keep abreast of news regarding the Platform and to see working examples including an OSGi-ified Spring PetClinic sample application which has been modularized and packaged as a PAR.

自从上周三发布SpringSource应用程序平台以来，许多开发人员已经下载了1.0.0 Beta，并开始将该平台进行测试。结果，人们开始问：“如何在平台上部署我的应用程序？我有什么样的部署和打包选项？” 此外，开发人员迫切要求查看工作样本。作为响应，S2AP团队将在接下来的几周内发布几个示例应用程序，以演示这些功能以及更多功能，但是在您获得这些示例之前，我想向您提供有关部署和打包选项的高级概述。在平台上可用。阅读这篇文章后，您将可以使用示例以及您自己的应用程序开始工作。