Xây dựng ứng dụng theo kiến trúc HDV

Các nguyên tắc trong thiết kế hướng dịch vụ

Việc tiếp cận xây dựng các hệ thống dựa trên mô hình hướng dịch vụ phải tuân theo bốn nguyên tắc sau:

Nguyên tắc 1: Giao diện của dịch vụ phải rõ ràng. Các dịch vụ tương tác qua việc truyền đi các thông điệp tường minh. Chúng ta không cần biết về không gian nằm sau giao diện của dịch vụ. Vượt qua các giao diện của dịch vụ có thể tốn nhiều công sức và chi phí. Các giao diện rõ ràng cho phép cài đặt các tương tác độc lập- nghĩa là không cần biết về nền tảng hay ngôn ngữ lập trình được lựa chọn để cài đặt.

Nguyên tắc 2: Dịch vụ là tự trị. Các dịch vụ hoạt động như là các thực thể độc lập. Không có quyền làm chủ trong một môi trường hướng dịch vụ. Các dịch vụ được triển khai, thay đổi, quản lý một cách độc lập.

Nguyên tắc 3:Các dịch vụ chia sẻ giao diện và giao ước không chia sẻ cài đặt. Các dịch vụ tương tác với nhau chỉ dựa vào giao diện và giao ước sử dụng dịch vụ. Giao ước của dịch vụ mô tả cấu trúc của thông điệp và các ràng buộc giữa các thông điệp, điều này cho phép chúng ta bảo toàn được tính toàn vẹn của dịch vụ. Các giao ước và giao diện phải được duy trì tính ổn định với thời gian. Vì vậy việc xây dựng chúng một cách mềm dẻo là rất quan trọng.

Nguyên tắc 4: Tính tương thích của dịch vụ phải dựa trên chính sách. Cả người cung cấp và người dùng dịch vụ sẽ phải có các chính sách để tương tác qua các giao diện của dịch vụ. Một ví dụ đơn giản về chính sách phía người cung cấp là một dịch vụ có thể đòi hỏi người gọi phải có một tài khoản hợp lệ với người cung cấp dịch vụ. Về phía người dùng dịch vụ, một tổ chức có thể đòi hỏi các lời kêu gọi qua Internet phải được mã hoá.

Các quyết định thiết kế và kiến trúc trong kiến trúc hướng dịch vụ

Có rất nhiều quyết định thiết kế và kiến trúc là nền tảng cho SOA để đạt được các mục tiêu và lợi ích mà kiến trúc này đã nêu ra. Các quyết định kiến trúc thường liên quan tới việc chọn lựa các công nghệ và sản phẩm cần thiết kế để đáp ứng chất lượng cho các thuộc tính dịch vụ được yêu cầu bởi một quy trình nghiệp vụ. Các quyết định thiết kế tập trung vào các lựa chọn dịch vụ sử dụng kỹ thuật được mô tả sau trong phân tích và thiết kế hướng đối tượng. Một số các quyết định chính là:

1. Xác định dịch vụ: các quyết định thiết kế quyết định thành công một kiến trúc hướng dịch vụ.
2. Thiết kế cài đặt thành phần chứa: các quyết định thiết kế và kiến trúc rất quan trọng để một dịch vụ cung cấp các chức năng cho việc mở rộng và bảo trì.
3. Mức độ đóng gói : các lựa chọn thiết kế về dịch vụ phải phù hợp với mức độ tái sử dụng và mềm dẻo được yêu cầu trong ngữ cảnh cụ thể. Các dịch vụ có mức độ đóng gói cao hơn có thể trợ giúp việc đóng gói các thay đổi trong các dịch vụ kỹ thuật có mức độ đóng gói thấp hơn (các dịch vụ này thường có xu hướng thay đổi thường xuyên hơn so với các nghiệp vụ ở ở mức cao hơn). Các nhân tố của tính mềm dẻo sẽ là các tiêu chuẩn chính cho việc đóng gói hơn là việc chỉ đơn thuần đóng gói chức năng.
4. Tính gắn kết không chặt chẽ và cấu hình lại động là một quyết định thiết kế yêu cầu việc tách giao diện khỏi cài đặt giao thức thông qua các chuẩn mở. Kết nối giữa các thành phần cung cấp và sử dụng dịch vụ cần phải bền vững và được cấu trúc rõ ràng, có khả năng cấu hình lại linh hoạt. Có khả năng cấu hình lại có nghĩa là các thành phần sử dụng dịch vụ và các thành phần cung cấp dịch vụ hiện có thể được lắp ghép lại với các chức năng không bị thay đổi để đạt được các giải pháp nghiệp vụ trong các môi trường kỹ thuật khác nhau và với các ràng buộc thao tác khác nhau của các đối tác kinh doanh mới.

