阅读以下关于企业应用系统集成架构设计的说明，在答题纸上回答问题1和问题2。
【说明】
某航空公司希望对构建于上世纪七、八十年代的主要业务系统进行改造与集成，提高企业的竞争力。由于集成过程非常复杂，公司决定首先以Ramp Coordination系统为例进行集成过程的探索与验证。
在航空业中，Ramp Coordination是指飞机从降落到起飞过程中所需要进行的各种业务活动的协调过程。通常每个航班都有一位员工负责Ramp Coordination，称之为Ramp Coordinator。由Ramp Coordinator协调的业务活动包括检查机位环境、卸货和装货等。
由于航班类型、机型的不同，Ramp Coordination的流程有很大差异。图1-1 （a）所示的流程主要针对短期中转航班，这类航班在机场稍作停留后就起飞；图1-1（b）所示的流程主要针对到达航班，通常在机场过夜后第二天起飞；图1-1（c）所示的流程主要针对离港航班，这类航班是每天的第一班飞机。这三种类型的航班根据长途/短途、国内/国外等因素还可以进一步细分，每种细分航班类型的Ramp Coordination的流程也略有不同。
为了完成上述业务，Ramp Coordination信息系统需要从乘务人员管理系统中提取航班乘务员的信息、从订票系统中提取乘客信息、从机务人员管理系统中提取机务人员信息、接收来自航班调度系统的航班到达事件。其中乘务人员管理系统和航班调度系统运行在大型主机系统之上，机务人员管理系统运行在Unix操作系统之上，订票系统基于Java语言，具有Web界面，运行在Linux操作系统之上。
目前Ramp Coordination信息系统主要由人工完成所有协调工作，效率低且容易出错。公司领导要求集成后的Ramp Coordination信息系统能够针对不同需求迅速开展业务流程，灵活、高效地完成协调任务。
针对上述要求，公司IT部门的架构师经过分析与讨论，最终采用面向服务的架构，以服务为中心进行Ramp Coordination信息系统的集成工作。
服务建模是对Ramp Coordination信息系统进行集成的首要工作，公司的架构师首先对Ramp Coordination信息系统进行服务建模，识别出系统中的两个主要业务服务组件：
（1）Ramp Control：负责Ramp Coordination信息系统中各种相关业务活动的组件；
（2）Flight Management：负责航班相关信息的管理，包括航班日程、乘客信息等。针对上述服务模型，结合题干描述，请为每个业务服务组件提供的服务进行分析与整理，完成表1-1中的空白部分。
（1）检查机位环境、检查卸货、检查装货、检查关门
（2）接收航班信息
对Ramp Coordination信息系统进行服务建模的起点，是把可复用、可编排的业务能力抽象为“服务”，并与后端异构系统的资源解耦。题干明确：Ramp Coordinator要协调的业务活动包含检查机位环境、卸货、装货等；结合图示三类典型航班流程（中转、到达过夜、离港首班），我们可进一步识别在放行前的关门检查也是常见的关键节点。因此，在“以服务为中心”的SOA方法下，把这些与地面保障现场直接耦合的可操作性步骤，统一归入 Ramp Control 业务服务组件最为合理。它们的共同特征是：面向运行现场、与航班在站位的一次保障周期强相关、对外呈现为可编排的原子或复合服务（如“检查卸货”可能细分为货舱门状态检测、ULD核对、卸载清单校验等）。将这些能力打包为Ramp Control的服务，可以被前端工作流或规则引擎按不同航班类型灵活编排，满足“流程差异大”的诉求。
与此相对，Flight Management 的职责是航班信息管理：题干指出系统需“从乘务人员管理系统提取乘务员信息、从订票系统提取乘客信息、从机务系统提取机务信息、接收航班调度系统的到达事件”。这些都属于“航班主数据与运行态数据的汇聚、维护与发布”。因此在服务边界上，Flight Management对外暴露的最核心能力应是接收与管理航班信息（包括日程、乘客、事件与关联系统人员信息），为Ramp Control等下游流程提供“事实源”。这类服务偏向信息型（Information Services），强调一致性、时效性与订阅/推送（例如，航班到达事件被接收后触发Ramp流程实例的启动或变更）。
拓展来说，这种划分具备三点好处：第一，高内聚低耦合——现场操作类能力与信息管理类能力边界清晰；第二，可编排性——Ramp Control的原子服务可以被BPMN/规则驱动按航班类型动态组合，契合“流程差异大”的业务现实；第三，可演进性——当后端异构来源或接入方式变化时，只需在Flight Management侧适配，不影响Ramp Control的服务契约。