This is an automated email from the ASF dual-hosted git repository.
mikexue pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/eventmesh-site.git
The following commit(s) were added to refs/heads/master by this push:
new 9f819d284 [Doc]Upload EventMesh application scenario case (#238)
9f819d284 is described below
commit 9f819d2842e6128f7e12fc4eb6e0291fd3583f8b
Author: KrispauI <[email protected]>
AuthorDate: Sun Oct 27 21:10:39 2024 +0800
[Doc]Upload EventMesh application scenario case (#238)
* update application scenario
* update 05-generative-AI.md
* fix bulid errors
* upload docs of Chinese version
---
.../00-data-steam-processing.md | 20 ++++
.../01-data-synchronization.md | 32 ++++++
docs/application-scenario/02-SaaS-integration.md | 122 +++++++++++++++++++++
.../application-scenario/03-serverless-eventbus.md | 37 +++++++
.../04-connected-vehicle-service.md | 32 ++++++
docs/application-scenario/05-generative-AI.md | 33 ++++++
docs/application-scenario/_category_.json | 5 +
.../zh/docusaurus-plugin-content-docs/current.json | 4 +
.../00-data-steam-processing.md | 20 ++++
.../01-data-synchronization.md | 32 ++++++
.../application-scenario/02-SaaS-integration.md | 117 ++++++++++++++++++++
.../application-scenario/03-serverless-eventbus.md | 36 ++++++
.../04-connected-vehicle-service.md | 33 ++++++
.../application-scenario/05-generative-AI.md | 33 ++++++
.../current/application-scenario/_category_.json | 5 +
sidebars/docs.js | 12 ++
static/images/application-scenario/s0_img1.png | Bin 0 -> 655456 bytes
static/images/application-scenario/s1_img1.png | Bin 0 -> 94320 bytes
static/images/application-scenario/s2_img1.png | Bin 0 -> 179468 bytes
static/images/application-scenario/s2_img2.png | Bin 0 -> 292450 bytes
static/images/application-scenario/s2_img3.png | Bin 0 -> 225807 bytes
static/images/application-scenario/s3_img1_en.png | Bin 0 -> 109902 bytes
static/images/application-scenario/s3_img1_zh.png | Bin 0 -> 42812 bytes
static/images/application-scenario/s4_img1_en.png | Bin 0 -> 75068 bytes
static/images/application-scenario/s4_img1_zh.png | Bin 0 -> 92912 bytes
static/images/application-scenario/s5_img1.png | Bin 0 -> 26818 bytes
static/images/application-scenario/s5_img2.png | Bin 0 -> 25922 bytes
27 files changed, 573 insertions(+)
diff --git a/docs/application-scenario/00-data-steam-processing.md
b/docs/application-scenario/00-data-steam-processing.md
new file mode 100644
index 000000000..eac9f1728
--- /dev/null
+++ b/docs/application-scenario/00-data-steam-processing.md
@@ -0,0 +1,20 @@
+# Data Steam Processing
+
+* **Application Scenario Name**
+
+  **Data Steam Processing**
+
+
+* **Application Scenario Description**
+
+<div align="center">
+<img src="/images/application-scenario/s0_img1.png" width="80%" />
+</div>
+
+<!--
-->
+
+  Based on the figure above, EventMesh is between customer data and
target data sources, and can support streaming data processing. Through the
filter\transformer capabilities of the EventMesh function, the data format and
content desired by the customer can be processed and spit out to the target
data source to achieve data cleaning, rule filtering, character replacement,
data enrichment, data routing and other capabilities.
+
+* **Application Scenario Implementation Proposal**
+
+  To be continued...
diff --git a/docs/application-scenario/01-data-synchronization.md
b/docs/application-scenario/01-data-synchronization.md
new file mode 100644
index 000000000..a72650129
--- /dev/null
+++ b/docs/application-scenario/01-data-synchronization.md
@@ -0,0 +1,32 @@
+# Data Synchronization
+
+* **Application Scenario Name**
+
+  **Data Synchronization**
+
+
+* **Application Scenario Description**
+
+  Large enterprises typically have central data management platforms
that connect multiple business systems.Upstream business systems often need to
distribute data to multiple downstream systems, while each of these systems may
also perform asynchronous data changes, additions, and deletions. This requires
efficient data synchronization.Traditional data synchronization methods
typically rely on message queues or request/response models, but both
approaches have limitations: the [...]
+
+  Therefore, EventMesh is introduced to handle user data
synchronization based on the Event-Driven Architecture (EDA). The data
management center only needs to publish data change information to different
event sources. Each business system can then configure event targets and
subscribe to the relevant event sources to achieve data synchronization. During
the subscription process, business systems can bind transformation rules (for
data splitting and desensitization) and filter [...]
+
+* **Application Scenario Implementation Proposal**
+
+  In the data synchronization scenario, Geely Auto implemented an
event integration platform based on EventMesh. For example, in Geely's user
center system, most internal business systems cache user data locally after
integrating with the user center. As these business systems frequently modify
user data asynchronously, there is a strong demand for data synchronization.
+
+<div align="center">
+<img src="/images/application-scenario/s1_img1.png" width="80%" />
+</div>
+
+  Geely Automobile's event integration platform, built on EventMesh,
enables the user center to publish new and changed user data as "events" within
an event-driven architecture. Business systems subscribe to event sources to
retrieve necessary user data updates. For instance, the finance system may only
be interested in payment information updates, while the customer service system
cares about contact information changes.
+
+  To address the unique data needs of different business systems,
the platform utilizes EventMesh's filter/transformer capabilities. Event
sources are configured with transformation and filtering rules, enabling
business systems to subscribe and process user data splitting and
desensitization. This approach decouples direct interactions between the
business systems and the user center while reducing the performance load on the
user center.
+
+  To ensure high performance and availability, Geely Automobile's
event integration platform is deployed using a multi-region, multi-cluster,
cross-cloud architecture, catering to data from various business areas.
Different business systems can consume events across regions, clusters, and
clouds, enabling data access and synchronization while minimizing data
synchronization latency. This architecture ensures stable system operation,even
under high concurrency conditions.
+
+* **Reference**
+
+  ["Apache EventMesh the event grid helps build an event platform"
in CommunityOverCode Asia 2024](https://asia.communityovercode.org/)
+
+  ["How Geely Automobile implements event integration platform based
on EventMesh to promote efficient business
integration"](https://mp.weixin.qq.com/s/BLHbIq5KyjnhoVlmw9_DBw)
\ No newline at end of file
diff --git a/docs/application-scenario/02-SaaS-integration.md
b/docs/application-scenario/02-SaaS-integration.md
new file mode 100644
index 000000000..cc5531455
--- /dev/null
+++ b/docs/application-scenario/02-SaaS-integration.md
@@ -0,0 +1,122 @@
+# The SaaS composite application integration standardization
+
+* Application scenario name
+
+  **The SaaS composite application integration standardization**
+
+
+* Application scenario description
+
+  A SaaS composite application consists of multiple PBCs (Package
Business Capabilities). A PBC can be defined as a SaaS application module with
clearly defined business capabilities. Each module is business-driven and
capable of independently fulfilling business requirements without external
dependencies. Enterprise solutions are typically composed of multiple SaaS
application modules, integrating various complex functionalities to present a
unified and comprehensive user experience.
+
+  The diagram below illustrates a single PBC, a combination of PBCs,
and multiple composite PBCs:
+
+<div align="center">
+<img src="/images/application-scenario/s2_img1.png" width="80%" />
+</div>
+
+<!--  -->
+
+
+  From the above architecture, it is clear that each SaaS
application module (PBC) has a low degree of coupling. Modifying or adjusting a
specific module does not affect the operation of other existing modules.This
facilitates agile development and efficient iterative updates. However, one
challenge of SaaS composite applications is the lack of standardized
integration between different applications, as the absence of a unified
communication protocol can hinder the implementati [...]
+
+  This issue can be solved by EventMesh. EventMesh integrates TCP
and HTTP protocols, and supports bi-directional asynchronous communication
between Client and Server through gRPC (Google’s open-source high-performance
RPC framework based on HTTP/2) with SDKs available for multiple languages such
as Java, Python, C, and Go. Users do not need to worry about which
communication protocol is used in different scenarios when using the SDK; the
event-driven asynchronous communication [...]
+
+<div align="center">
+<img src="/images/application-scenario/s2_img2.png" width="60%" />
+</div>
+
+* Application scenario implementation proposal
+
+  Regarding the specific implementation of the scenario, EventMesh
officially introduced the `gRPC` framework starting from version v1.4.0. gRPC
defines API interface data models using Protobuf. In the gRPC Protobuf event
model, each event is represented by the `SimpleMessage` data model, with the
event content stored in the `content` field.
+
+<div align="center">
+<img src="/images/application-scenario/s2_img3.png" width="60%" />
+</div>
+
+  The gRPC event scenarios supported by EventMesh include: event
sending and batch event sending, event broadcasting, event request and
response, event subscription, and event pushing (for more details, see:
[eventmesh-client.proto](https://github.com/apache/eventmesh/blob/master/eventmesh-protocol-plugin/eventmesh-protocol-grpc/src/main/proto/eventmesh-client.proto)).
+
+  1. The event publishing service provides the following interfaces:
+
+
+```java
+service PublisherService {
+
+ rpc publish(SimpleMessage) returns (Response);
+
+ rpc requestReply(SimpleMessage) returns (SimpleMessage);
+
+ rpc batchPublish(BatchMessage) returns (Response);
+}
+```
+
+  Events are presented in the SimpleMessage data model. Event
publishing supports three modes: `synchronous publishing`, `asynchronous
publishing`, and `batch publishing`.
+
+   `Synchronous publishing` means the event producer sends the event
to EventMesh, waits for the event to be successfully delivered to the event
consumer, and receives a response from the event consumer. The end-to-end event
publishing process is only considered complete once this is done.
+
+   `Asynchronous publishing` means the event producer sends the
event to EventMesh without waiting for the event to be successfully delivered
to the event consumer.
+
+   `Batch publishing` refers to asynchronously sending a batch of
events to EventMesh.
+
+  2. The event subscription service provides the following
interfaces:
+
+```java
+service ConsumerService {
+
+ rpc subscribe(Subscription) returns (Response);
+
+ rpc subscribeStream(stream Subscription) returns (stream SimpleMessage);
+
+ rpc unsubscribe(Subscription) returns (Response);
+}
+```
+
+  Event subscription supports two modes: `cluster` and `broadcast`.
In cluster mode, only one instance within the event consumer cluster will
consume the event. In broadcast mode, every instance in the cluster will
consume the event.
+
+  These subscription modes are defined in the subscription data
model. Additionally, the subscription service provides two subscription
interfaces: `the subscribe API` and `the subscribeStream API`. `The subscribe
API` pushes events to consumers via a URL, also known as a webhook. This
scenario is suitable for cloud-native microservices, custom applications, and
functions. `The subscribeStream API` pushes events to consumers using gRPC
bidirectional streaming, allowing the even [...]
+
+  3. Event subscription service provides the following interfaces:
+
+  To improve the performance of event production and consumption,
the EventMesh server (`EventMesh Runtime`) defines thread pools within the gRPC
service. Moreover, independent parameters are configured based on different
performance requirements for event production and consumption. These parameters
can be found in the EventMesh configuration file (`eventmesh.properties`).
+
+  For example, the following are the number of threads for event
production, subscription, and pushing:
+
+```java
+eventMesh.server.sendmsg.threads.num=50
+eventMesh.server.clientmanage.threads.num=30
+eventMesh.server.pushmsg.threads.num=50
+```
+
+  When the gRPC service starts, it begins listening for client
requests. Once a new request arrives, it is dispatched to the thread pool of
the corresponding service, and the appropriate processor (`Processor`) handles
it. This prevents blocking the handling of subsequent requests, thereby
improving concurrency.
+
+```java
+public void publish(SimpleMessage request, StreamObserver<Response>
responseObserver){
+ cmdLogger.info("cmd={}|{}|client2eventMesh|from={}|to={}", "AsyncPublish",
+ EventMeshConstants.PROTOCOL_GRPC, request.getHeader().getIp(),
+ eventMeshGrpcServer.getEventMeshGrpcConfiguration().eventMeshIp);
+
+ EventEmitter<Response> emitter = new EventEmitter<>(responseObserver);
+
+ threadPoolExecutor.submit(() -> {
+ SendAsyncMessageProcessor sendAsyncMessageProcessor = new
SendAsyncMessageProcessor(eventMeshGrpcServer);
+ try {
+ sendAsyncMessageProcessor.process(request, emitter);
+ } catch (Exception e) {
+ logger.error("Error code {}, error message {}",
StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getRetCode(),
+ StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getErrMsg(), e);
+
ServiceUtils.sendRespAndDone(StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR,
e.getMessage(), emitter);
+ }
+ });
+}
+```
+
+  For instance, the above code is the implementation of the event
publishing service. It uses a `threadPoolExecutor` to send events to the thread
pool for downstream `SendAsyncMessageProcessor` handling.
+
+
+* Reference
+
+  ["How Does Apache Eventmesh Solve The Saas Composite Application
Integration Standardization Problem" in ApacheCon Asia
2022](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  [A Blog by Huawei Cloud Middleware
Team](https://mp.weixin.qq.com/s/Z3DAw_YtKJWXftdFjAm2rA)
+
+  [The Code of EventMesh in
Github](https://github.com/apache/eventmesh/tree/master/eventmesh-protocol-plugin/eventmesh-protocol-grpc/src/main/proto)
\ No newline at end of file
diff --git a/docs/application-scenario/03-serverless-eventbus.md
b/docs/application-scenario/03-serverless-eventbus.md
new file mode 100644
index 000000000..b96d7e127
--- /dev/null
+++ b/docs/application-scenario/03-serverless-eventbus.md
@@ -0,0 +1,37 @@
+# Serverless Event Bus for Cloud Services
+
+* Application scenario name
+
+  **Serverless Event Bus for Cloud Services**
+
+
+* Application scenario description
+
+  Cloud service providers can build a Serverless Event Bus using
`EventMesh` to facilitate and manage events across various sources, including
traditional applications, cloud-native services, and SaaS partner applications.
In this scenario, the Serverless Event Bus powered by EventMesh helps
developers create loosely coupled and distributed event-driven serverless
microservice applications without the need to manage underlying infrastructure.
+
+  This Serverless Event Bus supports asynchronous event
communication across different cloud environments. It simplifies protocol
management by routing events between services, making it suitable for
multi-cloud, hybrid cloud architectures, and third-party SaaS systems.
Additionally, the bus can be deployed in distributed environments, ensuring
reliable event delivery even under heavy load, thanks to `EventMesh`’s
cross-region failover and load-balancing capabilities.
+
+
+* Application scenario implementation proposal
+
+  Cloud service provider Huawei Cloud offers a Serverless Event Bus
service called `EventGrid`, which is based on `EventMesh`. `EventGrid` uses
`EventMesh` as its runtime engine and supports the integration of Huawei Cloud
services, custom applications, and SaaS applications in a standardized,
centralized manner. By utilizing the standardized CloudEvents protocol, it
flexibly routes events between applications, building a loosely coupled,
distributed event-driven architecture. [...]
+
+  As a crucial part of the event-driven architecture in a Serverless
environment, it provides elastic, asynchronous, and decentralized event
governance services. Key functions include event aggregation, schema
validation, filtering, routing, transformation, and pushing. Additionally, it
offers enhanced features like fault-tolerant retries, dead-letter storage,
event query tracking, and event workflows.
+
+<div align="center">
+<img src="/images/application-scenario/s3_img1_en.png" width="70%"/>
+</div>
+
+  The diagram above represents the overall architecture of Huawei
Cloud `EventGrid`. `EventGrid` connects to various cloud services as event
sources, including Distributed Message Service, Object Storage Service (OBS),
and Distributed Cache Service. The various events generated by these event
sources are pushed to the event channels of the `EventGrid` Event Bus (Bus
Runtime). The Event Bus configures event channels for EventGrid users on a
per-tenant basis, allowing multiple ev [...]
+
+  `EventGrid`, as the standard event hub for Huawei Cloud, enables
interconnection between various cloud services. Cloud services, acting as event
sources or event targets, are deployed on Huawei Cloud's Serverless application
platform. Applications push real-time business events to the event grid, where
the event grid filters, routes, and transforms the events to trigger cloud
services subscribed to those events. `EventGrid` currently supports over 100+
built-in Huawei Cloud e [...]
+
+* Reference
+
+  ["How Does Apache Eventmesh Solve The Saas Composite Application
Integration Standardization Problem"in ApacheCon Asia
2022](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  [A Blog by Huawei Cloud Middleware
Team](https://mp.weixin.qq.com/s/Z3DAw_YtKJWXftdFjAm2rA)
+
+  [The Instruction Document of EventGrid by Huawei
Cloud](https://www.huaweicloud.com/product/eventgrid.html)
+
+
diff --git a/docs/application-scenario/04-connected-vehicle-service.md
b/docs/application-scenario/04-connected-vehicle-service.md
new file mode 100644
index 000000000..e3323a8ec
--- /dev/null
+++ b/docs/application-scenario/04-connected-vehicle-service.md
@@ -0,0 +1,32 @@
+# Serverless Solution for Connected Vehicle Services
+
+* Application scenario name
+
+  **Serverless Solution for Connected Vehicle Services**
+
+
+* Application scenario description
+
+  In the connected vehicle scenario, the huge number of vehicles and
the variety of models from different automakers generate massive amounts of
data. A single vehicle can have hundreds of sensors continuously producing
data, and during peak hours (such as morning and evening rush hours), the
volume of connected vehicle data can surge dramatically. Additionally, the
automotive industry lacks standardized software development kits for connected
vehicles to reduce development cos [...]
+
+  The Serverless solution for connected vehicle services can use
`EventMesh` as an event bus and event center. The vast amounts of data from
vehicle sensors, GPS devices, and cloud platforms can be ingested via API
gateways or IoT devices. Once processed by the event-driven architecture, the
solution provides real-time responses and scales smoothly to handle increased
traffic during peak times(such as morning and evening rush hours).
+
+* Application scenario implementation proposal
+
+  The Serverless solution for connected vehicle services, powered by
`EventMesh`, offers dynamic scaling and high flexibility in an event-driven
architecture. It meets the demand for high concurrency and rapid elasticity.It
can scale dynamically during traffic surges to handle highly concurrent data.
`EventMesh` also provides flexible routing capabilities, allowing events to be
routed to different systems and services based on customizable configuration
rules.
+
+<div align="center">
+<img src="/images/application-scenario/s4_img1_en.png" width="80%"/>
+</div>
+
+  The diagram above illustrates the Serverless solution for
connected vehicle services. First, data can be cleaned, filtered using the
filter and transformer capabilities of `EventMesh`,then data is processed via
function computation.After processing, the data is stored in distributed object
storage, and events are generated. `EventMesh` routes these events to the
appropriate services based on predefined configuration rules. These services
include peak-shaving and valley-fillin [...]
+
+  In addition, this solution offers features such as automatic
scaling, fault tolerance with retry mechanisms, and cross-regional support,
ensuring reliable event delivery even under high-load conditions. With
`EventMesh`, external Webhooks can also be integrated, allowing events to be
pushed to other systems or third-party services, facilitating future service
expansion.
+
+* Reference
+
+  ["How Does Apache Eventmesh Solve The Saas Composite Application
Integration Standardization Problem"in ApacheCon Asia 2022
](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  ["Apache EventMesh in Huawei Cloud Next Generation of Enterprise
Cloud Native Event Centre: EventGrid" in Community Over Code NA
2023](https://communityovercode.org/past-sessions/community-over-code-na-2023/)
+
+  ["Building a very large-scale cloud event network based on
EventMesh——EventGrid" in
CoCAsia2023](https://github.com/apache/eventmesh-site/blob/master/meetup/WangHaijun_HUAWEI_ApacheCon_Asia_0801.pdf)
\ No newline at end of file
diff --git a/docs/application-scenario/05-generative-AI.md
b/docs/application-scenario/05-generative-AI.md
new file mode 100644
index 000000000..73088a67c
--- /dev/null
+++ b/docs/application-scenario/05-generative-AI.md
@@ -0,0 +1,33 @@
+# Event-Driven Architecture in Generative AI
+
+* Application scenario name
+
+  **Application of Event-Driven Architecture in Generative AI**
+
+* Application scenario description
+
+  The basic principle of Generative AI is to utilize Deep Learning
to learn from large amounts of multimodal data such as text, images, audio, and
video, thereby constructing complex statistical models that describe natural
language and other data.The training data for these models almost covers all
information on the internet, with an immense number of parameters, among which
Large Language Models (LLMs) are the most representative. The coherent
sentences generated by such mod [...]
+
+  Generative AI, which relies on large language models (LLMs),
requires continuous updates to its training data to ensure that the content it
generates reflects the latest language usage and information. However,
open-source LLMs typically face limitations in domain-specific data. This type
of data often belongs to specific industries or remains internal to
enterprises, not being publicly available on the internet. As a result, the
model cannot access or learn from this informa [...]
+
+* Application scenario implementation proposal
+
+  To address this issue, AI experts employ a combination of
Retrieval Augmented Generation (RAG) and Prompt Engineering. By inputting
domain-specific data into the LLM in real time, the model can leverage the
latest information to generate responses. The event-driven mechanism of
`EventMesh` is highly compatible with RAG, enabling real-time synchronization
of data into the LLM’s vector database. This allows the LLM to generate more
accurate responses based on new knowledge, thu [...]
+
+  In addition, `EventMesh's` Event Source and Event Sink can support
various types of event sources and event targets, adapting to different kinds
of data sources. Whether it's internal enterprise data or external public data,
they can be synchronized to the LLM's vector database through the event-driven
system, enabling data diversification for the LLM.
+
+
+
+  The event-driven architecture also enhances the resilience and
scalability of generative AI applications. The Retrieval Augmented Generation
(RAG) + Prompt Engineering method requires to establish a data pipeline
consisting of multiple microservices to process domain-specific data. The main
components of the data pipeline include Tokenization, Data Chunking, Data
Vectorization, Word Embedding, and Prompt Builder. The interaction between
these microservices can be done asynchr [...]
+
+<div align="center">
+<img src="/images/application-scenario/s5_img2.png" width="80%"/>
+</div>
+
+  The `EventMesh` community, along with other Apache open-source
communities, will continue to explore new application scenarios in the field of
generative AI. The Workflow and Event Source/Sink features of the EventMesh
architecture can help build generative AI applications, improving the real-time
capability and accuracy of AI applications while enhancing their scalability.
This enables the creation of real-time, cloud-native generative AI applications.
+
+* Reference
+
+  [A Speech in Community Over Code NA 2023:"Apache EventMesh in
Huawei Cloud Next Generation of Enterprise Cloud Native Event Centre:
EventGrid"](https://communityovercode.org/past-sessions/community-over-code-na-2023/)
+
+  [A Technical Blog of
EventMesh](https://mp.weixin.qq.com/s/r6tsKEtaSwdwBizty6X6jg)
\ No newline at end of file
diff --git a/docs/application-scenario/_category_.json
b/docs/application-scenario/_category_.json
new file mode 100644
index 000000000..8db3c6321
--- /dev/null
+++ b/docs/application-scenario/_category_.json
@@ -0,0 +1,5 @@
+{
+ "position": 7,
+ "label": "Application Scenario",
+ "collapsed": false
+}
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current.json
b/i18n/zh/docusaurus-plugin-content-docs/current.json
index d85617874..9e13ca1ff 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current.json
+++ b/i18n/zh/docusaurus-plugin-content-docs/current.json
@@ -30,5 +30,9 @@
"sidebar.tutorialSidebar.category.Connect": {
"message": "连接器",
"description": "The label for category Connect in sidebar tutorialSidebar"
+ },
+ "sidebar.tutorialSidebar.category.Application Scenario": {
+ "message": "应用场景",
+ "description": "The label for category Application Scenario in sidebar
tutorialSidebar"
}
}
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/00-data-steam-processing.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/00-data-steam-processing.md
new file mode 100644
index 000000000..7c8909ce9
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/00-data-steam-processing.md
@@ -0,0 +1,20 @@
+# 数据流处理
+
+* **应用场景名称**
+
+  **数据流处理**
+
+
+* **应用场景描述**
+
+<div align="center">
+<img src="/images/application-scenario/s0_img1.png" width="80%" />
+</div>
+
+<!-- 
-->
+
+  基于上图，EventMesh处于客户数据与目标数据源之间，可以支持流式数据处理。通过EventMesh功能的filter\transformer能力，可以处理成客户想要的数据格式和内容并吐出到目标数据源，实现数据清洗、规则过滤、字符替换、数据丰富、数据路由等能力。
+
+* **应用场景实施方案**
+
+  未完待续...
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/01-data-synchronization.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/01-data-synchronization.md
new file mode 100644
index 000000000..f72a73884
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/01-data-synchronization.md
@@ -0,0 +1,32 @@
+# 数据同步
+
+* **应用场景名称**
+
+  **数据同步**
+
+
+* **应用场景描述**
+
+  大型企业的中心数据管理平台通常连接着多个业务系统，上游业务系统需要将数据分发给多个下游业务系统，各业务系统也均有可能会进行异步的数据变更、增加与删除等操作，所以需要进行数据同步。传统的数据同步方式通常采用消息队列或请求/应答模式，但这两种方式都有局限性：消息队列方式难以切分不同业务单位的数据，数据管理上存在痛点；而请求/应答模式对中心数据管理平台的性能影响较大，耦合性高，影响系统的升级与维护。
+
+  因此需要引入EventMesh，通过基于事件驱动架构（EDA）进行用户数据同步，数据管理中心只需将数据变更信息分别发布到不同的事件源。各业务系统通过配置事件目标并订阅相关事件源来实现数据同步。在订阅过程中，各业务系统可以绑定相应的转换规则（用于数据的拆分和脱敏处理）和过滤规则，从而实现系统架构的解耦。
+
+* **应用场景实施方案**
+
+  在数据同步场景下，吉利汽车基于EventMesh进行了落地实践，构建了事件集成平台。以吉利汽车的用户中心系统为例，企业内部大部分业务系统在集成用户中心后，会进行用户数据本地缓存；而各业务系统会对用户数据进行高频次的异步修改，产生了数据同步的需求。
+
+<div align="center">
+<img src="/images/application-scenario/s1_img1.png" width="80%" />
+</div>
+
+  吉利汽车基于 EventMesh
构建的事件集成平台，让用户中心基于事件驱动架构，能够以“事件”的方式发布用户数据的新增和变更信息，而各个业务系统订阅事件源以获取所需的用户数据更新。例如，财务系统可能只对用户的支付信息变更感兴趣，而客服系统则关心用户联系方式的更新。
+
+  而为了处理不同业务系统对用户数据的个性化需求，平台基于EventMesh
的filter\transformer能力，配置事件源的转换与过滤规则，业务系统订阅事件源来进行用户数据拆分和脱敏处理。不仅解耦了业务系统与用户中心之间的直接交互，还减少了用户中心性能负载。
+
+  
为了保证高性能和高可用性，吉利汽车的事件集成平台面向各个业务区域的数据，采用了多地域、多集群的跨云架构进行部署。不同业务系统可以跨区域、跨集群、跨云消费事件，实现数据访问和同步，确保数据同步的延迟最小化，并且在高并发环境下仍能保持系统的稳定运行。
+
+* **参考资料**
+
+  [CommunityOverCode Asia 2024 会议演讲《Apache EventMesh事件网格助力构建事件平台》
](https://asia.communityovercode.org/)
+
+  [吉利汽车如何基于EventMesh落地事件集成平台，助力业务高效集成](https://mp.weixin.qq.com/s/BLHbIq5KyjnhoVlmw9_DBw)
\ No newline at end of file
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/02-SaaS-integration.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/02-SaaS-integration.md
new file mode 100644
index 000000000..cdf01c5be
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/02-SaaS-integration.md
@@ -0,0 +1,117 @@
+# SaaS组合式应用集成标准化
+
+* **应用场景名称**
+
+  **SaaS组合式应用集成标准化**
+
+
+* **应用场景描述**
+
+  Saas组合式应用由多个PBC（Package Business
Capability）组成，PBC可以被定义为具有明确业务能力的SaaS应用程序模块，该模块以业务为驱动，能独立完成业务需求，不需要外部依赖。企业解决方案通常由多个SaaS应用程序模块进行组合，以呈现完整统一的用户体验。
+
+  下图为单一PBC、组合PBC和多个组合PBC的示意图：
+
+<div align="center">
+<img src="/images/application-scenario/s2_img1.png" width="80%" />
+</div>
+
+  由以上架构可见，每个SaaS应用程序模块（PCB）之间的耦合程度较低，对某个业务进行修改调整时，均不会影响到其他现有业务的运行，这有助于敏捷开发与高效的迭代更新。但SaaS组合式应用存在各个应用间集成标准的问题，各应用之间缺乏统一的通讯协议标准就给业务落地该架构带来了困难。
+
+  该问题可以使用Eventmesh解决，EventMesh整合了TCP和HTTP协议，同时通过gRPC(谷歌开源的基于HTTP/2的高性能RPC框架)支持Java、Python、C、Go等多语言SDK，从而支持Client和Server双向异步通讯。用户在使用SDK时无需考虑不同场景所使用的具体通讯协议，基于EventMesh所整合的SDK
API即可进行事件驱动的异步通讯，实现了不同SaaS应用程序模块之间的事件流转。
+
+<div align="center">
+<img src="/images/application-scenario/s2_img2.png" width="60%" />
+</div>
+
+* **应用场景实施方案**
+
+  关于场景的具体实现，EventMesh从v1.4.0版本开始正式引入 `gRPC` 框架，`gRPC` 通过 Protobuf
定义API接口数据模型，统一由CloudEvents定义事件模型。在gRPC的Protobuf事件模型中，每个事件是以 `SimpleMessage`
的数据模型呈现，事件的实体内容放在 `content` 字段里，CloudEvents是业界流行的事件模型。
+
+<div align="center">
+<img src="/images/application-scenario/s2_img3.png" width="60%" />
+</div>
+
+  在EventMesh所支持的gRPC事件使用场景包括：事件发送和批量事件发送、事件广播、事件请求和响应、事件订阅和推送（详见代码：[eventmesh-client.proto](https://github.com/apache/eventmesh/blob/master/eventmesh-protocol-plugin/eventmesh-protocol-grpc/src/main/proto/eventmesh-client.proto)）
+
+  1.事件发送服务提供了以下接口：
+
+```java
+service PublisherService {
+
+ rpc publish(SimpleMessage) returns (Response);
+
+ rpc requestReply(SimpleMessage) returns (SimpleMessage);
+
+ rpc batchPublish(BatchMessage) returns (Response);
+}
+```
+
+  事件是以SimpleMessage的数据模型呈现。事件发送支持同步发送、异步发送和批量发送三种模式：
+
+  同步发送是指事件生产者发送事件到EventMesh，并等待事件成功推送到事件消费者，并收到事件消费者的返回，才算完成整个端到端的事件发送过程；
+
+  异步发送是指事件生产者发送事件到EventMesh即可，无需等待事件被成功推送到事件消费者；
+
+  批量发送是指异步发送一批事件到EventMesh。
+
+  2.事件订阅服务提供以下接口：
+
+```java
+service ConsumerService {
+
+ rpc subscribe(Subscription) returns (Response);
+
+ rpc subscribeStream(stream Subscription) returns (stream SimpleMessage);
+
+ rpc unsubscribe(Subscription) returns (Response);
+}
+```
+
+  事件订阅支持两种方式：集群(cluster)
和广播(broadcast)。在集群模式中，事件消费者集群里只有一个实例能消费到事件；而广播模式让集群里每一个实例都消费到事件。
+
+  这些订阅模式是在订阅数据模型里定义的。另外订阅服务提供两种订阅接口：`subscribe API` 和
`subscribeStream API`。`subscribe
API`是通过url方式推送事件到消费者，这里url又叫webhook，这种场景适合云原生微服务和自定义应用及函数；`subscribeStream
API`是通过gRPC 双向流(Bidirectional Streaming) 推送事件到消费者，同时可以让事件消费者返回确认信息 (Ack)
给事件生产者。这就满足了生产者RequestReply同步事件发送的需求。
+
+  3.事件订阅服务提供以下接口：
+
+  为了提高事件生产和消费的性能，EventMesh服务端(EventMesh Runtime)
在gRPC的服务里定义了线程池(ThreadPool)，而且针对事件生产和消费的对性能要求的不同，配置独立的参数。这些参数都可以在EventMesh配置文件(`eventmesh.properties`)里找到。
+
+  例如以下分别是事件生产，订阅和推送的线程数：
+
+```java
+eventMesh.server.sendmsg.threads.num=50
+eventMesh.server.clientmanage.threads.num=30
+eventMesh.server.pushmsg.threads.num=50
+```
+
+  当gRPC服务启动后，它会监听客户端的请求，一旦有新请求进来，它会分发到对应服务的线程池，然后让对应的处理器(Processor)处理，这样就不会阻塞下一个请求的处理，从而提高了并发量。
+
+```java
+public void publish(SimpleMessage request, StreamObserver<Response>
responseObserver){
+ cmdLogger.info("cmd={}|{}|client2eventMesh|from={}|to={}", "AsyncPublish",
+ EventMeshConstants.PROTOCOL_GRPC, request.getHeader().getIp(),
+ eventMeshGrpcServer.getEventMeshGrpcConfiguration().eventMeshIp);
+
+ EventEmitter<Response> emitter = new EventEmitter<>(responseObserver);
+
+ threadPoolExecutor.submit(() -> {
+ SendAsyncMessageProcessor sendAsyncMessageProcessor = new
SendAsyncMessageProcessor(eventMeshGrpcServer);
+ try {
+ sendAsyncMessageProcessor.process(request, emitter);
+ } catch (Exception e) {
+ logger.error("Error code {}, error message {}",
StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getRetCode(),
+ StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR.getErrMsg(), e);
+
ServiceUtils.sendRespAndDone(StatusCode.EVENTMESH_SEND_ASYNC_MSG_ERR,
e.getMessage(), emitter);
+ }
+ });
+}
+```
+
+  比如以上代码是事件发送服务(publish service)
的实现。它使用了`threadPoolExecutor`把事件发送到线程池让下游`SendAsyncMessageProcessor`处。
+
+* **参考资料**
+
+  [ApacheCon Asia
2022会议演讲《EventMesh如何解决SaaS组合式应用集成标准化问题》](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  [华为云中间件团队的技术博客](https://mp.weixin.qq.com/s/Z3DAw_YtKJWXftdFjAm2rA)
+
+  [EventMesh项目源代码](https://github.com/apache/eventmesh/tree/master/eventmesh-protocol-plugin/eventmesh-protocol-grpc/src/main/proto)
\ No newline at end of file
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/03-serverless-eventbus.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/03-serverless-eventbus.md
new file mode 100644
index 000000000..914fb0f14
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/03-serverless-eventbus.md
@@ -0,0 +1,36 @@
+# 云服务的Serverless事件总线
+
+* **应用场景名称**
+
+  **云服务的Serverless事件总线**
+
+
+* **应用场景描述**
+
+  云服务提供商可以基于 `EventMesh` 构建 Serverless
事件总线，用于承载和管理来自传统应用、云原生服务以及SaaS合作伙伴应用等不同来源的各类事件。在此场景下，基于 `EventMesh` 的
Serverless 事件总线帮助开发者构建松耦合、分布式、事件驱动的Serverless微服务应用，而无需管理底层基础设施。
+
+  Serverless
事件总线支持跨不同云环境的异步事件通信。它通过在不同服务之间路由事件，简化协议管理的复杂性，尤其适用于多云、混合云架构以及第三方SaaS系统的事件处理；同时该总线可以部署在分布式环境下，借助
`EventMesh` 的跨区域故障转移和负载均衡功能，即使在高负载下也能确保事件的可靠传递。
+
+* **应用场景实施方案**
+
+  云服务厂商华为云所提供的的Serverless事件总线服务 `EventGrid` 便是基于 `EventMesh`
的实际应用。`EventGrid` 以 `EventMesh` 作为运行时引擎，支持华为云服务、自定义应用、SaaS应用以标准化、中心化的方式接入，以标准化的
`CloudEvents` 协议在应用之间灵活路由事件，从而构建松耦合、分布式的事件驱动架构，为华为云创造更多的应用场景，也进一步丰富了开发者生态。
+
+  作为Serverless架构下事件驱动架构的关键一环，它提供弹性、异步、去中心化的事件治理服务，对事件提供汇聚、模型校验、过滤、路由、转换和推送等核心功能，还包括容错重试、死信储存、事件查询跟踪、事件工作流等增强特性。
+
+<div align="center">
+<img src="/images/application-scenario/s3_img1_zh.png" width="70%"/>
+</div>
+
+  以上是华为云 `EventGrid` 的总体架构图， 可见 `EventGrid`
对接了诸多云服务作为事件源，包括分布式消息服务、对象存储服务(OBS)和分布式缓存服务。事件源所产生的各种事件，推送至 `EventGrid`
事件总线(Bus Runtime)的事件通道中。事件总线为 `EventGrid`
用户以租户为单位配置事件通道，一个租户下允许有多个事件通道，承载来自不同事件源的事件。
+
+  `EventGrid`
作为华为云服务的标准事件中心，可以实现各个云服务之间的联动。云服务作为事件源或者事件目标部署在华为云的无服务器（Serverless）应用平台上，应用推送业务实时事件到事件网格，事件网格对事件进行过滤、路由和转化，从而触发订阅事件的云服务。`EventGrid`
现已内置100+华为云事件源，支持自定义和伙伴事件扩展；同时有海量官方数据源支持，覆盖数据库、消息、函数计算、大数据类、DevOps平台、IOT等，支持自定义事件集成。
+
+  `EventGrid`
用户通过订阅的方式消费事件，通过在订阅的配置项里定义事件源、事件目标、事件过滤和转换规则，`EventGrid`
就能从事件总线里提取相关事件，然后实时推送到所定义的事件目标中。推送方式可以是同步和异步：同步推送一般是以HTTP协议，适合应用和微服务；异步推送一般是推动到SaaS伙伴应用的消息队列中。
+
+* **参考资料**
+
+  [ApacheCon Asia
2022会议演讲《EventMesh如何解决SaaS组合式应用集成标准化问题](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  [华为云中间件团队的技术博客](https://mp.weixin.qq.com/s/Z3DAw_YtKJWXftdFjAm2rA)
+
+  [华为云EventGrid使用教程文档](https://www.huaweicloud.com/product/eventgrid.html)
\ No newline at end of file
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/04-connected-vehicle-service.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/04-connected-vehicle-service.md
new file mode 100644
index 000000000..e15e86da9
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/04-connected-vehicle-service.md
@@ -0,0 +1,33 @@
+# Serverless化车联网解决方案
+
+* **应用场景名称**
+
+  **Serverless化车联网解决方案**
+
+
+* **应用场景描述**
+
+  车联网场景下，由于汽车数量庞大，且车企旗下存在多种不同型号的新老车型，车企数据处理的业务量巨大。一辆汽车有上百种传感器，不停在产生数据，且在早晚用车高峰的场景下，车联网数据将会激增；同时汽车行业缺少车联网开发套件来降低开发成本和缩短上线时间，对Serverless化车联网业务解决方案有着广泛需求。
+
+  Serverless化车联网业务解决方案可使用 `EventMesh`
作为事件总线与事件中心。来自汽车各传感器、GPS设备和云平台的海量数据可通过API网关或者利用IOTS设备接入，数据经由事件驱动的架构处理后，能够提供实时响应，在高峰流量期间（如早晚高峰）实现流畅的扩展。
+
+
+* **应用场景实施方案**
+
+  基于 `EventMesh`
的Serverless化车联网业务解决方案，在事件驱动的架构上灵活扩展，自动伸缩，满足了高并发，快速弹性的需求，在数据高峰期动态扩展，以实现高并发数据处理；`EventMesh`
同时提供了灵活的路由能力，通过不同的配置规则，可将事件路由到不同的系统与服务。
+
+<div align="center">
+<img src="/images/application-scenario/s4_img1_zh.png" width="80%"/>
+</div>
+
+  上图为Serverless化车联网业务解决方案的简要示意图，首先基于`EventMesh`
的filter\transformer能力，进行数据清洗过滤与函数计算处理，数据处理后将进行分布式对象存储并产生事件。`EventMesh`
根据不同的配置规则，将事件路由至相应的服务（包括削峰填谷的消费服务、AI智能推荐服务以及多个部门多个业务的相应服务）。这允许各种服务只需对特定事件做出响应，而无需与数据源直接耦合。
+
+  除此之外，该解决方案具备自动伸缩、容错重试机制以及跨区域支持等功能，即使在高负载条件下也能确保事件的可靠传递。基于
`EventMesh` 集成外部Webhooks，还可以将事件推送到其他系统或第三方服务，便于后续的服务扩展。
+
+* **参考资料**
+
+  [ApacheCon Asia 2022
会议演讲《EventMesh如何解决SaaS组合式应用集成标准化问题》](https://www.youtube.com/watch?v=0v-tjIYkDIw)
+
+  [Community Over Code NA 2023 会议演讲《Apache EventMesh in Huawei Cloud
Next Generation of Enterprise Cloud Native Event Centre:
EventGrid》"](https://communityovercode.org/past-sessions/community-over-code-na-2023/)
+
+  [CoCAsia 2023
会议演讲《基于EventMesh构建超大规模云原生事件网格——EventGrid》](https://github.com/apache/eventmesh-site/blob/master/meetup/WangHaijun_HUAWEI_ApacheCon_Asia_0801.pdf)
\ No newline at end of file
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/05-generative-AI.md
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/05-generative-AI.md
new file mode 100644
index 000000000..6f6b84c2f
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/05-generative-AI.md
@@ -0,0 +1,33 @@
+# 事件驱动架构在生成式AI中的运用
+
+* **应用场景名称**
+
+  **事件驱动架构在生成式AI中的运用**
+
+* **应用场景描述**
+
+  生成式AI的基本原理是通过深度学习技术对大量文本、图像、音频和视频等多模态数据进行学习，构建得到描述自然语言和其他数据的复杂统计模型。此类模型的训练数据几乎涵盖了互联网中的所有信息，参数量巨大，大语言模型（Large
Language
Model,LLM）是其中的典型代表。这类模型所生成的连贯语句，并非真正“理解”了语言，而是通过复杂的数学计算推断出最可能的词汇或句子结构，最终生成自然流畅的文本输出。这种过程依赖于模型对大量数据的学习，预测得到输出结果。
+
+  生成式AI依赖的大型语言模型（LLM）需要持续更新训练数据，以确保其生成的内容能够反映最新的语言使用和信息。然而，通常开源的LLM模型在专业领域数据（Domain-Specific
Data）方面存在局限。这些数据往往属于特定行业或企业内部，未公开于互联网，因此模型无法获取并学习这些信息，从而在处理专业领域的问题时表现较为有限。
+
+* **应用场景实施方案**
+
+  为了解决这样的问题，AI领域专家利用Retrieval Augmented Generation (RAG) + Prompt
Engineering 的方法,实时向LLM模型输入领域特定数据 (Domain Specific Data) 让LLM利用到最新的数据产生回答。而
`EventMesh` 的事件驱动机制与RAG高度兼容，能够让数据实时同步到LLM的向量数据库(Vector
Database)，从而使LLM基于新知识产生更准确的回答,构建实时性生成式AI (Real-time Generative AI)。
+
+  除此之外，`EventMesh` 的 Event Source 和 Event Sink
支持多种事件源和事件目标，适配不同类型的数据源无论是企业内部数据，还是外部公开数据，都可以通过事件驱动系统同步给到LLM的向量数据库，实现LLM数据的多样化。
+
+
+
+  事件驱动架构也增强了生成式AI应用的韧性和可扩展性。RAG + Prompt
工程的方法需要建立由多个微服务组成的数据流水线(Data
Pipeline)来处理领域特定数据。数据流水线的主要部分包括`Tokenization`，`Data Chunking`，`Data
Vectorization`，`Word Embedding` 和 `Prompt Builder`。
这些微服务之间的交互可以通过事件驱动方式异步通信。随着数据量的增大，每个微服务可以独立自动扩容，而不影响整个数据流水线的架构。如果系统想要增加新的微服务，比如构建一个User
Feedback App来处理用户反馈数据，则可以通过消费和发布指定Topic跟Data
Pipeline其他微服务交互，无需修改其他微服务的接口。`EventMesh` 的 `Serverless Workflow`
事件流特性可以用来构建这样的数据流水线。
+
+<div align="center">
+<img src="/images/application-scenario/s5_img2.png" width="80%"/>
+</div>
+
+  EventMesh社区和Apache其他开源项目社区将一起持续地探索生成式AI领域新的应用场景。EventMesh架构的Workflow，Event
Source / Sink 特性可以帮助构建生成式AI应用，提高AI应用的实时性与准确率，同时增强应用的可扩展性，打造出实时的云原生生成式AI应用。
+
+* **参考资料**
+
+  [Community Over Code NA 2023 会议演讲《Apache EventMesh in Huawei Cloud
Next Generation of Enterprise Cloud Native Event Centre:
EventGrid》"](https://communityovercode.org/past-sessions/community-over-code-na-2023/)
+
+  [EventMesh技术博客](https://mp.weixin.qq.com/s/r6tsKEtaSwdwBizty6X6jg)
\ No newline at end of file
diff --git
a/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/_category_.json
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/_category_.json
new file mode 100644
index 000000000..8db3c6321
--- /dev/null
+++
b/i18n/zh/docusaurus-plugin-content-docs/current/application-scenario/_category_.json
@@ -0,0 +1,5 @@
+{
+ "position": 7,
+ "label": "Application Scenario",
+ "collapsed": false
+}
diff --git a/sidebars/docs.js b/sidebars/docs.js
index b0d9d06ec..59cb6be89 100644
--- a/sidebars/docs.js
+++ b/sidebars/docs.js
@@ -103,5 +103,17 @@ module.exports = {
},
],
},
+ {
+ type: 'category',
+ label: 'Application Scenario',
+ collapsible: true,
+ collapsed: false,
+ items: [
+ {
+ type: 'autogenerated',
+ dirName: 'application-scenario',
+ },
+ ],
+ },
],
};
diff --git a/static/images/application-scenario/s0_img1.png
b/static/images/application-scenario/s0_img1.png
new file mode 100644
index 000000000..3e17530dc
Binary files /dev/null and b/static/images/application-scenario/s0_img1.png
differ
diff --git a/static/images/application-scenario/s1_img1.png
b/static/images/application-scenario/s1_img1.png
new file mode 100644
index 000000000..f272c5cd8
Binary files /dev/null and b/static/images/application-scenario/s1_img1.png
differ
diff --git a/static/images/application-scenario/s2_img1.png
b/static/images/application-scenario/s2_img1.png
new file mode 100644
index 000000000..97655b810
Binary files /dev/null and b/static/images/application-scenario/s2_img1.png
differ
diff --git a/static/images/application-scenario/s2_img2.png
b/static/images/application-scenario/s2_img2.png
new file mode 100644
index 000000000..0bafbd32d
Binary files /dev/null and b/static/images/application-scenario/s2_img2.png
differ
diff --git a/static/images/application-scenario/s2_img3.png
b/static/images/application-scenario/s2_img3.png
new file mode 100644
index 000000000..5b6783a02
Binary files /dev/null and b/static/images/application-scenario/s2_img3.png
differ
diff --git a/static/images/application-scenario/s3_img1_en.png
b/static/images/application-scenario/s3_img1_en.png
new file mode 100644
index 000000000..2a1bca292
Binary files /dev/null and b/static/images/application-scenario/s3_img1_en.png
differ
diff --git a/static/images/application-scenario/s3_img1_zh.png
b/static/images/application-scenario/s3_img1_zh.png
new file mode 100644
index 000000000..3ab09d652
Binary files /dev/null and b/static/images/application-scenario/s3_img1_zh.png
differ
diff --git a/static/images/application-scenario/s4_img1_en.png
b/static/images/application-scenario/s4_img1_en.png
new file mode 100644
index 000000000..7f154cc5b
Binary files /dev/null and b/static/images/application-scenario/s4_img1_en.png
differ
diff --git a/static/images/application-scenario/s4_img1_zh.png
b/static/images/application-scenario/s4_img1_zh.png
new file mode 100644
index 000000000..9af1c76e5
Binary files /dev/null and b/static/images/application-scenario/s4_img1_zh.png
differ
diff --git a/static/images/application-scenario/s5_img1.png
b/static/images/application-scenario/s5_img1.png
new file mode 100644
index 000000000..81e3d14a0
Binary files /dev/null and b/static/images/application-scenario/s5_img1.png
differ
diff --git a/static/images/application-scenario/s5_img2.png
b/static/images/application-scenario/s5_img2.png
new file mode 100644
index 000000000..d7a12d39a
Binary files /dev/null and b/static/images/application-scenario/s5_img2.png
differ
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
