जावा सर्वर के साथ जावा क्लाइंट को एकीकृत करने का सबसे आसान तरीका

जावा-आधारित डेस्कटॉप एप्लिकेशन के इंटरफेस के साथ रोजमर्रा के कार्यों को हल करते समय, आपको वैसे भी वेब सर्वर से अनुरोध करना होगा। J2EE और भयानक संक्षिप्त नाम RMI के दिनों के बाद, बहुत कुछ बदल गया है, और सर्वर कॉल अधिक हल्के हो गए हैं। वेब सॉकेट के मानक और किसी भी सामग्री के सरल पाठ संदेशों के आदान-प्रदान के लिए ऐसी समस्या के लिए उपयुक्त है। लेकिन उद्यम अनुप्रयोगों के साथ समस्या यह है कि विविधता और अनुरोधों की संख्या अलग-अलग चयनित व्यावसायिक सेवाओं के साथ एंडपॉइंट्स को बनाने और ट्रैक करने को एक भयानक दिनचर्या बनाती है और कोड की अतिरिक्त लाइनें जोड़ती है।

लेकिन क्या होगा यदि हम आधार के रूप में आरएमआई के साथ एक सख्ती से टाइप की गई रणनीति लेते हैं, जहां क्लाइंट और सर्वर के बीच एक मानक जावा इंटरफेस था जो विधियों, तर्कों और रिटर्न प्रकारों का वर्णन करता है, जहां कुछ एनोटेशन जोड़े गए थे, और क्लाइंट ने जादुई रूप से यह भी नोटिस नहीं किया था कि कॉल नेटवर्क पर किया जा रहा था; क्या होगा यदि न केवल पाठ, लेकिन क्रमबद्ध जावा ऑब्जेक्ट नेटवर्क पर प्रसारित किए जाते हैं? क्या होगा अगर हम इस रणनीति को वेब सॉकेट्स की आसानी और सर्वर से क्लाइंट पुश कॉल की संभावना के अपने फायदे जोड़ते हैं? क्या होगा यदि क्लाइंट के लिए वेब सॉकेट की अतुल्यकालिक प्रतिक्रिया को सामान्य अवरोधक कॉल में चिह्नित किया जाता है, और एक विलंबित कॉल के लिए, भविष्य या यहां तक ​​कि कंपेटिबलफ्यूज़न की वापसी की संभावना जोड़ते हैं? क्या होगा अगर हम सर्वर से विशिष्ट घटनाओं की सदस्यता लेने की क्षमता जोड़ते हैं? क्या होगा यदि सर्वर में प्रत्येक क्लाइंट के लिए एक सत्र और कनेक्शन हो? यह किसी भी जावा प्रोग्रामर से परिचित एक अच्छा पारदर्शी बंडल हो सकता है, क्योंकि जादू इंटरफ़ेस के पीछे छिपा होगा, और परीक्षण में इंटरफेस आसानी से बदला जा सकता है। लेकिन यह सिर्फ लोड किए गए अनुप्रयोगों के लिए नहीं है जो प्रक्रिया है, उदाहरण के लिए, स्टॉक मार्केट कोट्स।

मेरे अभ्यास से कॉर्पोरेट अनुप्रयोगों में, एक sql क्वेरी को निष्पादित करने और DBMS से चयनित डेटा को स्थानांतरित करने की गति क्रमबद्धता और चिंतनशील कॉल के ओवरहेड के साथ असंगत है। इसके अलावा, EJB कॉल का एक भयानक निशान, सबसे सरल अनुरोध के लिए भी निष्पादन समय 4-10 एमएस के पूरक है, एक समस्या नहीं है, क्योंकि ठेठ अनुरोधों की अवधि 50ms से 250ms तक गलियारे में है।

आइए सबसे सरल से शुरू करें - हम इंटरफ़ेस विधियों के पीछे जादू को लागू करने के लिए प्रॉक्सी ऑब्जेक्ट पैटर्न का उपयोग करेंगे। मान लीजिए कि मेरे पास अपने विरोधियों के साथ उपयोगकर्ता के पत्राचार का इतिहास प्राप्त करने का एक तरीका है:

public interface ServerChat{ Map<String, <List<String>> getHistory(Date when, String login); } 