Các tầng SOA: Các thành phần của một kiến trúc hướng dịch vụ.

Danh mục dịch vụ: mô tả các dịch vụ nghiệp vụ trogn SOA, bao gồm một danh sách, phân loại và cấu trúc của các dịch vụ được xác định thông qua kỹ thuật phân tích và thiết kế hướng dịch vụ.

Các thành phần: cung cấp các cài đặt chức năng cuả dịch vụ.

Thành phần sử dụng dịch vụ, thành phần cung cấp dịch vụ và thành phần môi giới dịch vụ với các kho đăng ký dịch vụ, ở đó, các định nghĩa và mô tả dịch vụ được xuất bản.

Các tầng của SOA: vị trí của các thành phần và dịch vụ.

Hình 5.4 mô tả các tầng của SOA. Với mỗi tầng, các quyết định thiết kế và kiến trúc được tiến hành.

Các tầng của SOA

Tầng 1: tầng dưới cùng, mô tả các hệ thống vận hành. Tầng này chứa các hệ thống hoặc các ứng dụng hiện có, bao gồm các ứng dụng được đóng gói, các ứng dụng đang có, và các cài đặt hệ thống hướng đối tượng theo kiểu cũ cũng như các ứng dụng thu thập nghiệp vụ. Kiến trúc theo tầng của một kiến trúc hướng đối tượng có thể thúc đẩy các hệ thống hiện có, tích hợp chúng bằng cách sử dụng tích hợp hướng dịch vụ.

Tầng 2: tầng thành phần, sử dụng các kỹ thuật và thiết kế dựa đối tượng chứa trong phát triển hướng thành phần truyền thống.

Tầng 3: cung cấp các cơ chế để lấy các thành phần ở quy mô doanh nghiệp, các thành phần cho từng đơn vị doanh nghiệp cụ thể, và trong một số trường hợp là các thành phần của từng dự án và cung cấp các dịch vụ thông qua các giao diện của chúng. Trong tầng này, các giao diện được thể hiện ra ngoài thông qua các đặc tả dịch vụ, ở đó, các dịch vụ tồn tại một cách độc lập hoặc là tổng hợp của một số dịch vụ.

Tầng 4: là một sự tiến hoá của việc tổng hợp dịch vụ các luồng hoặc sắp đặt các nhiệm vụ đượcc phân nhóm vào một luồng để hoạt động như một ứng dụng. Các ứng dụng này hỗ trợ các trường hợp sử dụng các quy trình nghiệp vụ cụ thể. ở đây, các công cụ tổng hợp luồng trực quan có thể được sử dụng để thiết kế luồng ứng dụng.

Tầng 5: Tầng trình diễn thường nằm ngoài phạm vi của một kiến trúc hướng dịch vụ.

Tầng 6: cho phép sự tích hợp của các dịch vụ thông qua việc định tuyến tin cậy và thông minh, giao thức trung gian, và một số cơ chế chuyển đổi khác, thường đựơc mô tả như là một tuyến dịch vụ doanh nghiệp (ESB- Enterprise Services Bus).

