Chuẩn bị đưa lên Hệ thống PureApplication của IBM, Phần 2: Ứng dụng của bạn đã sẵn sàng để trở thành ảo chưa? Những lợi thế và những hạn chế của các ứng dụng ảo Một ứng dụng ảo là một cách triển khai một ứng dụng JEE cùng với một bộ các quyết định chính sách để xác định cách ứng dụng co giãn quy mô và sử dụng các tài nguyên của máy ảo Java (Java™ Virtual Machine - JVM) như thế nào. Khi bạn triển khai một ứng dụng như là một ứng dụng ảo, bạn cũng tận dụng lợi thế của một bộ các dịch vụ chia sẻ dựng sẵn để xử lý các chi tiết của các vấn đề, ví dụ như việc cân bằng tải và quản lý HttpSession. Tuy nhiên, những lợi ích tự động hóa đó có kèm một giá phải trả. Cấu trúc liên kết của ứng dụng của bạn (ví dụ, có bao nhiêu máy chủ ứng dụng đang chạy cùng một lúc, máy chủ nào xử lý kiểu yêu cầu nào và v.v ) được Hệ thống PureApplication chủ động quản lý. Ví dụ, điều này có nghĩa là, bạn không thể chia tách ứng dụng của mình thành một tầng Web đang chạy các servlet và một tầng EJB đang chạy các EJB từ xa. Đối với nhiều ứng dụng, điều này không phải là một vấn đề, nhưng đối với các ứng dụng cũ hơn hoặc đã dựa vào việc đóng gói nhiều tầng hoặc dựa vào các đặc tính của một cấu trúc liên kết ứng dụng đặc thù, thì điều này có thể thành vấn đề. Một phần khác của cái giá phải trả là chỉ có một số mô hình lập trình nhất định nào đó được hỗ trợ. Đối với những ứng dụng nào đòi hỏi tính linh hoạt nhiều hơn, Hệ thống PureApplication cũng hỗ trợ các hệ thống ảo. Về đầu trang Những lợi thế và những hạn chế của các hệ thống ảo Một hệ thống ảo là một cơ chế tạo ra một khuôn mẫu hoặc một mẫu của toàn bộ cấu trúc liên kết được xây dựng từ các ảnh ảo. Bạn có thể sử dụng các ảnh của IBM-provided Hypervisor Edition (Ấn bản Siêu giám sát do IBM cung cấp) trong lúc xây dựng các hệ thống ảo của bạn, hoặc bạn có thể xây dựng các ảnh riêng của mình bắt đầu từ một ảnh RHEL cơ sở bằng cách sử dụng công cụ IBM Tivoli® ICON. Một khả năng khác là tính năng "Bắt giữ và Mở rộng" (Capture and Extend) của Hệ thống PureApplication, cho phép bạn bắt đầu với một ảnh ảo và thêm phần mềm bổ sung vào ảnh đó trước khi đóng gói lại để sử dụng sau này. Một lý do quan trọng khác trong việc xây dựng các hệ thống ảo là bạn có thể thêm các kịch bản lệnh riêng của bạn vào hệ thống ảo. Nếu bạn muốn triển khai một ứng dụng vào một mẫu cấu trúc liên kết mà bạn đã tạo ra, bạn sẽ cần tạo kịch bản lệnh cho việc triển khai đó để nó xảy ra như là một phần của quá trình khởi tạo cá thể trong triển khai một cá thể của hệ thống ảo vào phần cứng của Hệ thống PureApplication. Về đầu trang Chọn cách tiếp cận đúng Trong hầu hết trường hợp, việc chuyển một ứng dụng lên Hệ thống PureApplication thực sự không phải là một quá trình phức tạp. Tuy nhiên, điều mấu chốt để thực hiện quá trình di trú của bạn là hiểu rằng bạn cần chọn chính xác một cách tiếp cận đúng để đưa ứng dụng của bạn lên hệ thống. Hệ thống PureApplication hỗ trợ một số cách khác nhau để có thể triển khai ứng dụng của bạn. Lựa chọn một cách sao cho dẫn đến lượng công việc ít nhất với lợi ích lớn nhất là quyết định quan trọng nhất mà bạn có thể đưa ra trong quá trình di trú. Điều chúng ta đã thấy trong khi đưa lên một số ứng dụng ISV hiện có là cách đơn giản nhất để bắt đầu việc này là chỉ cần hỏi một loạt các câu hỏi sau: 1. Bạn đang xây dựng một ứng dụng mới phải không? Lý do tại sao bạn cần đề cập đến câu hỏi này trước tiên rất đơn giản – bạn muốn tận dụng lợi thế của cơ chế triển khai đơn giản nhất và dễ dàng nhất. Như bạn đã thấy ở trên, mô hình triển khai đơn giản nhất do Hệ thống PureApplication cung cấp là ứng dụng ảo. Nếu bạn đang xây dựng một ứng dụng mới và có cơ hội tác động đến các lựa chọn công nghệ và thiết kế được thực hiện trong ứng dụng, thì hãy chọn những công nghệ và thiết kế nào làm cho một ứng dụng tương thích với một ứng dụng ảo. Tuy nhiên, trong hầu hết các trường hợp, ứng dụng mà bạn đang xử lý hàng ngày không phải là các ứng dụng làm mới từ đầu. Thay vào đó, bạn xử lý các ứng dụng hiện có, đã được xây dựng và vẫn đang chạy trong một môi trường hiện có. Rồi bạn phải xem xét câu hỏi tiếp theo. 2. Đây có phải là một ứng dụng Web không? Đó là một câu hỏi có vẻ bề ngoài đơn giản đánh lừa. Điều chúng ta thực sự nghĩ đến khi hỏi câu này là, "Có phải ứng dụng này chỉ nhận các yêu cầu HTTP hoặc HTTPS (http an toàn) gửi đến không?" Định nghĩa này kết hợp một số mẫu khác nhau trong việc phát triển ứng dụng. Định nghĩa này có thể muốn nói tới bất cứ mẫu ứng dụng nào sau đây: o Một ứng dụng cung cấp các dịch vụ RESTful cho một giao diện người dùng được viết bằng các công nghệ Javascript và AJAX. o Một nhà cung cấp Các dịch vụ Web đang thực hiện các dịch vụ SOAP cho các máy khách bên ngoài trên Internet. o Một ứng dụng Web cổ điển được xây dựng bằng các servlet và các JSP. Tuy nhiên, định nghĩa này không bao gồm một số kiểu ứng dụng: ví dụ, ứng dụng khách- chủ Java, sử dụng máy khách Java phong phú (thick) kết nối thông qua RMI hay RMI/IIOP tới các EJB chạy ở mặt sau, không được coi là một ứng dụng web khi sử dụng định nghĩa này. Những suy xét này cũng đưa chúng ta đến câu hỏi tiếp theo. 3. Bạn có sử dụng các EJB từ xa không? Các EJB là một phần hữu ích của mô hình lập trình JEE hầu như ngay từ lúc khởi đầu của nó. Tuy nhiên, lợi ích của các EJB từ xa phải cân đối lại do phải đánh đổi bằng độ phức tạp của cấu trúc liên kết ứng dụng của bạn. Các máy chủ ứng dụng của bạn phải xử lý cả hai, lưu lượng HTTP gửi đến các servlet, các JSP, các dịch vụ Web của bạn, cũng như cả lưu lượng RMI/IIOP gửi đến từ các máy khách EJB. Thông thường, điều này được thực hiện thông qua việc xây dựng hai tầng máy chủ ứng dụng; một tầng được dành riêng để xử lý lưu lượng HTTP và một tầng khác được dành riêng để xử lý lưu lượng RMI. Như là một phần của quá trình đơn giản hóa, sử dụng các ứng dụng ảo, bạn phải từ bỏ một số các tùy chọn cấu trúc liên kết này. Vì vậy, như chúng ta đã thảo luận ở trên, nếu bạn cần các EJB từ xa, hãy bám chặt lựa chọn sử dụng các hệ thống ảo, ở đây có sẵn các tùy chọn cấu trúc liên kết này cho bạn sử dụng. 4. Ứng dụng của bạn có được đóng gói theo một cách tiêu chuẩn không? Một lần nữa, đây là một câu hỏi có vẻ bề ngoài đơn giản đánh lừa. Dùng thuật ngữ "theo một cách tiêu chuẩn", chúng ta muốn nói là ứng dụng có được đóng gói dưới dạng một tệp EAR, một tệp WAR, một tệp lưu trữ ZIP hoặc một EBA (OSGi Enterprise Bundle Archive - Lưu trữ gói doanh nghiệp OSGi) hay không? Bạn thấy, mặc dù tiêu chuẩn JEE là đóng gói các ứng dụng thành các tệp EAR hoặc WAR và tiêu chuẩn OSGi đã giới thiệu các kiểu lưu trữ EBA, nhưng nhiều ứng dụng vẫn không được đóng gói theo cách đó - thay vào đó, chúng được gửi đi dưới dạng cấu trúc thư mục "đã bung ra". Mặc dù cấu trúc đó có thể làm việc với các máy chủ đơn giản như Tomcat, việc thực hiện đóng gói theo cách không chuẩn làm rắc rối thêm cho bạn khi di chuyển đến các máy chủ JEE mới, ví dụ như các máy chủ hỗ trợ các ứng dụng ảo. Vì vậy, nếu câu trả lời của bạn là không, thì hãy đóng gói lại ứng dụng của bạn theo một trong các định dạng tiêu chuẩn này. Tương tự như vậy, có rất nhiều chiến lược đóng gói khác trong WebSphere® Application Server (Máy chủ ứng dụng WebSphere) mà có thể bạn muốn sử dụng; ví dụ, máy chủ đã liên kết với các thư viện chia sẻ. Một lần nữa, để đơn giản hóa mô hình, những cách đóng gói này không được sử dụng trong các ứng dụng ảo. Nếu bạn không thể tránh được việc sử dụng các cách tiếp cận này, thì hãy xem xét việc sử dụng các hệ thống ảo để thay thế. 5. Ứng dụng của bạn có đang sử dụng các mô hình lập trình JEE tiêu chuẩn không? Đã có một thành ngữ nói rằng "Một trong những điều thú vị về các tiêu chuẩn là có quá nhiều tiêu chuẩn để chọn." Thật không may, điều đó hoàn toàn đúng khi bạn đang nói về các mô hình lập trình. Các API mới được giới thiệu với một nhịp độ nhanh và qui trình của cộng đồng Java bị ngập chìm với các JSR tồn đọng, hoặc không bao giờ được phê duyệt hoặc không bao giờ đạt được sự chấp nhận rộng rãi đủ để chính thức trở thành một phần của tiêu chuẩn JEE. Một lần nữa, vấn đề là với các ứng dụng ảo, bạn cần giữ cho mọi thứ đơn giản. Vì thế, bạn phải hạn chế bộ các API được hỗ trợ ở mức có thể quản lý được. Do đó, nếu ứng dụng của bạn chỉ sử dụng các API tiêu chuẩn từ JEE5, J2EE1.4, 1.3 hoặc 1.2, OSGi, JPA, JAX-RPC, JAX-WS và JAX-RS, thì bạn sẽ yên tâm. Mặt khác, nếu bạn đang viết chương trình ở một mức JEE mới hơn (chẳng hạn như JEE 6) hoặc bạn đang sử dụng một số API khó hiểu từ sâu bên trong lòng của JCP, thì ứng dụng của bạn có thể sẽ không làm việc như một ứng dụng ảo. Tuy nhiên, cách tiếp cận của IBM là để cung cấp sự hỗ trợ cho các API mới hơn thông qua Các gói tính năng (Feature Packs). Vì vậy, nếu bạn đang lập kế hoạch cho một mức API mới, có thể bạn cần xem xét việc xây dựng một hệ thống ảo bằng cách sử dụng WebSphere Application Server V8 (Phiên bản V8 của Máy chủ ứng dụng WebSphere) và kết hợp Gói tính năng (và hỗ trợ cho API đó) khi nó trở nên có sẵn. 6. Ứng dụng này hiện có đang chạy được trên Phiên bản 7 hay Phiên bản 8 của WebSphere Application Server không? Đây là một câu hỏi mềm, nhưng là một câu hỏi quan trọng. Có một vài câu trả lời khác nhau cho câu hỏi này mà bạn cần xem xét. Thậm chí nếu câu trả lời của bạn cho câu hỏi này là "có", nhưng bạn rơi vào một trong các thể loại trước đây, đã đề cập khi nói về mô hình lập trình, đóng gói theo tiêu chuẩn hoặc sử dụng các EJB từ xa, thì quyết định của bạn đã được chọn rồi - ứng dụng của bạn không thể là một ứng dụng ảo. Tuy nhiên, nếu bạn trả lời "không", có thể bạn vẫn có khả năng chạy như một ứng dụng ảo. Nếu ứng dụng của bạn tuân thủ đúng như đã trả lời các câu hỏi về mô hình lập trình và về đóng gói ở trên, thì mọi thứ có thể vẫn còn tốt. Tuy nhiên, nếu ứng dụng của bạn đang chạy trên một phiên bản WebSphere Application Server cũ hơn nhiều hoặc trên một máy chủ ứng dụng khác, thì trước hết bạn có thể phải hoàn thành nỗ lực di trú trước khi bạn có thể di chuyển tới hoặc một ứng dụng ảo hoặc một hệ thống ảo. 7. Ứng dụng của bạn có yêu cầu bất kỳ các sản phẩm họ WebSphere nào như WebSphere Portal Server (Máy chủ cổng WebSphere) hoặc WebSphere Process Server (Máy chủ xử lý quy trình WebSphere) không? Như chúng ta đã mô tả ở trên, cách tiếp cận ứng dụng ảo là một cách tiếp cận được nhằm vào việc xây dựng các ứng dụng Web. Nếu kiểu ứng dụng của bạn (hoặc "tải làm việc" nếu bạn muốn sử dụng thuật ngữ đó) không phải là một ứng dụng Web, thì cách tiếp cận ứng dụng ảo hiện tại không phải là một cách tiếp cận đúng dành cho bạn. Lưu ý rằng đây là tuyên bố có tính thời điểm. Theo thời gian, các kiểu tải làm việc mới sẽ được thêm vào IBM Workload Deployer và Hệ thống PureApplication. Vì vậy, ở một số thời điểm, ngay cả khi bạn có một ứng dụng quản lý qui trình nghiệp vụ, bạn có thể tận dụng lợi thế của các mức tự động hóa cao hơn mà các ứng dụng ảo cung cấp cho các ứng dụng Web hiện nay. Tuy nhiên, vào lúc này, nếu bạn yêu cầu bất kỳ sản phẩm nào trong các sản phẩm này, bạn cần phải xây dựng một hệ thống ảo kết hợp các sản phẩm của Hypervisor Edition (Ấn bản Siêu giám sát) của IBM được phân phối như là một phần của danh mục trực tuyến cho Hệ thống PureApplication hoặc Workload Deployer của IBM. 8. Ứng dụng của bạn đã sẵn sàng để tận dụng lợi thế của việc quản lý phiên làm việc với WebSphere Extreme Scale (Mở rộng quy mô rất lớn của WebSphere) chưa? Cũng như với nhiều câu hỏi trước đó, có rất nhiều thứ được gói trong câu này. Về cơ bản, trước tiên bạn phải xem xét việc sử dụng API HttpSession của mình. Nhiều ứng dụng được viết theo một cách hoàn toàn không trạng thái và không hề dùng API HttpSession tí nào - những ứng dụng đó hoàn toàn phù hợp với các ứng dụng ảo. Mặt khác, nếu bạn hiện đang sử dụng HttpSessions trong ứng dụng của mình, thì bạn phải suy nghĩ một chút về cách bạn sử dụng chúng. Trước hết, có phải tất cả các nội dung HttpSession của bạn được khai báo là java.io.Serializable hay không? Nếu không, thì bạn có một vấn đề. Với các ứng dụng ảo, mô hình mà các chính sách mở rộng tuân theo là các cá thể máy chủ ứng dụng có thể được tạo ra động và bị phá hủy khi cần để xử lý tải làm việc mà ứng dụng đang thực hiện vào bất cứ lúc nào. Nếu bạn giả định rằng máy chủ của bạn tồn tại lâu dài và bộ nhớ của nó là một kho lưu trữ "an toàn" cho thông tin về phiên làm việc, thì bạn sẽ bị bất ngờ lúng túng nếu bạn cố gắng thực hiện một ứng dụng ảo. Tương tự như vậy, nếu các phiên làm việc của bạn rất lớn (hàng trăm MB), thì bạn có thể bị bất ngờ bởi thời gian cần thiết để tải một phiên làm việc qua mạng từ lưới WebSphere Extreme Scale. Mặt khác, nếu bạn có các phiên làm việc nhỏ, đã tuần tự hóa hóa hoàn toàn, tuân thủ các cách thực hành HttpSession tốt nhất, thì bạn có thể sử dụng các ứng dụng ảo. 9. Ứng dụng của bạn có sử dụng một sản phẩm bảo mật bên ngoài hay không hoặc nó có sử dụng các API bảo mật đặc biệt như các trình cắm thêm TAI (Trust Authentication Interceptors – Các trình chặn xác thực tin cậy) hoặc JAAS hay không? Cuối cùng, một trong những thứ cần xem xét là những yêu cầu bảo mật nào được đặt ra với ứng dụng của bạn. Nếu ứng dụng của bạn không có các yêu cầu bảo mật hoặc đơn giản chỉ sử dụng bảo mật WebSphere và nó cũng sử dụng một trong những đăng ký người dùng được hỗ trợ (TDS, Microsoft® Active Directory), thì bạn có thể triển khai thực hiện hệ thống của bạn như một ứng dụng ảo. Mặt khác, nếu bạn sử dụng một sản phẩm bảo mật riêng biệt như Tivoli Authentication Manager (Trình quản lý xác thực Tivoli) hoặc một trong những sản phẩm đối thủ của nó hoặc bất kỳ trong số các tính năng Bảo mật WebSphere đặc biệt nào như JAAS hoặc các TAI, thì bạn cần lập kế hoạch xây dựng một hệ thống ảo. Về đầu trang Chọn cách tiếp cận đúng ở đúng thời điểm Một điều quan trọng cần xem xét là các ứng dụng có các vòng đời, và một mô hình triển khai duy nhất không thể duy trì cho toàn bộ vòng đời của ứng dụng. Ví dụ, bạn có thể muốn triển khai một ứng dụng trong môi trường phát triển và thử nghiệm của mình như một ứng dụng ảo để có một mô hình đơn giản nhất và để chắc chắn rằng bạn bắt giữ chính xác các thông số cấu hình (như chính sách JVM) trong những môi trường đó. Tuy nhiên, bạn có thể muốn triển khai ứng dụng đó trong sản xuất như một hệ thống ảo để thiết lập môi trường tối ưu hóa cao nhất cho ứng dụng này. Tương tự như vậy, bạn có thể có một ứng dụng hiện có đã được triển khai như một hệ thống ảo hiện nay, nhưng trong các phiên bản mới nhất của ứng dụng, bạn có thể làm theo hướng thay đổi mã của nó để làm cho nó tương thích với việc triển khai như một ứng dụng ảo. Về đầu trang Lập kế hoạch cho tương lai Điều tốt nhất mà bạn có thể làm trong khi lập kế hoạch về ứng dụng của bạn đã hay chưa sẵn sàng thành các ứng dụng ảo chỉ đơn giản là mất thời gian để lập kế hoạch cho qui trình này. May mắn thay, IBM sẵn sàng giúp bạn trong suốt qui trình này. Quá trình PureExperience có một vài bước để khai triển tiếp các câu hỏi mà chúng ta đã đặt ra bằng cách hỏi thêm một số câu hỏi nữa đi vào từng lĩnh vực ấy. Thông qua quá trình hỏi và trả lời này, Chuyên gia kỹ thuật phía khách của IBM (IBM Client Technical Professional) có thể giúp bạn hiểu mô hình triển khai nào đáp ứng tốt nhất cho ứng dụng cụ thể của bạn. Tương tự như vậy, IBM Software Services for WebSphere (Các dịch vụ phần mềm với WebSphere của IBM) sẵn sàng trợ giúp với các dịch vụ di trú ứng dụng và các dịch vụ khác để giúp bạn chọn dùng Hệ thống PureApplication. Hãy liên hệ với đại diện bán hàng của IBM của bạn để được trợ giúp thêm và để bắt đầu! . Chuẩn bị đưa lên Hệ thống PureApplication của IBM, Phần 2: Ứng dụng của bạn đã sẵn sàng để trở thành ảo chưa? Những lợi thế và những hạn chế của. hiểu rằng bạn cần chọn chính xác một cách tiếp cận đúng để đưa ứng dụng của bạn lên hệ thống. Hệ thống PureApplication hỗ trợ một số cách khác nhau để có