Jini (/dʒ//iː//n//i/) – Apache River: Бөлінген жүйелер құруға арналған JavaSpaces негізіндегі желілік архитектура. Apache 2.0 лицензиясымен қолданылады.
Ағылшыншамен салыстырыңыз: абзацты басыңыз — түпнұсқа терезеде ашылады. Абзац астындағы EN түймесі оны мәтін ішінде көрсетеді.
Мазмұны
Кіріспе
Таратылған жүйелер үшін желілік архитектура, оңтүстік кореялық әнші
Network architecture for distributed systems
the South Korean singer
Jini ('/dʒ//iː//n//i/'), сондай-ақ Apache River деп аталады, модульдік, бірлесіп жұмыс істейтін қызметтер түрінде таратылған жүйелерді құруға арналған желілік архитектура. JavaSpaces – Jini құрамының бір бөлігі. Jini бастапқыда Sun Microsystems компаниясымен әзірленген және Apache License 2.0 лицензиясымен шығарылған. Jini жауапкершілігі "River" жобасы ретінде Apache-қа берілді.
Jini ('/dʒ//iː//n//i/), also called Apache River, is a network architecture for the construction of distributed systems in the form of modular co operating services. JavaSpaces is a part of the Jini. Originally developed by Sun Microsystems, Jini was released under the Apache License 2.0. Responsibility for Jini has been transferred to Apache under the project name "River".
Тарих
Sun Microsystems компаниясы Jini-ді 1998 жылдың шілдесінде таныстырды, бірақ ол әрқашан Jini ретінде танылды. "Джини" сөзі суахили тілінде "шайтан" деген мағынаны білдіреді; бұл сөз араб тіліндегі мифологиялық рухқа қатысты ұғымнан алынған, латын тіліндегі "genius" сөзінен туындаған, сонымен қатар ағылшын тіліндегі "genie" сөзінің де бастауы осы сөз. Jini сервистік объектіге бағытталған архитектураның (SOOA) инфрақұрылымын қамтамасыз етеді.
Sun Microsystems introduced Jini in July 1998. but it has always been just Jini. The word 'jini' means "the devil" in Swahili; this is borrowed from the Arabic word for a mythological spirit, originated from the Latin genius, which is also the origin of the English word 'genie'. Jini provides the infrastructure for the Service object oriented architecture (SOOA).
Қызметті пайдалану
Қызметтерді табу іздеу қызметі арқылы жүзеге асырылады. Қызметтер іздеу қызметімен (LUS) байланыс орнатуға тырысады, егер іздеу қызметінің нақты орнын білсе, біржолғы байланыс арқылы, немесе динамикалық көпжолғы іздеу арқылы. Іздеу қызметі қызмет тіркеушісі деп аталатын объектіні қайтарады, оны қызметтер өздерін тіркеу үшін пайдалана алады, соның арқасында клиенттер оларды таба алады. Клиенттер іздеу қызметін қызметке прокси-объектіні алу үшін пайдалана алады; проксиге жасалған шақырулар шақыруды қызмет сұранысына айналдырады, бұл сұранысты қызметте орындайды және нәтижені клиентке қайтарады. Бұл стратегия Java қашықтан әдіс шақырудан көбірек ыңғайлы, себебі ол клиенттен қашық қызметтің орнын алдын ала білуді талап етеді.
Locating services is done through a lookup service. Services try to contact a lookup service (LUS), either by unicast interaction, when it knows the actual location of the lookup service, or by dynamic multicast discovery. The lookup service returns an object called the service registrar that can be used by services to register themselves so they can be found by clients. Clients can use the lookup service to retrieve a proxy object to the service; calls to the proxy translate the call to a service request, performs this request on the service, and returns the result to the client. This strategy is more convenient than Java remote method invocation, which requires the client to know the location of the remote service in advance.
Шектеулер
Jini клиент пен қызмет арасындағы байланысты брокерлеу үшін іздеу қызметін пайдаланады. Бұл орталықтандырылған модель сияқты көрінеді (бірақ клиент пен қызмет арасындағы байланыс орталықтандырылмаған болып есептелуі мүмкін), ол өте ірі жүйелерде тиімді масштабталмайды. Дегенмен, іздеу қызметін бірнеше дананы (экземплярды) бірдей мультикаст тобын тыңдау арқылы көлденеңге қарай масштабтауға болады.
Jini uses a lookup service to broker communication between the client and service. This appears to be a centralized model (though the communication between client and service can be seen as decentralized) that does not scale well to very large systems. However, the lookup service can be horizontally scaled by running multiple instances that listen to the same multicast group.