Tầng 7: đảm bảo chất lượng dịch vụ thông qua các cơ chế cảm biến và đáp ứng các công cụ kiểm soát các ứng dụng SOA.

Các mức độ chấp nhận kiến trúc hướng dịch vụ

Việc sử dụng kiến trúc hướng dịch vụ không bị giới hạn cho các tổ chức hơn. Trong thực tế, kiến trúc này tạo ra cơ hội cho các tổ chức vừa và nhỏ. Một ví dụ về việc các doanh nghiệp nhỏ có thể sử dụng dịch vụ là việc nhận các hoá đơn: chúng ta có thể dùng dịch vụ mạng để tạo ra một dịch vụ nhận hoá đơn. Các hoá đơn này sẽ được lưu trữ bởi dịch vụ cho đến khi hệ thống kế toán trên máy PC của người dùng kết nối đến nó để nhận hoá đơn về bằng cách sử dụng dịch vụ mạng. Các hoá đơn sau đó có thể cập nhận một cách tự động trên PC… Bằng cách này, bất kỳ tổ chức nào, không phụ thuộc vào quy mô lớn hay nhỏ, đều có thể nhận được lợi ích từ việc sử dụng kiến trúc hướng dịch vụ.

Một tổ chức có thể dùng nhiều cách khác nhau để tiếp nhận được kiến trúc hướng dịch vụ, tuỳ thuộc vào mục tiêu và các ràng buộc công nghệ thông tin.

Các mức độ thực hiện kiến trúc hướng dịch vụ

Mức độ 1: Cài đặt các dịch vụ riếng lẻ.

Mức độ này tạo ra các dịch vụ từ các nhiệm vụ có trong các ứng dụng mới hoặc các ứng dụng hiện có. Kiến trúc hướng dịch vụ đem lại khả năng thiết kế các ứng dụng và các hệ thống cung cấp dịch vụ cho các ứng dụng khác thông qua các giao diện được xuất bản. Cách tạo ra các ứng dụng này có thể đưa đến một mô hình lập trình manh hơn, linh hoạt hơn, giảm chi phí cả trong phát triển và bảo trì.

Mức độ 2: Tích hợp hướng dịch vụ các chức năng nghiệp vụ

Mức độ tiếp theo là tích hợp hướng dịch vụ. Bước này bao gồm việc tích hợp các dịch vụ từ nhiều ứng dụng khác nhau cả bên trong lẫn bên ngoài doanh nghiệp để phục vụ cho mục đích nghiệp vụ. Mức độ này cũng phảI hỗ trợ nhiều kiểu tích hợp, bao gồm:

Tích hợp ứng dụng: gồm cả sự phát triển các giao diện mới để thể hiện các ứng dụng hiện có.

Tích hợp thông tin: gồm cả dữ liệu doanh nghiệp và dữ liệu phòng ban.

Tích hợp thông tin : gồm tích hợp qua sự tích hợp, sắp xếp các ứng dụng và dịch vụ với nhiều giao diện.

Tích hợp hệ thống: gồm sự kết nối các hệ thống không đồng nhất, các hệ thống hiện có và tích hợp ứng dụng.

Mức độ 3: Chuyển đổi doanh nghiệp công nghệ thông tin có quy mô lớn.

Mức cài đặt SOA rộng hơn là một cài đặt được kiến trúc hoá cho phép tích hợp nhiều chức năng nghiệp vụ trogn toàn doanh nghiệp.

Mức dộ 4: Chuyển đổi nghiệp vụ theo yêu cầu.

Đây là mức độ cuối cùng trong phát triển theo kiến trúc hướng dịch vụ. Mức độ này là sự định hướng chiến lược hướng tới sự chuyển đổi rộng của các mô hình nghiệp vụ hiện có hoặc sự triển khai của các mô hình nghiệp vụ mới.

