Viết mã thú vị với các API FileNet P8 của IBM, Phần 1 pps

Viết mã thú vị với các API FileNet P8 của IBM, Phần 1: Hello, Document! Bắt đầu với chương trình FileNet P8 đầu tiên của bạn Bill Carpenter, Kiến trúc sư phần mềm ECM, IBM Tóm tắt: Bài viết này giúp bạn khởi đầu bằng việc phát triển một ứng dụng đơn giản, HelloDocument, với FileNet® P8 Content API (API Nội dung FileNet P8) của IBM®. Thông qua một chuỗi các hoạt động đơn giản, hãy tìm hiểu cách sử dụng các mô hình mã hóa để thực hiện một loạt các hoạt động riêng của bạn. Các API P8 có thể mở rộng và để biết cách khởi đầu cần có một chút khéo léo với những người mới bắt đầu. Bài viết này cung cấp cho bạn sự khởi đầu đó: một định hướng và bệ phóng mà từ đó bạn có thể dễ dàng xây dựng các ứng dụng riêng của mình. Thậm chí nếu bạn đã quen với việc phát triển P8, chắc chắn bạn sẽ tìm thấy thông tin có ích trong bài viết này và các bài viết tiếp theo trong loạt bài này. Các bài viết trong sắp tới trong loạt bài này đi sâu hơn về các chủ đề cụ thể trong cả hai API quy trình và API nội dung. Hãy làm quen với HelloDocument Bộ e-kit (dụng cụ-điện tử) DB2 của IBM cho các người chuyên nghề cơ sở dữ liệu Tìm hiểu cách dễ dàng để được đào tạo và được cấp chứng chỉ với DB2 cho Linux, UNIX và Windows với bộ e-kit DB2 của IBM cho những người chuyên nghề cơ sở dữ liệu. Hãy đăng ký ngay bây giờ và mở rộng danh mục các kỹ năng của bạn hoặc mở rộng sự hỗ trợ của nhà cung cấp DBMS của bạn để bao gồm cả DB2. Bài viết này cung cấp cho bạn một tổng quan về một ứng dụng FileNet P8 của IBM đầy đủ, độc lập. P8 là một nền tảng của IBM về Quản lý nội dung doanh nghiệp (ECM-Enterprise Content Management). Mặc dù hầu hết các chương trình P8 trong thế giới thực là một phần của một khung công tác lớn hơn như J2EE hay .Net, là một nhà phát triển, nhiều khả năng điểm bắt đầu có thể của bạn là một chương trình độc lập. Bằng cách sử dụng một chương trình độc lập, bạn có thể tập trung vào các chi tiết P8 mà không cần phải tập trung vào sự phức tạp của khung công tác lớn hơn. Ứng dụng ví dụ HelloDocument thực hiện một số nhiệm vụ, một số trong đó bạn có thể không cần biết về nó, tuy nhiên, bạn có thể muốn làm một điều riêng biệt nào đó trong ứng dụng đó. Ngoài ra, bạn có thể sử dụng các kỹ thuật được minh họa trong mã này và mở rộng chúng để làm những việc phù hợp hơn với các trường hợp sử dụng của mình. Có lẽ cũng quan trọng không kém, một khi bạn có HelloDocument đang chạy, bạn có thể tự tin rằng môi trường của bạn được cấu hình đúng. Điều này cho phép bạn sau đó tập trung vào các chi tiết ứng dụng của mình mà không còn vương vấn nghi ngờ về môi trường của bạn nữa. Để hiểu bài viết này, bạn cần có một sự hiểu biết cơ bản về Java™ và có thể làm theo các mô tả của mã nguồn Java. Bài viết này không mô tả tất cả các dòng mã của HelloDocument.java mà, thay vào đó, đi vào những điểm nổi bật để minh họa các quan điểm API của Máy nội dung (CE-Content Engine). Mã này có rất nhiều chú thích và nếu bạn thích phiêu lưu, bạn có thể bỏ qua bài viết này và đi ngay vào chính mã nguồn của nó (xem phần Tài nguyên). HelloDocument được cấu trúc như một tệp nguồn Java duy nhất có 400-500 dòng. Thậm chí khi tính đến nhiều chú thích trong mã nguồn, vẫn còn rất nhiều dòng chỉ để làm quen. Có một số thứ trong HelloDocument.java mà bạn muốn di chuyển vào các lớp hoặc các tệp nguồn riêng biệt . Chúng được trình bày tất cả ở một chỗ duy nhất để cho bạn có thể chắc chắn là bạn có mọi thứ. Ví dụ, chuỗi đăng nhập Dịch vụ xác thực và ủy quyền Java (JAAS) đầy đủ, bao gồm một lớp bên trong xử lý các cuộc gọi lại, được bao gồm trong tệp nguồn HelloDocument.java. Điều đó chắc chắn sẽ là một sự lựa chọn khác thường với một ứng dụng thực tế. Lớp HelloDocument triển khai thực hiện giao diện PrivilegedAction và gói hầu hết logic nghiệp vụ của mình bên trong một phương thức chạy chỉ để dễ dàng minh họa mô hình đăng nhập JAAS rõ ràng. Logic nghiệp vụ cho HelloDocument hóa ra không quá 50 -100 dòng. Bài viết này được viết khi bản phát hành hiện tại trong lĩnh vực này đã là P8 4.0.1 và P8 4.5.0 đã đến cuối chu kỳ phát triển của nó. Mã này chạy được trong cả hai bản phát hành. (Bài viết này và các bài viết khác trong loạt bài này không dành nhiều thời gian cho các API từ P8 3.x. Trong một số trường hợp, các API này là hoàn toàn khác nhau). Vì các lớp API và các phương thức được dùng làm lõi cho các API, chúng rất ổn định. Nhiều khả năng là HelloDocument sẽ chạy mà không cần thay đổi gì trong một số chu kỳ phát hành P8 sắp tới. HelloDocument được viết bằng Java. Vì API của Content Java P8 khác với API của Content .Net P8 chủ yếu trong quy ước đặt tên và các lý do phụ khác, nên để viết lại HelloDocument bằng một ngôn ngữ .Net giống như C# sẽ chỉ là một việc chuyển chữ đơn giản. (Trong lĩnh vực xác thực có sự không giống nhau giữa hai API. Mặc dù bài viết này bàn về xác thực Java cho HelloDocument, nhưng việc thảo luận chung về xác thực nằm ngoài phạm vi của bài viết này.) Vậy thì, HelloDocument thực sự làm cái gì? Nó tạo ra một tài liệu, tải nội dung từ một tệp lên, kiểm tra tệp và đặt tệp đó trong một thư mục. Sau đó nó đọc lại tệp đó và so sánh nội dung được tải về với nội dung tệp gốc. Theo tùy chọn, bạn có thể cấu hình ứng dụng để bỏ qua một phần của tệp trong quá trình tải về và so sánh. Mặc dù việc tạo và lưu các tài liệu thành tệp là phổ biến cho nhiều trường hợp sử dụng, nhưng lại không có các bước so sánh. Trong thực tế, bạn chưa bao giờ phải kiểm tra nội dung mà bạn đã tải lên. Các phần bổ xung trong khi tải về chỉ có nghĩa minh họa một số khía cạnh viết mã API. HelloDocument được thiết kế để cho bạn không phải làm bất kỳ thiết lập cụ thể nào trong Máy nội dung (CE) trước khi bạn chạy nó (ngoài việc bảo đảm chắc chắn rằng bạn có các quyền truy cập để tạo các thư mục và các tài liệu mới). Một khi bạn có nó đang chạy trong môi trường của mình, bạn có thể chạy nó nhiều lần mà không bị lỗi. Cấu hình Cấu hình nhúng Một số các mục trong cấu hình điều khiển HelloDocument, chẳng hạn như URI (Uniform Resource Identifier-Trình nhận dạng tài nguyên thống nhất) của kết nối Máy nội dung (CE), là chung cho hầu hết các ứng dụng P8. Những mục khác là dành riêng cho ví dụ HelloDocument. Trong một ứng dụng thực tế, bạn sẽ gần như chắc chắn không mã hóa cứng các mục cấu hình này. Bạn sẽ sử dụng các đối số dòng lệnh, một tệp cấu hình hoặc một số cơ chế khác để tách cấu hình ra khỏi mã của chính ứng dụng. Để cho thuận tiện, HelloDocument định nghĩa tất cả các mục cấu hình đó như là các hằng số trong một lớp bên trong tĩnh tên là ConfigInfo, được hiển thị dưới dạng viết tắt trong Liệt kê 1. Ở đây bạn thấy các tham chiếu tới ConfigInfo.SOME_VALUE rải rác trong mã đó, chúng đang tham chiếu đến các hằng số này. Liệt kê 1. Lớp bên trong tĩnh ConfigInfo private static final class ConfigInfo { // . . . /** * This URI tells us how to find the CE and what protocol to use. */ static String CE_URI = "http://myCEserver:7001/wsi/FNCEWS40DIME"; /** * This ObjectStore must already exist. */ static String OBJECT_STORE_NAME = "MyObjectStore"; // . . . } Mỗi mục trong ConfigInfo có các chú thích giải thích cách sử dụng nó. Bạn nên xem xét từng mục và đặt nó tới một giá trị thích hợp cho môi trường của bạn. ConfigInfo Các mục cấu hình khác Vì đây là một bài viết về cách viết mã, nó không đi sâu vào nhiều chi tiết về cách thiết lập đường dẫn lớp Java và các mục cấu hình bên ngoài khác của bạn. Tài liệu về nền tảng P8 mô tả cách thiết lập một môi trường khách không rõ ràng. Nó là khác với mỗi nhánh của máy chủ ứng dụng J2EE. Phần tương tự của tài liệu đó cũng mô tả cách cấu hình các giá trị cài đặt JAAS của bạn. Các ví dụ và các hướng dẫn trong phần còn lại của bài viết này dựa trên điều kiện mọi giá trị ấy được cấu hình đúng. Nhận hay tìm nạp? Một đối tượng Java trong API không phải là thứ giống hệt như một đối tượng trong một kho lưu trữ CE. Nó chỉ đại diện cho một tham chiếu đến đối tượng CE qua đó bạn có thể kiểm tra các giá trị đặc tính, chuyển hướng bằng cách đi theo các đặc tính do đối tượng định giá (các OVP) và thực hiện nhiều kiểu cập nhật. Sự phối hợp thực sự giữa đối tượng API và đối tượng CE xảy ra khi API thực hiện một chuyến đi khứ hồi (truyền dữ liệu khứ hồi) đến máy chủ. Số các chuyến đi khứ hồi đến máy chủ nhiều lần là yếu tố chi phối hiệu năng của một ứng dụng, vì vậy API cung cấp việc kiểm soát chặt chẽ hơn khi các chuyến đi khứ hồi thực sự xảy ra và dữ liệu nào truyền trên dây cho mỗi chuyến đi khứ hồi ấy. HelloDocument khá cẩn thận về giảm thiểu các chuyến đi khứ hồi, nhưng nó đặc biệt không lưu ý về việc giảm thiểu số lượng dữ liệu liên quan đến các yêu cầu hoặc các đáp ứng. Bạn có thể điều chỉnh các kích cỡ tải đó thông qua các bộ lọc đặc tính và các cơ chế khác. Các bộ lọc đặc tính này được thảo luận chi tiết hơn trong một bài viết sắp tới của loạt bài này. Bây giờ, tất cả mọi thứ mà bạn thực sự cần biết là API được thiết kế để làm việc mà nếu bạn không sử dụng các bộ lọc đặc tính thì cũng chẳng có gì bất ngờ cả. Một khi bạn có được một sự hiểu biết cơ bản về API, chắc chắn bạn sẽ muốn sử dụng các bộ lọc đặc tính vì chúng có thể cải thiện đáng kể hiệu năng, cả hai vừa bằng cách giảm kích cỡ tải trọng và vừa bằng cách kết hợp một số chuyến đi khứ hồi. Khi bạn đang tạo một đối tượng Java, API có một quy ước có ích. Các tên của các phương thức factory (nhà máy) (và một số các kiểu phương thức khác) sử dụng tiền tố get (nhận) để biểu thị một hoạt động cục bộ và tiền tố fetch (tìm nạp) để biểu thị rằng một chuyến đi khứ hồi sẽ được thực hiện với máy chủ CE. (Cũng có một động từ thứ ba nữa: create (tạo) được sử dụng khi ý định của bạn không chỉ là tạo một đối tượng Java, mà còn là tạo một đối tượng CE mới trong một kho lưu trữ hoặc ở nơi nào đó khác). Trong biệt ngữ API, việc tạo một đối tượng Java mà không có một chuyến đi khứ hồi đến máy chủ được gọi là fetchless instantiation (tạo đối tượng không tìm nạp). Vì vậy, ví dụ, conn = Factory.Connection.getConnection(ConfigInfo.CE_URI) là cục bộ. Ở nhiều vị trí trong mã nguồn HelloDocument, một chú thích no R/T được sử dụng để nhấn mạnh đến việc tạo đối tượng không tìm nạp hoặc hoạt động khác mà một người nào đó có thể ngây thơ nghĩ rằng cần có một chuyến đi khứ hồi. Lưu ý rằng các phương thức get được sử dụng bất cứ nơi nào có thể. Một điều kỳ lạ có thể xảy ra khi bạn sử dụng việc tạo đối tượng không tìm nạp. API tin rằng các đối tượng CE mà bạn tham chiếu thực sự tồn tại. Nếu bạn thích nó, bạn có thể nói dối hoàn toàn với API biết, mặc dù điều này thường không có ích. Sự tính toán này chỉ cần đến khi một chuyến đi khứ hồi xảy ra liên quan đến đối tượng đó. Tại thời điểm đó, máy chủ CE chấp nhận một cách có phương thức các tham chiếu đối tượng của bạn với các đối tượng CE thực tế. Đương nhiên, việc tạo ra một đối tượng CE là một trường hợp đặc biệt được xử lý theo cách bạn mong đợi. Có một số trường hợp khác (nằm ngoài phạm vi của bài viết này), ở đó có thể có ích để tham chiếu các đối tượng CE không tồn tại; chúng đơn thuần phải tồn tại vào lúc CE nghe về chúng. Điểm mấu chốt là bạn có được một cải tiến hiệu năng bằng cách sử dụng việc tạo đối tượng không tìm nạp, nhưng các giá tương ứng phải trả là việc xử lý lỗi của ứng dụng của bạn có thể phải đối phó với việc thiếu các đối tượng ở giai đoạn sau. Trên thực tế, giá phải trả cho việc xử lý lỗi đó không quá nghiêm trọng. Bắt đầu ObjectStore Phương thức HelloDocument.run là nơi diễn ra logic nghiệp vụ chính từ trên xuống. Việc bắt đầu của phương thức này, cùng với biến cá thể cho một Connection (kết nối), minh họa một mô hình mã hóa rất phổ biến (xem Liệt kê 2). Không nghi ngờ gì, hầu hết các ứng dụng nội dung chỉ xử lý các đối tượng bên trong các kho lưu trữ CE và hầu hết trong số chúng chỉ xử lý một kho lưu trữ duy nhất. Liệt kê 2. HelloDocument.run và bạn bè /** * All interaction with the server will make use of this Connection object. * Connections are actually stateless, so you don't have to worry about * holding open some CE resource. * * no R/T */ private Connection conn = Factory.Connection.getConnection(ConfigInfo.CE_URI); // /** * This method contains the actual business logic. Authentication has * already happened by the time we get here. */ public Object run() { // Standard Connection -> Domain -> ObjectStore //no R/T Domain dom = Factory.Domain.getInstance(conn, null); //no R/T ObjectStore os = Factory.ObjectStore.getInstance(dom, ConfigInfo.OBJECT_STORE_NAME); String containmentName = createAndFileDocument(dom, os); File f = new File(ConfigInfo.LOCAL_FILE_NAME); long fileSize = f.length(); System.out.println("Local content size is " + fileSize + " for file " + ConfigInfo.LOCAL_FILE_NAME); long skipPoint = 0L; if (ConfigInfo.USE_SKIP) { long midPoint = fileSize / 2; // pick a random point in the second half of the content skipPoint = midPoint + (long)Math.floor((Math.random() * midPoint)); } System.out.println("Will skip to " + skipPoint + " of " + fileSize); readAndCompareContent(os, containmentName, skipPoint); [...]... thế của cách tiếp cận này là API của CE không cần mã hoá vào trong nó các phương thức khác nhau mà bạn có thể sử dụng để xác thực Với kiến trúc cắm được của JAAS, bạn có thể sử dụng các lược đồ mã định danh người dùng/mật khẩu truyền thống, các trình đọc dấu vân tay, các thiết bị xác thực cầm tay và nhiều kỹ thuật khác Bất kể bạn xác thực thế nào, mã ứng dụng CE API của bạn vẫn giữ nguyên Xác thực với. .. thực hiện xác thực của mình với một thùng chứa J2EE và để cho thùng chứa xử lý các chi tiết Kết luận Bài viết này dẫn bạn qua toàn bộ ứng dụng HelloDocument Bạn đã thấy cách kết nối với một ObjectStore, cách tạo ObjectStore, cách tạo Folder, Document và các kiểu đối tượng khác, cách đọc và thiết lập các giá trị đặc tính và cách tải lên và tải về nội dung Mặc dù những thứ này cùng với nhau vẫn chỉ tạo... bài viết này không nói nhiều hơn về các mục đích này) Ở bên trong, API sử dụng cùng một đối tượng Connection cho đối tượng Domain và các đối tượng được tạo từ nó Sau đó, khi chính ObjectStore được sử dụng để tạo các đối tượng, đối tượng Connection sẽ tự động được chuyển đi cùng với chúng trong các API Phần mã này cũng là một nơi thích hợp để lưu ý đến việc sử dụng các phương thức factory nói chung API. .. hằng số này với các giá trị tham số được mã hoá bằng một mô hình bảng liệt kê an toàn-kiểu Vì ban đầu API đã được viết cho một môi trường 1. 4 của Java và vẫn có thể hoạt động trong môi trường này, nên không có sẵn các enum (bảng liệt kê) của ngôn ngữ Java Các enum an toàn-kiểu bảo đảm an toàn-kiểu của chúng bằng cách buộc bạn sử dụng các hằng số từ một danh sách các lựa chọn thích hợp Ví dụ, trình biên... chuyến đi khứ hồi của CE? Trong trường hợp đó, đặc tính API của CE tìm kiếm một Subject của JAAS ở xung quanh Thuật ngữ ở xung quanh ở đây có nghĩa là một Subject đã được liên kết với luồng bằng các cơ chế JAAS chuẩn Ví dụ, trong một ứng dụng web bạn có thể tiến hành đăng nhập vào thùng chứa trang web J2EE Trong HelloDocument, việc đăng nhập được thực hiện một cách rõ ràng như là một phần của phương thức... di sản bị hạn chế theo một lược đồ xác thực bằng mã định danh người dùng/mật khẩu truyền thống Sử dụng phương thức UserContext.createSubject để tạo ra một cá thể của một Subject của JAAS Đối tượng UserContext cũng có thể duy trì một ngăn xếp của các Subject của JAAS, ở đó Subject ở đỉnh ngăn xếp thực sự được sử dụng cho các chuyến đi khứ hồi của CE Các phương thức UserContext.pushSubject và popSubject... với nhau vẫn chỉ tạo ra một ứng dụng khá đơn giản, nhưng chúng đưa vào các mô hình mã hóa có thể được dùng cho rất nhiều thứ Nếu bạn vừa mới bắt đầu viết mã P8, bạn có thể sử dụng HelloDocument như là một điểm khởi đầu Tệp mã nguồn hoàn chỉnh có sẵn để tải về thông qua một liên kết đi kèm với bài viết này Bạn có thể thử nghiệm bằng cách thay đổi nó để thử những điều khác nhau Trong thực tế, nếu bạn có... bởi vì cách làm này hầu như luôn không hiệu quả Một cách làm khác là bạn thực sự có thể thực hiện tìm nạp Folder và quay lại để tạo nó nếu nó chưa tồn tại Cách làm này vẫn đòi hỏi một chuyến đi khứ hồi để kiểm tra sự tồn tại của Folder (mà ứng dụng của bạn có thể biết nó tồn tại trong phần lớn thời gian) Vì vậy, có lẽ giải pháp tốt nhất, về mặt hiệu năng, là tạo Folder theo cách không tìm nạp với giả... ContentTransfer thích hợp Xác thực Phần này quay lại một đoạn trước đây của HelloDocument đã được che đi Mặc dù bài viết này không đi sâu vào chi tiết về xác thực, nhưng nó mô tả mã xác thực trong HelloDocument đang làm cái gì Trong mô hình CE, việc xác thực hoàn toàn được giao cho JAAS Điều đó có nghĩa rằng bạn không bao giờ thực sự đăng nhập vào API của CE hoặc CE Thay vào đó, API của CE trông đợi bạn đã thực... thời gian chạy Có một họ các phương thức khác, nhỏ hơn (không được sử dụng nhiều trong HelloDocument) đó là không an toàn-kiểu Trong biệt ngữ API, đây là các phương thức tiện nghi (commodity methods) Một ví dụ là phương thức ObjectStore.getObject, có thể trả về các đối tượng của hầu như bất kỳ lớp CE độc lập nào Ý định của phương thức tiện nghi là để sử dụng trong các mô hình mã hóa ứng dụng cụ thể xử . Viết mã thú vị với các API FileNet P8 của IBM, Phần 1: Hello, Document! Bắt đầu với chương trình FileNet P8 đầu tiên của bạn Bill Carpenter, Kiến trúc sư phần mềm ECM, IBM Tóm tắt: Bài viết. HelloDocument, với FileNet P8 Content API (API Nội dung FileNet P8) của IBM®. Thông qua một chuỗi các hoạt động đơn giản, hãy tìm hiểu cách sử dụng các mô hình mã hóa để thực hiện một loạt các hoạt. kỳ phát hành P8 sắp tới. HelloDocument được viết bằng Java. Vì API của Content Java P8 khác với API của Content .Net P8 chủ yếu trong quy ước đặt tên và các lý do phụ khác, nên để viết lại HelloDocument