Có hai phương pháp để thiết kế một hệ thống SOA là Top-down và Bottom-up Phương pháp Top-down: là phương pháp mà ddiem xuất phát của nó là từ các yêu cầu nghiệp vụ để xác định các yêu cầu chức năng các tiến trình và các tiến trình con, các trường hợp sử dụng (use cases) để tiến tới việc xác định các thành phần hệ
Bottom-up: dựa trên phân tích tình trạng các tài nguyên của hệ thống hiện có và sẽ tái sử dụng các tài nguyên này trong việc xây dựng các dịch vụ mới
1.3.1. Chu trình phát triển của SOA:
develop-->integrate-->orchestrate-->deploy-->manage-->secure-->access
1. Develop
Giai đoạn này ta tập trung phát triển các service và tạo web service Mô hình: webservice<=>myservice
- web service: để bên ngoài tương tác với service chúng ta - myservice: hiện thực service bằng Java class hoặc EJB
Trong quá trình hiện thực myservice thì có thể service của chúng ta cần giao tiếp với cơ sở dữ liệu. Bình thường thì chúng ta có thể tự mở CSDL và query sau đó đóng gói dữ liệu vào trong class Java. Điều này dễ dàng thực hiện trong các ứng dụng nhỏ.
Vì người làm database và ứng dụng rất gần với nhau, đôi khi chỉ là một. Nhưng với những vấn đề lớn, thì hầu như là người phát ứng dụng không biết hoặc biết rất ít về database. Do đó, chúng ta nên mapping giữa CSDL và đối tượng Java, khi bạn mapping xong thì bạn chỉ cần read hoặc write 1 đối tượng thì hệ thống runtime sẻ lo công việc query CSDL.
2. Integrate
Bạn có thể tích hợp component hoặc tích hợp rule.
Rule: nhằm để tách giữa ứng dụng và nghiệp vụ, do đó bạn có thể thay đổi nghiệp vụ 1 cách đễ dàng mà không cần phải code lại chương trình
3. Orchestrate
Đây là giai đoạn tích hợp các service. Khi bạn có qui trình nghiệp vụ thì bạn đưa ra được business workflow. Từ business workflow bạn phân tích ra các service. Bạn sẻ hiện thực hoặc sử dụng lại các service. Khi có đầy đủ các service thì chúng ta phải tích hợp lại. Công việc tích hợp này chúng ta dùng ngôn ngữ BPEL để tích hợp các service.
Bạn có thể sử dụng BPEL của IBM hoặc của Oracle. Với bộ design của BPEL chúng ta có thể tích hợp các service 1 cách nhanh chóng và dễ dàng.
Business process được tích hợp xong cũng được xem là một service và nó tương tác với bên ngoài thông qua web service. Và nó có thể được tích hợp bởi các business process khác.
4. Deploy
Khi các service đã được tạo xong. Bạn test nó cẩn thận và đạt rồi thì chúng ta tiến hành đóng gói các service và sau đó deploy nó lên server đích.
5. Manage và Secure
Đối với các hệ thống phát triển theo mô hình SOA thì hệ thống ngày càng phức tạp dần, và càng ngày có nhiều service hơn do đó thì yêu cầu quản lí và bảo mật các Web service được đặt ra. Hiện nay bạn có thể sử dụng Oracle Web service Manager cho công việc bảo mật này. Với bộ này chúng ta có thể đưa ra những chiến lược cho việc tổ chức và bảo mật một cách dễ dàng.
6. Access
Chúng ta bắt đầu truy xuất vào trong hệ thống.
1.3.2. Các kỹ thuật hỗ trợ SOA - Giao thức vận chuyển SOAP
- Định dạng WSDL
- Định dạng UDDI và ebXML - Kiến trúc service
1.3.3. Dịch vụ và các nguyên tắc thiết kế một dịch vụ
Service: là những ứng dụng mà mình muốn cho bên ngoài sử dụng.
Thí dụ: Chương trình chỉ có 1 class Java đơn giản như sau Class HelloWorld {
public HelloWorld() { super();
}
public String sayHello(String str) { Return “Hello, “ + str;
}
}
Khi người khác sử dụng chương trình của chúng ta và họ truyền vào 1 chuỗi str, thì chúng ta sẻ trả lại cho họ chuổi “Hello, “ + str.
Chuẩn để thiết kế có thể theo các bước sau:
1. Apply naming standards.
Vì một interface miêu tả cho bản chất của service nên cần phải có những nguyên tắt đặt tên cho nó:
+ Tên của service.
+ Tên của phương thức( operation).
+ Giá trị message (message value).
Thừơng thì sẽ đặt tên giống như cách đặt tên của hướng đối tượng(OO): Object thường là
danh từ, method thường là động từ.
Ví dụ: service Employee thì có các phương thức là: GetID, GetName.
2. Apply a suitable level of interface granularity.
Tính chất hạt của interface là thể hiện mức độ mịn hay thô (coarse-grained, finer- grained ). Mức độ mịn hay thô là phụ thuộc vào tính reuse của service. Cụ thể nếu một service ở tầng business process thì sẽ thô hơn những service ở tầng application
3. Design service operations to be inherently extensible
Bên cạnh tính reusability, composability thì trong suốt quá trình thiết kế phải đảm bảo được tính extensibility (tính có thể mở rộng được).
Một điều quan trọng nhất cho việc thiết kế những phương thức và những thông điệp là đảm bảo tính hoạt động độc lập cao nhất.
1. Identify known and potential service requestors.
Sẽ hữu ích và thực tế hơn nếu trong quá trình thiết kế ta đoán trước những tính năng sẽ phục vụ cho những yêu cầu mới trong tương lai, từ đó kết hợp với những yêu cầu hiện tại áp dụng cho việc thiết kế cho service của mình.
Điều này sẽ dẫn đến thêm vào môt số phương thức có thể không cần thiết cho những yêu cầu ở hiện tại so với phạm vi, ngân sách, hay những yêu cầu có liên quan. Vì vậy cũng phải sàng lọc lại để không ảnh hưởng nhiều đến project hiện tại.
5. Consider using modular WSDL documents
Sử dụng những file XSD schema để định nghĩa những kiểu dữ liệu phức tạp, từ đó ta có thể sử dụng cùng một file XSD schema cho nhiều file WSDL.
Khai báo import được sử dụng trong thẻ types của file WSDL để khai báo cho một file XSD schema hay một file WSDL khác.
(dữ liệu nên đặt trong file .xsd hay . wsdl)
6. Use namespaces carefully.
Chuẩn WS-I Basic Profile yêu cầu đặt thuộc tính targetNamespace để định ra một namespace cho một file WSDL hoặcmột file XSD schema được nhúng trong những file WSDL
7. Use the SOAP document and literal attribute values
Có hai thuộc tính quan trọng trong SOAP message là stype trong phần soap:binding và use trong phần soap:body. Nó liên quan đến dạng format và kiểu dữ liệu trình bày của SOAP message.
Thuộc tính stype có hai giá trị là “document ” và “rpc”.
Thuộc tính use có hai giá trị là “literal ” và “encoded”.
Người ta thường dùng kết hợp 3 thuộc tính như sau:
+ style:RPC + use:encoded + style:RPC + use:literal
+ style:document + use:encoded + style:document + use:literal
8. Use WS-I Profiles even if WS-I compliance isn't required
Giúp ích cho ta trong phần bảo mật các service thông qua gateway hoặc agent
9. Document services with metadata
Khi thiết kế một document cho server theo kiểu metadata nghĩa là khi có một request đến sẽ trả về cho requestor tất cả những thông tin của service provider.
Thông tin trả về bao gồm: file WSDL, file XSD schema, và địa chỉ của policies.
1.4. Vấn đề bảo mật trong SOA