Các bước trong quy trình phát triển phần mềm theo định hướng dịch vụ

Hiện nay chưa có một quy trình cụ thể để phát triển các ứng dụng theo kiến trúc hướng dịch vụ, tuy nhiên, dựa trên thực tế, 12 bước sau đã được đưa ra nhằm tham khảo quyết định chuyển sang hướng dịch vụ.

Mười hai bước trong quy trình phát triển phần mềm theo kiến trúc hướng dịch vụ:

Hiểu nghiệp vụ.

Xác định phạm vi (miền) của vấn đề.

Hiểu tất cả ngữ nghĩa của ứng dụng trong miền đó.

Hiểu tất cả các dịch vụ hiện có trong miền.

Hiểu tất cả các nguồn và đích của thông tin có trong miền.

Hiểu tất cả các quy trình trong miền.

Xác định và phân loại tất cả các giao diện bên ngoài miền cần thiết cho việc xây dựng ứng dụng (các dịch vụ và thông tin).

Định nghĩa các dịch vụ mới và các ràng buộc thông tin của các ứng dụng dịch vụ đó.

Định nghĩa các dịch vụ mới, cũng như các dịch vụ và ràng buộc thông tin cho các quy trình này.

Lựa chọn tập công nghệ.

Triển khai công nghệ SOA.

Kiểm thử và đánh giá.

Bước 1: Hiểu các mục đích nghiệp vụ, và xác định thành công.

Đây là nhiệm vụ thu thập các yêu cầu cơ bản. Nó đòi hỏi phảI tiếp xúc với tài liệu, nhân sự và hệ thống để xác định thông tin cho phép việc tích hợp ứng dụng được xác định đúng để có thể phân tích, mô hình hoá và cải tiến. Chỉ sau khi thực hiện bước này thì thực thu tập giảI pháp thích hợp mới được ra đời.

Cần lưu ý rằng có cả lợi ích hữu hình và vô hình từ việc cài đặt bất kỳ loại công nghệ nào. Lợi ích hữu hình bao gồm việc tiết kiệm chi phí tức thì, như việc tự động hoá một hệ thống bán theo đơn đặt hàng thay cho việc bán hàng thủ công. Lợi ích vô hình thì khó nhận biết hơn, như sự thoả mãn của khách hàng dẫn tới việc tăng doanh số bán hàng, hoặc cộng tác chặt chẽ hơn tăng cường chất lượng và cho phép cac nhân công trao đổi thông tin tốt hơn.

Bước 2: Xác định miền vấn đề.

Phải xác định phạm vi của việc ứng dụng SOA trong một tổ chức. Hãy chia nhỏ tổ chức để áp dụng SOA thay vì áp dụng vào toàn bộ tổ chức. Cùng với thời gian, những thành công nhỏ sẽ dẫn tới các chiến lược thành công lớn hơn, phải thiết lập các đường ranh giới khi bắt đầu dự án có thể tiến hành xây dựng ứng dụng một cách trọng tâm hơn.

Bước 3: Hiểu tất cả các ngữ nghĩa ứng dụng trong miền vấn đề.

