COBMAF-VAME++ Introducing COBMAF-VAME-WEB Model Presented by: Sujeet Ghanvat Ashay Kharpate Rahul Iyer Karan Kamdar

COBMAF-VAME++Introducing COBMAF-VAME-WEB

Model

Presented by:Sujeet GhanvatAshay Kharpate

Rahul IyerKaran Kamdar

COBMAF-VAME

The Previous Model

Literature Survey

• Virtual Enterprise•Project Requirements

•Design of VAME•Implementation

Virtual Enterprise

Definition :

"A virtual enterprise is a temporary aggregation of core competencies and associated resources collaborating to address a specific situation, presumed to be a business opportunity.“

Topology :

•Internet communities sharing a common interest•Intra-enterprise groups of individuals •Inter-enterprise organizations •Independent organizations that joined together to accomplish a particular project.

stable or dynamic environments.

What is VAME ?

Virtual Automobile Manufacturing Enterprise

The VAME is an agglomeration of all companies that provide essential parts in the manufacturing of an automobile.

Project Requirements

CORBA FrameWork

To incorporate more flexibility into the implementation of agents in the Virtual Enterprise the CORBA (Common Object Request Broker Architecture) platform is used as the middleware.

Language Independence

Borland Visibroker

VisiBroker is a complete CORBA Object Request Broker (ORB) and supports a development environment for building, deploying, and managing distributed object applications that are interoperable across platforms.

Software Agents to model a VE:

•A software agent is basically a software program designed to perform specific goal- driven functions and has the capability to communicate with other agents

•A software agent is an “expert" in its function. It is aware of and can access the functioning capabilities of other agents.

Design of VAME

An automobile manufacturing VE consists of various companies (enterprises) buying and selling automobile related products.. There is a need to come up with a generalized agent system which can be used by any of the above types of companies. Let us first look at the essential requirements of our VE.

•Global Product Database:•Negotiation Functionality:•Resource Management:•Scheduling:•Choice of Agents:

•Global Agent Management Server (Global AMS):•Local Agent Management Server (Local AMS):•Resource Management Agent (RMA):•Scheduling Agent: •Sales Agent (SA): •Procurement Agent (PA):

IMPLEMENTATION

Agent Class:

• This is the basis of the agents in the virtual enterprise system. The Agent class is the super class of all other agent programs or classes written by the application developers. .

•The Agent class extends the Thread class of the Thread package provided by the programming language environment.

sendACLMessage(ACLMessage)(ACLMessage)=recvACLMessage()

Behaviours:

•A Behaviour provides the agent a separate thread of control to execute a certain set of actions in a certain manner. Every behaviour is configured as a thread of the underlying programming language package. So an agent with much behaviour spawns separate threads to server each behaviour.

Behaviours:

•One Shot Behaviour:

•Simple Behaviour:

•Cyclic Behaviour:

•Looper Behaviour:

•Waker Behaviour:

The ACL Message Class:

This class provides the basic implementation of our agent communication language message. Any message has the following four string fields:

sender IDreceiver ID

contentperformative

The Agent Management Server (AMS):

This is basically a facilitator agent that handles registration and authorization of agents on an intra organization scale. Every participating enterprise of VE must have its own version of AMS agent running to service all its other local agents.

The Global Agent Management Server (GAMS):

The global AMS functions much like the local version except that it works on an inter organization scale keeping information about the participating organizations and their local AMS. The global AMS also is not available for implementation by developers and is hard coded.

COBMAF-VAME++

The Extended Model

Application Level Facilitator Agents

Directory Service Agent (Directory Facilitator)

•White Page Service: This service looks up agents in the directory based on their unique identity. It returns the services provided by the agent and its address.

•Yellow Page Service: This service looks up the agents based on their type and services provided. It returns the access details of the agent including name and address.

VisiBroker’s Smart Agent

•A lightweight directory service with a flat, simple namespace, which can support a small number of well known objects within a local network.

•Must be started on at least one host within your local network.

•When your client program invokes bind() on an object, the Smart Agent is automatically consulted.


GUIDELINES:

•Communications are based on UDP.

•UDP is often not reliable or allowed in wide area networks.

•Smart Agent is designed for intranet use, it is not recommended over wide area networks that involve firewall configurations.

