Chuyển đổi RPG sang Java trên IBM iSeries

Question

Công ty chúng tôi sử dụng IBM iSeries cho phần lớn xử lý dữ liệu của chúng tôi. Tất cả các ứng dụng nội bộ của chúng tôi đều được viết bằng RPG. Theo lộ trình của IBM, IBM đang đẩy các công ty chuyển sang Java/J2EE. Chúng tôi đang tìm cách hiện đại hóa các ứng dụng nội bộ của mình cho một giao diện GUI hơn. Chúng tôi cung cấp sự hiện diện web bên ngoài bằng cách sử dụng các trang web Asp.Net, mặc dù có lẽ các dự án greenfield có thể là Java. Một lựa chọn là sử dụng một ứng dụng scraper màn hình trong khi ở trên RPG nhưng tôi nghĩ rằng nó có thể là tốt hơn để từ từ đi con đường của lộ trình của IBM và chuyển sang Java. Mục tiêu của chúng tôi là chuyển sang giao diện GUI và trở thành nội tuyến với lộ trình của IBM.

Bạn đã từng tham gia vào việc chuyển đổi RPG sang Java, ngay cả khi chỉ các dự án greenfield là Java và các dự án brownfield vẫn là RPG?

quản lý của tôi là sợ rằng:

1) cập nhật JRE trên máy trạm, khách hàng đặc biệt mỏng, có thể gây ra một cơn ác mộng hành chính (Công ty chúng tôi sử dụng 80% máy trạm mỏng và 20% máy tính) và

2) Java đòi hỏi quá nhiều chi phí của máy trạm để chạy hiệu quả

3) Sự không tương thích giữa các máy khách JRE khi chúng tôi cập nhật, có khả năng phá vỡ các ứng dụng khác yêu cầu JRE.

Bạn có thể làm sáng tỏ điều này không? Có lợi ích to lớn nào không? Bất kỳ gotchas lớn?

KIỂM TRA: Tôi chỉ quan tâm đến việc di chuyển sang Java. Mức độ khó khăn là gì và tôi có mất bất cứ thứ gì khi chuyển từ RPG sang Java không? Màn hình có đáp ứng rất nhanh khi di chuyển sang Java không?

Answer 1

Công ty của tôi cũng đang cố di chuyển sang Java từ RPG.

1. Chúng tôi không cố gắng sử dụng JRE trên máy khách mỏng, chúng tôi đang chuyển sang ứng dụng web được phân phối qua trình duyệt. Điều này có thể kéo theo (cuối cùng) thay thế các máy quét POS cũ của chúng tôi bằng một số máy quét dựa trên PC mới hơn.
2. Tôi đã được thông báo (bởi các kiến ​​trúc sư công ty) rằng JVM trên iSeries OS không có một số vấn đề về hiệu suất. Tôi không đích thân biết những hạn chế này là gì. Trong trường hợp của chúng tôi, việc di chuyển có liên quan đến việc phân bổ một tài nguyên AIX, được cho là tốt hơn nhiều - nói chuyện với đại diện của IBM về việc liệu bạn có cần mua giấy phép hệ điều hành hay không. phần cứng).
3. Xem phản hồi cho câu hỏi 1. Trong ngữ cảnh lớn hơn, nơi bạn đang cố cập nhật trình duyệt (hoặc bất kỳ tài nguyên nào khác), điều này thường được xử lý bằng giấy phép doanh nghiệp - hầu hết sẽ có tùy chọn cho phép cập nhật.

Một số lưu ý khác:

• Bạn sẽ có thể di chuyển để chỉ sử dụng .NET, mặc dù bạn có thể cần khác nhau phần cứng/phân vùng để chạy môi trường. Bạn có thể nói chuyện với DB2 theo cách đó, ít nhất. Java lợi ích duy nhất có là nó sẽ chạy trên cùng một hệ điều hành/phần cứng như cơ sở dữ liệu.
• Tôi đã nhìn thấy một ứng dụng màn hình ở đây (nó đã được trong VB.NET, nhưng tôi khá chắc chắn ví dụ áp dụng). Quét màn hình được thực hiện bằng cách lấy/đặt các ký tự vào các vị trí cụ thể trên màn hình (tương đương với substring()). Đó có thể chỉ là API mà chúng tôi đang sử dụng - tôi nghĩ tôi đã nghe về các giải pháp có thể đọc được tên trường. Tuy nhiên, nó cũng dựa vào dòng chảy chương trình RPG cho logic của nó, và nếu không thì không thể duy trì được.
• Hầu hết các chương trình RPG tôi đã xem và viết đều có xu hướng vi phạm MVC, nghĩa là bạn không thể làm gì hơn thử nghiệm tích hợp - lịch sử và kiến ​​trúc của chính ngôn ngữ đó (và một số nhà phát triển) thích mọi thứ (truy cập tập tin vào màn hình hiển thị) nằm trong một tập tin. Điều này cũng sẽ cố gắng để bọc RPG để gọi từ xa có hiệu quả không thể. NẾU bạn đã phân tách tất cả mọi thứ vào Chương trình Dịch vụ, bạn nên có thể gói chúng lên (tương đương với cuộc gọi phương thức gốc, gần như) gọn gàng - rất tiếc là tôi chưa thấy gì ở đây dựa vào một hoặc nhiều thủ thuật không lưu giữ cho việc sử dụng Web điển hình (ví dụ, sử dụng một tệp trong QTEMP để kiểm soát việc thực hiện chương trình - phiên trên iSeries sẽ biến mất một cách hiệu quả mỗi khi một trang mới được yêu cầu ...).
• Java là ngôn ngữ có xu hướng thúc đẩy phân tách mã tốt hơn (lưu ý rằng nó có thể bị lạm dụng một cách tồi tệ), vì nó không có lịch sử RPG. Nói chung, có thể hữu ích khi nghĩ Java là ngôn ngữ mà mọi thứ đều là chương trình dịch vụ, trong đó tất cả thông số được chuyển với VALUE, không được phép, CONST thường được đề xuất và hầu hết các tham số thuộc loại DS (datastructure - this là một loại khác biệt trong RPG) và được truyền xung quanh bằng con trỏ. Các tham số mức mô-đun được cau mày, nếu có lợi cho việc đóng gói mọi thứ trong cơ sở dữ liệu được thông qua hoặc các thủ tục của chương trình dịch vụ. STATIC có sử dụng phần nào khác nhau trong Java, làm cho biến toàn cầu, và không có sẵn bên trong các thủ tục.
• RPG khá đơn giản hơn Java, nói chung và lập trình OO là một mô hình hoàn toàn khác. Dưới đây là một số điều có khả năng chuyển lên các nhà phát triển di chuyển sang Java:
  1. Mảng trong RPG bắt đầu tại 1. Mảng trong Java bắt đầu tại 0.
  2. Java không có tham số 'ouput' và tất cả các kiểu nguyên thủy được truyền theo giá trị (được sao chép). Điều này có nghĩa là việc chỉnh sửa một số nguyên sẽ không hiển thị trong các phương thức gọi.
  3. Java không có mã hóa đóng gói/đã ký và do đó việc dịch sang/từ số/chuỗi có liên quan nhiều hơn. Kiểu ngày trong Java cũng có một số vấn đề nghiêm trọng (nó bao gồm thời gian, loại) và khó thay đổi có ý nghĩa hơn đến/từ biểu diễn ký tự. Khó khăn hơn để đọc/ghi các tập tin trong Java, ngay cả khi sử dụng SQL (và quên sử dụng I/O bản địa trực tiếp với Java) - tuy nhiên, điều này có thể được giảm thiểu một chút với một khung công tác tốt.
  4. Không có các toán tử ENDxx nào trong Java, mọi thứ sử dụng dấu ngoặc đơn ({}) để chỉ định bắt đầu/kết thúc của các khối.
  5. Mọi thứ trong Java đều ở dạng tự do, và không có thông số kỹ thuật của bất kỳ loại nào (mặc dù vẫn cần phải có chữ ký thủ tục). Không có khó khăn về độ dài dòng, mặc dù ~ 80 ký tự vẫn được khuyến khích. Các công cụ (miễn là miễn phí, thậm chí là tốt hơn, thời gian, và thường hữu ích hơn nhiều (mặc dù chúng có thể mất một số nhận được sử dụng cho những người tiếp xúc với SEU). Ngoài ra còn có các thư viện lớn, miễn phí có sẵn để tải xuống.
  6. Dấu hiệu = không phải là ngữ cảnh nhạy cảm trong Java theo cách nó trong RPG, nó là luôn luôn được sử dụng cho các bài tập. Sử dụng toán tử double-equals, == để so sánh các giá trị trong Java.
  7. Đối tượng (datastructures) không thể được so sánh một cách có ý nghĩa với == - bạn thường cần phải thực hiện một phương thức có tên là equals() thay thế.
  8. Chuỗi không thể thay đổi được, chúng không thể thay đổi. Tất cả các hoạt động được thực hiện trên các chuỗi (hoặc trên chính lớp/datastructure, hoặc từ các thư viện bên ngoài) trả về các tham chiếu mới. Và có, các chuỗi được xem là datastructures, không phải loại giá trị, do đó bạn không thể so sánh chúng với ==.
  9. Không có tích hợp tương đương với chỉ thị trước khi biên dịch /copy. Cố gắng triển khai chúng đang sử dụng Java không chính xác. Bởi vì chúng thường được sử dụng để đối phó với mã 'boilerplate' (định nghĩa biến hoặc mã thông thường), tốt hơn là xử lý điều này trong architecure. Biến (ALL D-specs, thực sự) definitons sẽ được xử lý với các câu lệnh import hoặc import static, trong khi các biến thể mã chung thường được xử lý bởi một khung công tác hoặc xác định một lớp mới.

Tôi chắc rằng có một số thứ khác ra khỏi đó, cho tôi biết nếu bạn có bất kỳ câu hỏi khác.

Answer 2

Khi IBM nói bạn nên chuyển sang Java/J2EE thì có lẽ bạn nên chuyển ứng dụng của mình sang các ứng dụng web như ứng dụng web asp.net của mình. Có lẽ bạn nên sử dụng một giao diện giàu tính năng như JSF hoặc GWT.

Các ứng dụng web không phải lo lắng về các vấn đề JRE vì bạn chỉ cần một trình duyệt chuẩn.

Tuy nhiên tôi không biết RPG và tôi không biết chiến lược di chuyển được đề xuất.

Answer 3

Việc phân phối và quản lý khách hàng chất béo sẽ là cơn ác mộng tuyệt đối.

Giải pháp lý tưởng là một ứng dụng web dựa trên Java được lưu trữ trên iSeries. Các máy trạm truy cập các ứng dụng của bạn thông qua một trình duyệt web giống như ASP.NET.

Tôi đã sử dụng Khung Grails để hiện đại hóa và tạo các ứng dụng mới và nó đang hoạt động tuyệt vời.

Answer 4

Tôi là một nhà phát triển tham gia vào hiện đại hóa as400. Cho đến nay, từ kinh nghiệm của tôi, tôi có thể cung cấp cho bạn những hiểu biết của tôi.

Ngoài các trang web dựa trên Java EE, bạn có thể sử dụng các dịch vụ web dựa trên jax-w, cung cấp dịch vụ cho các màn hình phẳng và lưới khác nhau.

Khách hàng có thể sử dụng chúng theo bất kỳ công nghệ nào họ mong muốn. Một số độ trễ là có, nhưng khả năng sử dụng tổng thể là tốt như trong các ứng dụng dựa trên web bình thường.