Chúng ta không thể giải quyết các vấn đề mà bản thân mình không hiểu rõ. Vì vậy, bước tiếp theo này là cực kỳ quan trọng để xác định tất cả các siêu dữ liệu ngữ nghĩa tồn tại trong miền ứng dụng nhằm giải quyết các vấn đề một cách hoàn hảo. Sự hiểu biết về ngữ nghĩa ứng dụng thiết lập cách thức và khuôn dạng trong đó ứng dụng tham khảo cac thuộc tính của quy trình nghiệp vụ. Ví dụ, cùng một số hiệu khách hàng nhưng trong một ứng dụng này có một giá trị và ý nghĩa hoàn toàn khác trong một ứng dụng khác. Việc hiểu ngữ nghĩa của ứng dụng đảm bảo rằng sẽ không có bất kỳ sự xung đột thông tin nào khi nó được tích hợp với các ứng dụng khác ở mức độ thông tin hoặc dịch vụ. Xác định ngữ nghĩa của ứng dụng là một công việc khó khăn vì có thể nhiều hệ thống mà chúng ta đang phân tích đã cũ hoặc mang tính độc quyền. Bước đầu tiên trong việc xác định và định vị ngữ nghĩa là tạo ra một danh sách các hệ thống ứng viên. Danh sách này sẽ cho phép chúng ta có thể xác định những kho chứa dữ liệu nào tồn tại trong các hệ thống đó. Bất kỳ công nghệ nào có thể xây dựng lại các lược đồ dữ liệu vật lý và logic cũng sẽ có ích trong việc xác định dữ liệu trong các miền vấn đề. Tuy nhiên, trong khi lược đồ và mô hình dữ liệu có thể cho phép nhìn vào cấu trúc của cơ sở dữ liệu thì chúng lại không thể xác định những thông tin đó được sử dụng như thế nào trong ngữ cảnh của dịch vụ hoặc ứng dụng; đó là lý do chúng ta cần tới các bước tiếp theo, Bằng việc hiểu rõ các ngữ nghĩa của ứng dụng, và đảm bảo rằng tất cả các hệ thống nguồn và đích trong và giữa các tổ chức được tích hợp một cách hoàn hảo.

Bước 4: Hiểu tất cả các dịch vụ hiện có trong miền.

Tìm hiểu các thông tin về dịch vụ, bao gồm:

1. Vị trí của dịch vụ.
2. Mục đích của dịch vụ.
3. Thông tin ràng buộc của dịch vụ.
4. Các phụ thuộc (nếu đó là một dịch vụ phức hợp).
5. Các vấn đề bảo mật.

Vị trí tốt nhất để bắt đầu tìm hiểu là thư mục dịch vụ. Giống như các thư mục khác, đây là một kho chứa các thông tin được thu nhập về các dịch vụ hiện có, cùng với các tài liệu về mỗi dịch vụ, bao gồm mục đích của dịch vụ, các thông tin vào/ra.. Thư mục này được sử dụng cùng với những hiểu biết về ngữ nghĩa của ứng dụng để xác định các điểm tích hợp trong tất cả các hệ thống của miền vấn đề.

Bước 5: Hiểu tất cả các nguồn và đích thông tin hiện có trong miền vấn đề.

Bước này xác định các giao diện xử lý các thông tin đơn giản. Chúng có thể thực hiện một trong hai vai trò: sử dụng thông tin (đích) hoặc cung cấp thông tin ( nguồn).

Chúng ta cần phải hiểu rõ khía cạnh sau:

Vị trí của chúng.

Cấu trúc của luồng thông tin vào/ra.

Các ràng buộc tích hợp.

Các phụ thuộc (các nguồn và đích khác, cũng có thể là các dịch vụ).

Các vấn đề bảo mật.

Bước 6: Hiểu tất cả các quy trình.