•Smart Agent is meant for use in static network configurations.


LOAD BALANCING/ FAULT TOLERANCE:

•Load balancing using a simple round-robin algorithm on a per agent basis.

•ORB runtime caches access to the Smart Agent.

•When a Smart Agent is terminated, all servers that were registered with that agent attempt to locate another agent with which to register.


LOCATING SMART AGENTS:

•VisiBroker locates Smart Agent using a broadcast message.

•Point-to-point UDP connection setup with the first Smart Agent to respond.

•If one of the Smart Agent processes should terminate unexpectedly, all implementations registered with that Smart Agent will automatically re-register with another available Smart Agent.

•A heartbeat message is sent every 2 minutes to verify client connectivity.

MIGRATING OBJECTS BETWEEN HOSTS:

•Process of terminating an object implementation on one host, and then starting it on another host.

•Moving objects from overloaded hosts to hosts that have more resources or processing power.

•To keep objects available when a host is shutdown for hardware or software maintenance.



BINDING TO OBJECTS:

•Client application must first obtain an object reference using the bind() method.

•VisiBroker contacts the osagent to locate an object server that is offering the requested interface.

•VisiBroker attempts to establish a connection between the object implementation that was located and your client application.

•If the connection is successfully established, VisiBroker will create a proxy object if necessary, and return a reference to that object.


DATABASE AGENT:

•Different types of databases being accessed.

•Agent keeps track of the drivers used by each database.

•Data formats, access details, ways of storage etc. are also maintained.

Middleware Level Facilitator Agents

Gatekeeper in VisiBroker

•An OMG-CORBA compliant General Inter-ORB Protocol (GIOP) Proxy Server developed by Borland Software Corporation

•Enables CORBA clients and servers to communicate across networks while conforming to security restrictions imposed by Internet browsers, firewalls, and Java sandbox security.

Deployment of Gatekeeper

Client and Server on the Same network:

•Client can generally connect directly to Server.

•Case 1: Restricted client transport type.

•Case 2: Java sandbox security.

Gatekeeper in VisiBroker

CLIENT AND SERVER ON ADJACENT NETWORKS:

•Two networks are connected using an internetworking device such as a gateway or router.

•Firewall may exist in either network or both networks.

•Internetworking device must forward the message from the client network to the server network.

Locations to Deploy Gatekeeper

Case 1: No GateKeeper required.


Case 2: Gatekeeper in a Server Network.


Case 3: GateKeeper in a Client Network.


Case 4: GateKeeper in Both Networks.

Configuring the Firewall

Network Address Translation (NAT)

•NAT can translate the source host address, source port number, destination host address, and destination port number found in every network packet.

•Client side: firewall translates the source host address.

•Server side: Firewall may translate the destination host address and/or the destination port number.

•GateKeeper supports only static NAT.

Communication Agent

•Used to facilitate communication amongst any two agents.

•Facilitator looks up the interface repository, obtains the interfaces used provided by the agents and the parameters requires to invoke them, and returns this information to the “caller” agent.

•Each individual agent has the flexibility to change the interfaces it provides or the parameters required to access its methods.

COBMAF-VAME-WEB

A New CORBA Based Web Agent Framework

COBMAF – VAME – WEB (C V W) – You got to see things in a new light !

Introduction – Why CVW ?

•The desire to market our extensible base research model COBMAF.

•Mapping of the model to the internet and thereby setting up an actual company called COBMAF.com.

•Provide some means of building not only a Virtual Enterprise based on Manufacturing System but to create a general purpose VE model extensible to any kind of VE on the web.

•Parallely integrate research in base model into web model and so provide continuous growth potential to CVW.

•Underlying drive – To give back something truly magnanimous to VESIT before we leave.

The GlobalAMS (Server-Side Architecture) – Company COBMAF.com

A) Servlet Hosting and Deployment:- Consists of any servlet enabled web server such as Apache Tomcat which would host and deploy all servlets related to the respective client companies such as Company X. - Each company joining the dynamic enterprise is allotted its own registered user space where servlets corresponding to that company are stored.

B) The ORB and Naming Service:- Support for different ORBs and Naming Services in the web-based model. ORBs such as Visibroker, OpenORB etc and naming services such as JNDI and others are compatible

