인하대학교 소프트웨어 공학
연구실에서는 신입 대학원생
과 예비 대학원생을 모집
합니다. 연구실 지원을
희망하는 학생은 하이테크관
1407호 로 방문 또는
아래의 연락처로
연락 주시기 바랍니다.
TEL: (032) 860-7454
Email: inhaselab@gmail.com
Software Engineering Laboratory.
Computer Networking - Middleware (Transport Layer)
Researchers: Tae Young Kim (18th semester), Jae Kwon Kim (9th semester)
Related Published List:
1. Taeyoung Kim, Youngshin Han, Jaekwon Kim, Jongsik Lee, "Adaptive Flow QoS Management Model for Wireless Communication in Mobile Environments", Acta Polytechnica Hungarica (indexed by SCIE), Volume 13 Issue Number 2, March 2016
2. Taeyoung Kim, Youngshin Han, Jaekwon Kim, Jongsik Lee, "Fuzzy Logic-based Adaptive Communication Management on Wireless Network", 6th International Conference on Computational Collective Intelligence (ICCCI 2014), LNAI 8733, Seoul, South Korea, September 2014
3. 김재권, 이종식, "클라우드 프로비저닝 서비스를 위한 퍼지 로직 기반의 자원 평가 방법", 한국시뮬레이션학회 논문지, Vol. 22, No. 1, March 2013
4. 장성호 김태영 이종식, "분산 컴퓨팅 환경에서의 워게임 시뮬레이션을 위한 네트워크 트래픽 제어", 한국시뮬레이션학회 논문지 제18권 4호, December 2009
5. 이종식 장성호 노창현, "퍼지 로직 기반의 그리드 데이터 전송 제어 장치 및 방법", 인하대학교 산학협력단 특허 등록번호 10-0919475, September 2009
6. Jong S. Lee , "Intelligence Balancing for Communication Data Management in Grid Computing", LECTURE NOTES IN COMPUTER SCIENCE, 3033, April 2004
7. J.S. Lee B. P. Zeigler, "Development of DEVS/GDDM Environment: Realization of Space-based Data Management", IEEE Systems, Man, and Cybernetics Conference, October 2001
8. Bernard. P. Zeigler Hessam Sarjoughian Sunwoo Park James Nutaro Jong S. Lee Y.K. Cho, "DEVS Modeling And Simulation: A new layer of Middleware", Advanced Middleware Systems proceedings of the IEEE high performance distributed systems, San Francisco, CA, August 2001
9. Bernard. P. Zeigler Hyup Cho J.S. Lee Y.K. Cho Hessam Sarjoughian, "Predictive Contract Methodology and Federation Performance", Simulation Interoperability Workshop (SIW) 99F-SIW-161, Orlando, FL., September 1999
10. Bernard. P. Zeigler George Ball Hyup Cho J.S. Lee, "Implementation of the DEVS Formalism over the HLA/RTI: Problems and Solutions", Simulation Interoperability Workshop (SIW), 99S-SIW-65, Orlando, FL, June 1999
11. Bernard. P. Zeigler George Ball Hyup Cho J.S. Lee Hessam Sarjoughian, "Bandwidth Utilization/Fidelity Tradeoffs in Predictive Filtering", Simulation Interoperability Workshop (SIW), 99S-SIW-63, Orlando, FL., June 1999
12. Zeigler B.P J.S. Lee, "Theory of Quantized Systems: Formal Basis for DEVS/HLA Distributed Simulation Environment", Enabling Technology for Simulation Science(II), SPIE AeoroSense 98, vol.3369, April 1998
About Middleware
In computing, middleware consists of software agents acting as an intermediary between different application components. It is used most often to support complex, distributed applications. The software agents involved may be one or many.
The ObjectWeb consortium gives the following definition of middleware: "In a distributed computing system, middleware is defined as the software layer that lies between the operating system and the applications on each site of the system."
The classic example is the transaction manager, a component that is interposed between client users and the application or "back end" database in OLTP or client/server computing. In these situations, middleware accelerates client requests by reducing the number of resource-expensive connections that must be made, and by making each connection as efficient as possible. Examples of such transaction-focused middleware include: CICS, IBM Websphere MQ, Tibco, ObjectWeb JOTM and Tuxedo.
Another reason for using middleware is to centrally provide high-level abstractions and services to applications, to ease application programming, application integration, and system management tasks. Over the years, middleware has evolved from its initial limited focus on the efficiency of transaction management to this bigger role.
Middleware is now used to describe database management systems, web servers, application servers, content management systems, and similar tools that support the application development and delivery process. Middleware is especially integral to modern information based on XML, SOAP, Web services, and service-oriented architecture.
Middleware is the enabling technology of Enterprise application integration.
In addition to the existing vendors updating their wares to address the newly expanded vision, vendors such as Mercator, Vitria, and webMethods were specifically founded to provide Web-oriented middleware tools. Groups such as the Apache Software Foundation and the ObjectWeb consortium encourage the development of open source middleware.

