Soap Client server architecture

I am trying to learn Soap and perl so that I can setup a semi sophisticated client server architecture for managing vmware machines and images for automation testing. I have ok perl experience but i am average at best and no soap experience. Here is what I am trying to do

Main Machine -> Its going to have a apache running on it and will be a web interface to controlling vmware machines on seperate computers. os is linux
Vmware host machines -> will be several physical machines hosting vmware os is linux
VMware client -> will be vmware client os running windows

Now I need soap on all 3 layers to communicate with each other. The manager will get a request via web interface to launch a specific vmware image. The manager needs to send that request with parameters to vmware host machine. The vmware host machine will then launch the vmware session based on parameters and then the vmware session will start. then once the session is started after a specified about of time the vmware session will give a log back to the host machine and the host machine will then in turn send the log into a database. Now I have this logically laid out in my head and on paper.

Now I would like some help with how soap would fit in best. I have been reading some docs and it looks like soap processes are either client or server and not both. I was hoping to write client/server pieces at all three layers so that they could talk back and forth easily. I would like to be able to send status messages and create a protocol of communication between all 3 layers. But from what I have seen with soap you have to write client and then server then somehow syncronize between them which seems to make it overly difficult.

Also is it better to run as cgi scrips or run with the daemons option and listen on specified ports?

Any online references will also help. A
amesdaqAsked:
Who is Participating?
 
ahoffmannConnect With a Mentor Commented:
ok so the manager (human) just uses a browser as client and only connects to Manager (server from your picture), where this manager also contains a db for Nodes, a db vor Agent build scripts and Agent log files.
Then a web server is only requieres on Manager, if you do the jobs on Node using a web server is more a question of your taste. On the Agent you don't need a web server, simple scripts are sufficient (for both starting the inital setup and sending logs to the Manager).
As I said in my previous comment, I guess that a web server with SOAP installed on the Node is overkill.

Keep in mind that your simple picture
   Manager -> Node -> Agent
would look like following in reality (if I understand right):

Workflow to initialize/setup  Agent:
  Browser ---HTTP---> Manager ---HTTP or SSH--> Node ---> shell script to initialize Agent

Workflow to send logs to db:
  script on Agent ---HTTP--> Manager
where "script on Agent" is a simple shell one line using wget, curl or whatever started by cron, probably
0
 
ahoffmannCommented:
and why would need SOAP for that?
0
 
amesdaqAuthor Commented:
What is a better way to communicate between three layers and be able to transfer logs and files between all three layers?
0
[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

 
ahoffmannCommented:
if I understand correctly you mainly want  2 tasks
  1. server1 tells the vmware-host to start/stop another vmware-client
  2. any vmware-client sends its logs to another vmware-client
and you want to implement this using HTTP

So my my first question is: why do you need a web server for that?
all this could be implemented with simple shell scripts and ssh.

Second question: if you insist on using a web server (which complicates things), why SOAP and not imple CGI?

KISS - keep it simple stupid
0
 
amesdaqAuthor Commented:
The reason why I am using a webserver is several reasons. 1 is I need a interface thats easy to access and understand. I can't have my manager login to ssh and run vmwarelaunch -s 10.10.10.10 -i blahblah -x morelblah. On top of that The logs will be displayed via web interface. We will also be tracking which images are running via webpage. Basically the webserver layer on the manager is just there to watch over things and make things more automated when it comes to managing the process and reporting on it.

Also your missing some of the functionality I am trying to accomplish. When starting a vmware session I will also be passing parameters and files. And I think ti would be really sloppy to do it via ftp or network shares and what not.

And are you refferring to running webserver on all 3 layers? I was hoping to only run it on the manager and all other layers have the soap client/server listening on specified ports running in daemon mode.

I have a implementation with KISS in mind right now but its very sloppy and not scaleable. Imagine about 20-40 vmware host machines with 4-6 vmware images on each being launched at different intervals and all inserting logs and transferring files back and forth with the manager. I think I need a better framework for that and SOAP seems to fit the bill I could be wrong and I would love to hear your input on that.
0
 
ahoffmannCommented:
ok, understand that.
But I guess that a simple CGI is sufficient for your purpose
0
 
amesdaqAuthor Commented:
I don't understand how a cgi is sufficient if i will be running vmware instances and I DONT want to run a webserver on the client os. And I don't want to run a webserver on the host os either unless I HAVE to
0
 
ahoffmannCommented:
hmm, in your previous comment you say:
> The reason why I am using a webserver is several reasons.
> On top of that The logs will be displayed via web interface.
and now:
> And I don't want to run a webserver

if you don't run a web server, which process is then doing this and which process is sending/receiving SOAP messages?
a bit confising ...
0
 
amesdaqAuthor Commented:
Sorry for not being clearer let me try to clarify. Let me simplify the explanation of the different layers that need to talk.

Manager -> Node -> Agent

Manager - Is a web server with a web frontend to control the process.  It also has mysql on the box. For example from this gui you could kick off a automation process. It would be similar to saying install build x on Windows 2000 sp 1.

Node - Is a machine that hosts several vmware images. It start and stops vmware images based on what the manager tells it to do. It will also transfer the specified build onto the vmware image once its up. Then it will also be responsible for collecting the logs off the vmware image.

Agent - Is the actual vmware image. This will collect logs and send it to the node machine that will in turn send it to the db on the manager machine.

So the way I see the communication is the manager gets a request to run x build on x OS. It locates a node machine with the specified image and sends it a message run this build on this image. The node recieves the file via base64 then starts up the vmware image. Once the image is up it will transfer the file again via base64 and soap to the agent machine. The agent will have a install script that will install the file and collect the logs. At certian point in time it will ship the log to the node machine via soap and the node machine will insert into a db that is on the manager machine.

Now my question is what is a good way to structure and architect soap client/server so I have easy two communication between all components?
0
 
amesdaqAuthor Commented:
Thanks for your input however I don't feel you actually answered my question.
0
 
ahoffmannCommented:
which question?
you're asking for complex concept
0
 
amesdaqAuthor Commented:
How I can write a client/server process in perl to communicate all 3 layers together. The answer is semi complex thats why I made it worth 500 points. I dont need the code written for me I just need the overall process and concept explained at a high level and how I should approach doing it.
0
All Courses

From novice to tech pro — start learning today.