हम मानक जावा टूल का उपयोग करके प्रॉक्सी ऑब्जेक्ट बनाएंगे और उस पर आवश्यक विधि को कॉल करेंगे:

 public class ClientProxyUtils { public static BiFunction<String, Class, RMIoverWebSocketProxyHandler> defaultFactory = RMIoverWebSocketProxyHandler::new; public static <T> T create(Class<T> clazz, String jndiName) { T f = (T) Proxy.newProxyInstance(clazz.getClassLoader(), new Class[]{clazz}, defaultFactory.apply(jndiName, clazz)); return f; } } //    //... ServerChat chat = ClientProxyUtils.create(ServerChat.class, "java:global/test_app/ServerChat"); Map<String, <List<String>> history = chat.getHistory(new Date(), "tester"); //... //    

यदि एक ही समय में आप कारखाने स्थापित करते हैं, और सीडीआई-इंजेक्शन के माध्यम से इंटरफ़ेस के माध्यम से प्रॉक्सी ऑब्जेक्ट इंस्टेंस को लागू करते हैं, तो आपको जादू अपने शुद्ध रूप में मिलेगा। एक ही समय में, हर बार एक सॉकेट खोलना / बंद करना आवश्यक नहीं है। इसके विपरीत, मेरे अनुप्रयोगों में सॉकेट लगातार खुला है और संदेशों को प्राप्त करने और संसाधित करने के लिए तैयार है। अब यह देखने लायक है कि RMIoverWebSocketProxyHandler में क्या होता है:

 public class RMIoverWebSocketProxyHandler implements InvocationHandler { public static final int OVERHEAD = 0x10000; public static final int CLIENT_INPUT_BUFFER_SIZE = 0x1000000;// 16mb public static final int SERVER_OUT_BUFFER_SIZE = CLIENT_INPUT_BUFFER_SIZE - OVERHEAD; String jndiName; Class interfaze; public RMIoverWebSocketProxyHandler(String jndiName, Class interfaze) { this.jndiName = jndiName; this.interfaze = interfaze; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Request request = new Request(); request.guid = UUID.randomUUID().toString(); request.jndiName = jndiName; request.methodName = method.getName(); request.args = args; request.argsType = method.getParameterTypes(); request.interfaze = interfaze; WaitList.putRequest(request, getRequestRunnable(request)); checkError(request, method); return request.result; } public static Runnable getRequestRunnable(Request request) throws IOException { final byte[] requestBytes = write(request); return () -> { try { sendByByteBuffer(requestBytes, ClientRMIHandler.clientSession); } catch (IOException ex) { WaitList.clean(); ClientRMIHandler.notifyErrorListeners(new RuntimeException(FATAL_ERROR_MESSAGE, ex)); } }; } public static byte[] write(Object object) throws IOException { try (ByteArrayOutputStream baos = new ByteArrayOutputStream(); ObjectOutputStream ous = new ObjectOutputStream(baos)) { ous.writeObject(object); return baos.toByteArray(); } } public static void sendByByteBuffer(byte[] responseBytes, Session wsSession) throws IOException { ... } public static void checkError(Request request, Method method) throws Throwable { ... } @FunctionalInterface public interface Callback<V> { V call() throws Throwable; } } 

और यहाँ वास्तविक ग्राहक स्वयं EndPoint है :

 @ClientEndpoint public class ClientRMIHandler { public static volatile Session clientSession; @OnOpen public void onOpen(Session session) { clientSession = session; } @OnMessage public void onMessage(ByteBuffer message, Session session) { try { final Object readInput = read(message); if (readInput instanceof Response) { standartResponse((Response) readInput); } } catch (IOException ex) { WaitList.clean(); notifyErrorListeners(new RuntimeException(FATAL_ERROR_MESSAGE, ex)); } } private void standartResponse(final Response response) throws RuntimeException { if (response.guid == null) { if (response.error != null) { notifyErrorListeners(response.error); return; } WaitList.clean(); final RuntimeException runtimeException = new RuntimeException(FATAL_ERROR_MESSAGE); notifyErrorListeners(runtimeException); throw runtimeException; } else { WaitList.processResponse(response); } } @OnClose public void onClose(Session session, CloseReason closeReason) { WaitList.clean(); } @OnError public void onError(Session session, Throwable error) { notifyErrorListeners(error); } private static Object read(ByteBuffer message) throws ClassNotFoundException, IOException { Object readObject; byte[] b = new byte[message.remaining()]; // don't use message.array() becouse it is optional message.get(b); try (ByteArrayInputStream bais = new ByteArrayInputStream(b); ObjectInputStream ois = new ObjectInputStream(bais)) { readObject = ois.readObject(); } return readObject; } } 

इस प्रकार, प्रॉक्सी ऑब्जेक्ट के किसी भी तरीके को कॉल करने के लिए, हम एक खुला सॉकेट सत्र लेते हैं, पारित तर्कों और उस विधि का विवरण भेजते हैं जिसे सर्वर पर कॉल किया जाना चाहिए, और अनुरोध में निर्दिष्ट गाइड के साथ प्रतिक्रिया प्राप्त होने तक प्रतीक्षा करें। प्रतिक्रिया प्राप्त होने पर, हम एक अपवाद की जाँच करते हैं, और यदि सब कुछ ठीक है, तो हम रिस्पांस के उत्तर को रिक्वेस्ट में डालते हैं और उस स्ट्रीम को सूचित करते हैं जो WaitList में प्रतिक्रिया का इंतजार कर रही है। मैं इस तरह के WaitList के कार्यान्वयन को नहीं दूंगा, क्योंकि यह तुच्छ है। प्रतीक्षा धागा, सबसे अच्छा, WaitList.putRequest (अनुरोध, getRequestRunnable (अनुरोध)) लाइन के बाद काम करना जारी रखेगा ; । जागने के बाद, थ्रेड्स अनुभाग में घोषित अपवादों की जांच करेगा, और परिणाम को रिटर्न के माध्यम से लौटाएगा ।

उपरोक्त कोड उदाहरण पुस्तकालय के कुछ अंश हैं, जो अभी तक गीथूब पर पोस्ट करने के लिए तैयार नहीं हैं। लाइसेंसिंग के मुद्दों पर काम करना आवश्यक है। इसके प्रकाशन के बाद पहले से ही स्रोत कोड में सर्वर साइड के कार्यान्वयन को देखने के लिए समझ में आता है। लेकिन वहाँ कुछ खास नहीं है - एक ejb ऑब्जेक्ट के लिए एक खोज की जाती है जो कि Precontext के माध्यम से jndi में निर्दिष्ट इंटरफ़ेस को लागू करती है और प्रेषित विवरण का उपयोग करके एक परावर्तक कॉल किया जाता है। वहां, ज़ाहिर है, अभी भी बहुत सारी दिलचस्प चीजें हैं, लेकिन इस तरह की जानकारी किसी भी लेख में फिट नहीं होगी। लाइब्रेरी में ही, उपरोक्त अवरोधक कॉल स्क्रिप्ट को सबसे पहले लागू किया गया था, क्योंकि यह सबसे सरल है। बाद में फ्यूचर और कंप्लीटटेबल सिवनी <> के माध्यम से नॉन-ब्लॉकिंग कॉल के लिए समर्थन जोड़ा गया। लाइब्रेरी जावा डेस्कटॉप क्लाइंट के साथ सभी उत्पादों में सफलतापूर्वक उपयोग किया जाता है। मुझे खुशी होगी कि अगर कोई ओपनिंग सोर्स कोड के अपने अनुभव को साझा करे जो कि gnu gpl 2.0 ( tyrus-standalone-client ) के साथ जुड़ा हुआ है।

परिणामस्वरूप, यूआई फॉर्म में ही मानक आईडीई टूल का उपयोग करके विधि मंगलाचरण का एक पदानुक्रम बनाना मुश्किल नहीं है, जिस पर बटन हैंडलर दूरस्थ सेवाओं को खींचता है। उसी समय, हमें क्लाइंट और सर्वर एकीकरण परत की सख्त टाइपिंग और कमजोर कनेक्टिविटी मिलती है। एप्लिकेशन सोर्स कोड की संरचना क्लाइंट, सर्वर और कर्नेल में विभाजित होती है, जो क्लाइंट और सर्वर दोनों के लिए लत द्वारा जुड़ा होता है। यह उस में है कि सभी दूरस्थ इंटरफेस और स्थानांतरित ऑब्जेक्ट स्थित हैं। और डेटाबेस में क्वेरी के साथ जुड़े डेवलपर की दिनचर्या को इंटरफ़ेस में एक नई विधि और सर्वर पर इसके कार्यान्वयन की आवश्यकता होती है। मेरी राय में, बहुत आसान ...