Chúng ta cần xác định và liệt kê tất cả các quy trình nghiệp vụ tồn tại trong miền vấn đề, có thể là tự động hoá hoặc không phải là tự động hoá. Việc này rất quan trọng vì chúng ta đã biết dịch các dịch vụ và nguồn/đích thông nào hiện có, chúng ta cần xác định các cơ chế tương tác cao hơn, bao gồm tất cả các quy trình ở mức độ cao, mức trung bình và mức thấp. Trong nhiều trường hợp, những quy trình này vẫn chưa được tự động hoá hoặc chỉ có một phần được tự động hóa. Ví dụ, nếu một kiến trúc sư tích hợp ứng dụng cần hiểu tất cả các quy trình hiện có trong một ứng dụng kiểm kê, anh ta sẽ hoặc là đọc tài liệu hoặc là đọc mã nguồn để xác định quy trình nào đang được thực hiện. Sau đó, anh ta sẽ đưa quy trình nghiệp vụ vào phân loại và xác định mục đích của quy trình, ai là người sở hữu nó, nó chính xác là gì, và công nghệ thực hiện nó (Java hoặc C++...). Những quy trình này sau đó được gán với các quy trình mới để đáp ứng được các yêu cầu nghiệp vụ. Chúng ta cần phải xem xét khái niệm quy trình chia sẻ và quy trình riêng. Một số quy trình là quy trình riêng, và do đó, chúng không chia sẻ với các thực thể bên ngoài( trong một số trường hợp, chúng thậm chí còn không chia sẻ với các phần khác của tôt chức). Các quy trình chia sẻ và quy trình riêng có thể tồn tại trong cùng một không gian quy trình với công nghệ tích hợp quy trình quản lý bảo mật giữa các người dùng.

Một số thông tin có thể được bảo trì trong phân loại, đó là thông tin bao gồm các biến được sử dụng trong các quy trình, các lược đồ đối tượng, các yêu cầu bảo mật, và/ hoặc các đặc điểm hiệu suất. Mỗi phân lịa quy trình phải duy trì tập thuộc tính riêng của nó, được xây dựng tuỳ biến cho mỗi yêu cầu tích hợp ứng dụng cụ thể.

Bước 7: Xác định và phân loại tất cả các giao diện bên ngoài miền cần thiết cho việc xây dựng ứng dụng.

Chúng ta cần xác định tất cả các giao diện bên ngoài mà các hệ thống trong miền của vẩn đề của chúng ta có tương tác với hoặc cần tương tác với để đem lại giá trị tối đa. Điều quan trọng ở đây là phải chắc chắn rằng tất cả các giao diện cần thiết đều được xác định, bao gồm khả năng thể hiện các dịch vụ của miền đề ra bên ngoài cho các đối tác, cũng như khả năng nhận biết và thúc đẩy dịch vụ của họ. Các hệ thống của đối tác và của chúng ta cần hoạt động cùng nhau để hỗ trợ các quy trình chia sẻ chung.

Bước 8: Xác định các dịch vụ mới, các dịch vụ phức hợp và thông tin buộc đối với các dịch vụ đó.

Chúng ta cần xác định tất cả các dịch vụ tạo thành SOA; những dịch vụ này được chia làm 3 loại/

Bước 9: Xác định các quy trình mới, cũng như các dịch vụ và thông tin ràng buộc với các quy trình đó.

Đến bước này, chúng ta cần hiểu phần lớn những thành phần cần thiết để xác định các quy trình mới cũng như liên kết chúng với các quy trình hiện có tự động hoá các quy trình mà trước chưa được tự động hoá.

Bước 10: Lựa chọn tập công nghệ.

Có rất nhiều các công nghệ để lựa chọn, gồm các máy chủ ứng dụng, các đối tượng phân tán, và các máy chủ tích hợp. Sự lựa chọn công nghệ sẽ giống như một sự tổng hợp các sản phẩm và các nhà cung cấp để đáp ứng yêu cầu cho SOA. Rất hiếm có trường hợp một nhà cung cấp duy nhất có khả năng giải quyết được vấn đề.

Lựa chọn công nghệ là một công việc khó khăn yêu cầu một lượng thời gian và công sức đáng kể. Việc tạo ra tiêu chuẩn cho công nghệ và sản phẩm, việc hiểu rõ ràng các giải pháp được đưa ra, và sau đó nối các tiêu chuẩn với các sản phẩm đó là một công việc không dễ dàng. Đê thành công, việc kết nối tiêu chuẩn với sản phẩm thường đòi hỏi một dự án thử nghiệm để chứng minh rằng nó sẽ hoạt động. Thời gian cần thiết để lựa chọn các công nghệ phù hợp có thể dài bằng thời gian phát triển SOA, nhưng nếu nản chí, có thể dẫn tới việc lựa chọn các công nghệ không phù hợp dẫn đến phá hỏng hệ thống.