About HLA
High-Level Architecture for beginners
This is an introduction to the High-Level Architecture targeted at persons with no previous HLA knowledge and with only a basic understanding of computer programs.
What is HLA?
HLA (High-Level Architecture) is a standard for connecting several computer-based simulation systems so that they can run together and exchange information. Instead of building a big monolithic simulation system from scratch, the HLA allows you to combine existing simulation systems with new systems.
HLA enables you to reuse existing systems for new purposes. You can also mix different programming languages and operating systems. HLA supersedes several earlier standards such as DIS and ALSP.
Who uses HLA?
HLA was originally developed by the US Department of Defence. It is the prescribed standard for military simulation interoperability within the US. It is also the new standard for simulation interoperability within the NATO as well as in many countries, for example Sweden. The HLA can be used for any kind of simulation systems. There is a growing interest from non-military areas, for example manufacturing and transportation. The HLA standard has also become a non-military standard through IEEE.
What kind of simulation systems can interoperate through HLA?
HLA can be used to combine several simulations systems. Simulation systems can be entirely computer-based or involve real people. One type of simulation is called a virtual simulation where a real person operates simulated equipment, for example a flight simulator. Another type of simulations is a constructive simulation where simulated people in a computer operate simulated equipment, for example in computer-generated forces. Yet another kind of simulation is a live simulation where real people operate real equipment, for example soldiers during a military exercise connected to other simulation systems using radio equipment.
HLA supports simulations developed for various purposes. Some examples are training, analysis and simulation based acquisition, where products are evaluated through a simulation of their capabilities.
What are the technical components of HLA?
In HLA you combine several simulation systems, called "federates", into one big simulation, called the "federation". To do this you need to do the following:
You have to document the information that will be exchanged in a Federation Object Model (FOM). This is a file that describes the common language of the federation. It provides information about what object classes ("car"), attributes ("brand, speed") and interactions ("honk the horn") that will be exchanged within the federation. One of the reasons that HLA is so flexible is that you can develop a FOM to meet the needs of your particular federation. If, on the other hand, you have an application in a well-known area then there are several ready-made reference models that you can base your work upon.
You have to exchange information between the participating systems (federates) using a piece of software called the Run-Time Infrastructure (RTI) that follows a standardised specification.
What does the Run-Time Infrastructure do?
as exchanging interactions. The RTI can synchronize time within the federation. Different types of simulations handle time in various ways. HLA supports several time management methods. Some examples are real-time, scaled real-time, event-based time and as-fast-as-possible.
The RTI also contains more advanced functions such as transferring the responsibility of updating an attribute between federates, managing data distribution and managing the federation.
The RTI is defined by a number of services that your program can use. These are described in the interface specification in the HLA standard. An RTI can be implemented using many different technologies (shared memory/network communications, centralized/distributed topology, etc). There are several RTIs targeted at different needs.
To ensure correct behavior of an RTI there are official certification procedures. A certified RTI is guaranteed to implement the full specification and behave according to the standard. There are currently two standards, HLA 1.3, the first standard (developed by US Department of Defence) and the new, improved, IEEE 1516 standard for HLA.
Where can I find more information about HLA?
In addition to this web site you can look at
DMSO (www.dmso.mil). The US Defence Modelling and Simulation Office has a lot of information about HLA in the "Warfighter" section. This includes the HLA 1.3 standard, projects, organizations, HLA tools, RTI certification, etc.
SISO (www.sisostds.org). The Simulation Interoperability Standards Organization arranges the SIW (Simulation Interoperability Workshop). A lot of practical HLA experiences are described in various papers.
IEEE (www.ieee.org). Provides the IEEE 1516 standard for HLA.

