Lợi ích của JCA là gì?

Question

Ứng dụng của chúng tôi thường kết nối với các nhà cung cấp dịch vụ web khác nhau, MQ, JDBC, độc quyền (trực tiếp trên socket) và các phương tiện giao thông khác. Chúng tôi đã có một số triển khai cho phép chúng tôi kết nối từ ứng dụng của chúng tôi đến các đầu cuối này và trong khi tất cả các triển khai này thực hiện giao diện java chung, chúng không chia sẻ bất kỳ thứ gì khác.

Chúng tôi đã nhận ra rằng có các phần biểu thị mã phổ biến cho tất cả các triển khai trình kết nối cụ thể này và chúng tôi đã quyết định hợp lý hóa việc phát triển các trình kết nối trong tương lai thông qua một trình kết nối phổ quát. Trình kết nối này sẽ có khả năng định dạng thông báo thành định dạng được mong đợi bằng cách sao lưu và gửi chúng bằng cách sử dụng cơ chế truyền tải có sẵn. Ví dụ: định dạng tin nhắn có độ dài cố định trên MQ hoặc trên ổ cắm.

Một trong những tình huống khó xử mà chúng ta đang đối mặt là công nghệ thích hợp nhất cho loại đầu nối này. Cho đến nay, các trình kết nối của chúng ta là các lớp java cơ bản thực hiện giao diện java thông dụng. Vì chúng ta thường lưu trữ các ứng dụng của chúng ta trong một số máy chủ ứng dụng Java EE, có vẻ như Kiến trúc kết nối Java sẽ là công nghệ thích hợp nhất cho phần mềm này. Tuy nhiên, việc triển khai trình kết nối tuân thủ JCA có vẻ tương đối phức tạp. Những lợi ích có thể sờ thấy của việc đi theo tiêu chuẩn - JCA và làm những lợi ích nào cho thấy nỗ lực bổ sung?

Answer 1

Thực tế, JCA dường như là công nghệ thích hợp nhất cho bạn. Đã có các đối số tuyệt vời đã được thực hiện, cụ thể là tính di động, giao diện chuẩn hóa, kết nối tổng hợp và hỗ trợ giao dịch. Và đừng quên bảo mật.

Với máy chủ WebSphere Process, bộ điều hợp có thể được hiển thị dưới dạng dịch vụ SCA có thể có nhiều lợi ích nếu điều đó quan trọng đối với bạn.

Một số công cụ phát triển cũng hỗ trợ rộng rãi cho việc phát triển và thử nghiệm các trình kết nối JCA.

Một lợi ích khác là (có kinh nghiệm) Quản trị viên Java EE và nhà phát triển Java EE (nên) biết tiêu chuẩn để quản trị và phát triển phải dễ dàng hợp lý hóa. Tuy nhiên, cuối cùng, bạn phải tìm lý do để thực hiện JCA dựa trên phạm vi dự án của bạn, các kế hoạch tương lai bạn có cho dự án của mình hoặc có thể trong chính sách của công ty bạn.

Answer 2

Âm thanh giống như sử dụng tốt cho hộp chứa JBI có các thành phần ràng buộc. Discussion của JCA vs JBI.

Answer 3

Tôi vừa phát triển bộ điều hợp tài nguyên trong nước cho thiết bị gps giao tiếp qua giao thức độc quyền. Nó không phải là rắc rối nhiều, mặc dù tôi đã có ấn tượng rằng việc phát triển một người đi ra có thể đòi hỏi nhiều công việc hơn. Điều tồi tệ nhất với JCA là thiếu tài liệu. Tất cả các sách và bài báo dường như có cùng một ví dụ câm.

Điều tôi hài lòng nhất là tính di động. Một khi bạn đã viết bộ điều hợp, bạn có thể cắm rar (kho lưu trữ bộ điều hợp tài nguyên) vào bất kỳ máy chủ ứng dụng nào để cung cấp các ứng dụng được triển khai khả năng giao tiếp với eis được hỗ trợ bởi việc bạn thực hiện. Hoặc bạn có thể bó rông vào chiến tranh/tai.

Answer 4

Lợi ích chủ yếu dành cho nhà cung cấp muốn bán kết nối với hệ thống đầu cuối độc quyền để sử dụng với bất kỳ máy chủ ứng dụng nào, cho khách hàng muốn có thể kết nối mà không lo lắng về việc nó chỉ hoạt động trên WebLogic không Websphere , vv Thực tế đây là mục tiêu của Java EE nói chung.

Lưu ý rằng JBoss đã quyết định đưa vài thứ vào JCA, ví dụ như kết nối JDBC đi qua JCA.

Mã khách hàng trong tương lai của bạn sẽ có giao diện được chuẩn hóa, hỗ trợ một số nhóm và hỗ trợ giao dịch, nhưng điều quan trọng là phải nhìn thấy bức tranh lớn hơn; cụ thể là các lợi ích không được nhắm vào bạn và một dự án cụ thể của bạn, nhưng tại một hệ thống sinh thái phần mềm bao gồm nhiều máy chủ ứng dụng, nhiều hệ thống đầu cuối, nhiều trình kết nối và nhiều thứ khác.

Answer 5

Câu trả lời ngắn: Tôi thấy không có lợi khi chọn JCA qua các công nghệ khác, tôi coi đó là một hạn chế vì bạn cần thùng chứa Java EE.

Câu trả lời dài:

Tôi đã hoài nghi về các tiêu chuẩn Java EE này một thời gian. Tôi không thấy lý do chính đáng nào của kỹ thuật để sử dụng máy chủ Java EE đầy đủ tính năng nữa vì có các triển khai mã nguồn mở tốt hơn cho mỗi tính năng được cung cấp. Tôi đã bị cắn nhiều lần bằng cách thực hiện không tương thích khi di chuyển đến/từ "giải pháp enterprisey".

Ý tưởng cho JCA đang hiển thị ở đây ngay bây giờ và tôi đang cố gắng thử apache camel hoặc spring integration thay thế. Tôi là tất cả cho việc triển khai mã nguồn mở mà bạn có thể sử dụng ở khắp mọi nơi. Và có rất nhiều thứ đang diễn ra. Kiểm tra this list of components. Cấp, có thể nhỏ hơn những gì đã được phát triển với JCA, nhưng mỗi bit đều có nguồn mở và tất cả đều ở một địa điểm. Ngoài ra, tôi tin rằng tài liệu đơn giản và đầy đủ hơn. Sự thôi thúc cho việc tích hợp các cuộc gọi cho một SPI mạnh mẽ với nhiều nguồn mở, ví dụ thực sự sống, được phát triển trong cùng một thời trang, và có thể được tìm thấy trên cùng một vị trí.

Tôi ghét tính tiêu cực, nhưng tôi không thích các máy chủ ứng dụng đầy đủ tính năng. Ví dụ, tôi sẽ đi cho tomcat và terracota bất kỳ ngày nào so với các sản phẩm "enterprisey" khác, giống như tôi sẽ đi với lạc đà trước JCA, cho đến khi nhu cầu JCA được chứng minh. Tôi không thích ý tưởng của Ủy ban Java để nói làm thế nào tôi nên phát triển các ứng dụng của riêng tôi bởi vì tôi không tin tưởng họ. Tôi tin rằng đó là lợi ích tốt nhất của tôi khi phần mềm có thể hoạt động dễ dàng trên Java SE/RCP như trong một môi trường Java EE hoặc trong một thùng chứa Servlet thuần túy.