Bước 11: Triển khai công nghệ SOA.

Đến bước này, chúng ta đã hiểu tất cả những gì cần thiết phải hiểu, đã xác định được các dịch vụ và quy trình mới, đã lựa chọn được tập công nghệ thích hợp, và bây giờ là thời gian để xây dựng hệ thống.

Bước 12: Kiểm thử và đánh giá.

Để đảm bảo cho việc kiểm thử cần xây dựng kế hoạch kiểm thử.

Cần phải hiểu rằng 12 bước trên không phải là quy trình bắt buộc xây dựng một dự án SOA thành công. Trong một số trường hợp, chúng ta cần thêm vào hoặc loại bỏ đi một số bước để phù hợp vói yêu cầu cụ thể.

Kiến trúc hướng dịch vụ được đưa ra nhằm loại bỏ sự trùng lặp và dư thừa qua việc tái sử dụng và tích hợp. Cách đơn giản nhất là để bắt đầu vói SOA là thử với một dịch vụ mà chúng ta biết rằng có nhiều cài đặt trong nhiều ứng dụng khác nhau, sau đó bắt đầu xây dựng kế hoạch và chiến lược để loại bỏ các dịch vụ dư thừa. Quy trình cài đặt này sẽ giúp chúng ta đáp ứng được các yêu cầu cơ bản của tổ chức ẩn sau bước chuyển đổi thành công sang SOA. Khi chúng ta đã thực hiện được quy trình này, chúng ta sẽ có các công cụ và hiểu biết để mở rộng quy mô áp dụng SOA trong tổ chức của mình.

Vòng đời phát triển của dịch vụ

Việc đảm bảo rằng chỉ có các dịch vụ nghiệp vụ chuẩn hoá và có mức trừu tượng cao trong xây dựng và triển khai là mối quan tâm chính trong việc xây dựng các dịch vụ trong kiến trúc hướng dịch vụ. Chỉ với việc tập trung chú ý vào quy trình xác định dịch vụ mới đảm bảo việc cài đặt SOA trở lên hiên hiệu quả như mong đợi.

Dưới đây là một vòng đời phát triển và định nghĩa dịch vụ cho phép tiến hành thực hiện việc xem xét và các điểm kiểm tra từ sớm trong quy trình định nghĩa dịch vụ. Điều này sẽ giúp loại bỏ lỗi trước khi chúng làm cho chi phí khắc phục lỗi tăng vọt khi dịch vụ được tiến hành phát triển và triển khai.

Vòng đời phát triển dịch vụ.

Hình trên mô tả vòng đời phát triển dịch vụ, mỗi trạng thái được định nghĩa như sau:

Khởi tạo: một dịch vụ tiềm năng được xác định từ việc phân tích các yêu cầu của doanh nghiệp từ trên xuống (top – down) và việc mô hình hoá quy trình nghiệp vụ.

Thu nhận: đội ngũ kiến trúc dịch vụ thông báo là đã nhận được yêu cầu dịch vụ và bắt đầu đánh giá nó.

Chứng nhận: đội ngũ kiến trúc dịch vụ đã đánh giá dịch vụ và thống nhất giao diện chức năng của nó.

Phân loại: dịch vụ được xác định và được chuyển giao cho đội phát triển.

Cài đặt: đội ngũ phát triển dịch vụ cài đặt dịch vụ theo các quy tắc và hướng dẫn phát triển được định nghĩa bởi framework.

Kiểm thử: đội ngũ kiểm thử dịch vụ kiểm chứng tính năng cũng như các đặc tính chất lượng của dịch vụ.

Xuất bản: dịch vụ được xuất bản để có thể được sử dụng bởi các dịch vụ khác hoặc các ứng dụng định hướng quy trình.