About CORBA
What is CORBA?
CORBA, or Common Object Request Broker Architecture, is a standard architecture for distributed object systems. It allows a distributed, heterogeneous collection of objects to interoperate.
The OMG
The Object Management Group (OMG) is responsible for defining CORBA. The OMG comprises over 700 companies and organizations, including almost all the major vendors and developers of distributed object technology, including platform, database, and application vendors as well as software tool and corporate developers.
CORBA Architecture
CORBA defines an architecture for distributed objects. The basic CORBA paradigm is that of a request for services of a distributed object. Everything else defined by the OMG is in terms of this basic paradigm.
The services that an object provides are given by its interface. Interfaces are defined in OMG's Interface Definition Language (IDL). Distributed objects are identified by object references, which are typed by IDL interfaces.
The figure below graphically depicts a request. A client holds an object reference to a distributed object. The object reference is typed by an interface. In the figure below the object reference is typed by the Rabbit interface. The Object Request Broker, or ORB, delivers the request to the object and returns any results to the client. In the figure, a jump request returns an object reference typed by the AnotherObject interface.
The ORB
The ORB is the distributed service that implements the request to the remote object. It locates the remote object on the network, communicates the request to the object, waits for the results and when available communicates those results back to the client.
The ORB implements location transparency. Exactly the same request mechanism is used by the client and the CORBA object regardless of where the object is located. It might be in the same process with the client, down the hall or across the planet. The client cannot tell the difference.
The ORB implements programming language independence for the request. The client issuing the request can be written in a different programming language from the implementation of the CORBA object. The ORB does the necessary translation between programming languages. Language bindings are defined for all popular programming languages.
CORBA as a Standard for Distributed Objects
One of the goals of the CORBA specification is that clients and object implementations are portable. The CORBA specification defines an application programmer's interface (API) for clients of a distributed object as well as an API for the implementation of a CORBA object. This means that code written for one vendor's CORBA product could, with a minimum of effort, be rewritten to work with a different vendor's product. However, the reality of CORBA products on the market today is that CORBA clients are portable but object implementations need some rework to port from one CORBA product to another.
CORBA 2.0 added interoperability as a goal in the specification. In particular, CORBA 2.0 defines a network protocol, called IIOP (Internet Inter-ORB Protocol), that allows clients using a CORBA product from any vendor to communicate with objects using a CORBA product from any other vendor. IIOP works across the Internet, or more precisely, across any TCP/IP implementation.
Interoperability is more important in a distributed system than portability. IIOP is used in other systems that do not even attempt to provide the CORBA API. In particular, IIOP is used as the transport protocol for a version of Java RMI (so called "RMI over IIOP"). Since EJB is defined in terms of RMI, it too can use IIOP. Various application servers available on the market use IIOP but do not expose the entire CORBA API. Because they all use IIOP, programs written to these different API’s can interoperate with each other and with programs written to the CORBA API.
CORBA Services
Another important part of the CORBA standard is the definition of a set of distributed services to support the integration and interoperation of distributed objects. As depicted in the graphic below, the services, known as CORBA Services or COS, are defined on top of the ORB. That is, they are defined as standard CORBA objects with IDL interfaces, sometimes referred to as "Object Services."
There are several CORBA services. The popular ones are described in detail in another module of this course. Below is a brief description of each:
Service Description
Naming Defines how CORBA objects can have friendly symbolic names
Events Decouples the communication between distributed objects
Relationships Provides arbitrary typed n-ary relationships between CORBA objects
Externalization Coordinates the transformation of CORBA objects to and from external media
Transactions Coordinates atomic access to CORBA objects
Concurrency Control Provides a locking service for CORBA objects in order to ensure serializable access
Property Supports the association of name-value pairs with CORBA objects
Trader Supports the finding of CORBA objects based on properties describing the service offered by the object
Query Supports queries on objects
CORBA Products
CORBA is a specification; it is a guide for implementing products. Several vendors provide CORBA products for various programming languages. The CORBA products that support the Java programming language include:
ORB Description
The Java 2 ORB The Java 2 ORB comes with Sun’s Java 2 SDK. It is missing several features.
VisiBroker for Java A popular Java ORB from Inprise Corporation. VisiBroker is also embedded in other products. For example, it is the ORB that is embedded in the Netscape Communicator browser.
OrbixWeb A popular Java ORB from Iona Technologies.
WebSphere A popular application server with an ORB from IBM.
Netscape
Communicator
Netscape browsers have a version of VisiBroker embedded in them. Applets can issue request on CORBA objects without downloading ORB classes into the browser. They are already there.
Various free or
shareware ORBs
CORBA implementations for various languages are available for download on the web from various sources.
Providing detailed information about all of these products is beyond the scope of this introductory course. This course will just use examples from both Sun's Java 2 ORB and Inprise's VisiBroker 3.x for Java products.
Implementing a CORBA Client
This section covers what you need to know to use CORBA objects from the Java programming language. It examines OMG IDL interfaces, the Java programming language binding for IDL interfaces, object references, and requests, how to obtain object references, and how, as a client, to create distributed objects. After reading this section and completing the exercises, you should be able to write a client using the Java programming language. Again, the stock example is used to illustrate the client’s model of CORBA.
HighTech Center 1407, SE Lab, School of CSE, Inha University #253, YongHyun-Dong, Nam-Ku, Incheon 402-751, South Korea
TEL: (+82) 32-860-7454, E-mail: inhaselab@gmail.com