C) Administrator:- Any person in charge of setting up and managing the web server as well as initializing the Naming Service. The ORB is automatically initialized through the port values present in the code.

D) LocalAMSServlet (Common):- Common to all the LocalAMSs and acts as the intermediary between each LocalAMS and the: GlobalAMS. Registers each LocalAMS on the naming service

E) GlobalAMS agent: - 1) Initializes the ORB 2) Registers on the naming service with id "globalAMS" 3) Starts the GlobalAgentManager which invokes another GlobalAgentListener class (agent) and handles registration of all LocalAMSs.

Why Servlets ? - Increasingly the internet standard for keeping client thin.

- Possibility of extending the servlet model to embed all agent code at server.

- The client side is so thin that only a web-browser is required which calls the corresponding servlets.

- Provide only mapping and not one to one translation of the base model.

- Scalability Support : Possibility of customizing agent code anytime anywhere.

- Servlets such as Listener Servlet, Resource Management Servlet, Procurement Servlet and Sales Servlet, Scheduler Servlet have been employed to implement all the agent related class files. Each of the above servlets are stored on the registered user space for each company and these servlets can be downloaded by the LocalAMSs so that they can tailor it to their exact preference and upload them back on the web server.

The LocalAMS (Client-Side Architecture) – Company X

- Possible because all agent related class files have been migrated to the server side, the client side architecture is kept clean in the form of simple html pages which request and receive data through the servlet processing at the server side.

How our Web-Model works ?

The 7 Steps to Business – Page 1 1) Administrator at Company COBMAF.com first gets the servlet enabled web server up and running and manually initializes the Naming Service which is used by different participating companies to find each other and communicate.

2) Next the Administrator runs the GlobalAgent class file (agent) which initializes the ORB and registers itself on the naming service with id "globalAMS" and represents our company COBMAF.com. By registering itself this agent makes itself available to all other participating companies. It then automatically starts the GlobalAgentManager class file (agent) which invokes the GlobalAgentListener class and handles registration of all LocalAMSs in the gams database containing entries in the form of LocalAMS name - IP. Now the server side startup is complete and our Company COBMAF.com is ready to listen to incoming registration requests from the client side.

3) Now the Company X or LocalAMS who wishes to participate in the Virtual Enterprise first visits our Company site : www.cobmaf.com and is presented with a License buying screen as seen in Fig 1.1. When it clicks on Buy now, it is taken to the Registration page (Fig 1.2) where it enters its name and selects its mode of payment. Then it clicks on the button 'Register with GlobalAMS' to send it registration request to the GlobalAMS. This registration request is processed by the common LocalAMSServlet which finds the ORB and the Naming Service and registers Company X on the Naming Service with id passed in the 'Company Name' field through the get and post methods.

The 7 Steps to Business – Page 2 4) Next the LocalAMSServlet extracts the ids globalAMS and the recently registered "Company X" from the naming service. It then uses the available interface gint to send a 'REGISTER performative' to the listening GlobalAMSListener and also sets up LocalAMS interface to listen to the corresponding response from the GlobalAMS.

5) The GlobalAgentListener which is part of the GlobalAgentManager now received the performative "REGISTER" after which it makes an entry of the type Company X name - IP in the gams directory. This confirmation goes back to the LocalAMS listener as success = 1 or success = 0. If the company is registered it is then taken to a login screen else an error message is displayed.

6) Company X logs into the system at its sub domain : companyx.cobmaf.com. If (option = remote side hosting) then (simply download the servlet files diplayed on the screen, make suitable changes to the code, and upload the files back to COBMAF.com's web server). These changes are required because the idea is that the Company X should also be able to act like another GlobalAMS providing custom Agent classes to its intranet participants. However if the Company X has chosen the option of hosting servlets on its own web server then it only needs to download the template servlets and does not have to upload any files since the servlets now become locally available.

7) A Company Y who is part of the seller-buyer network of Company X now acts like the LocalAMS and Company X acts like the GlobalAMS and the procedure is exactly the same as that for COBMAF.com - Company X.

Thank You

Documents

COBMAF-VAME++ Introducing COBMAF-VAME-WEB Model Presented by: Sujeet Ghanvat Ashay Kharpate Rahul Iyer Karan Kamdar