|
View Full Version : When will control panel software move to XML Webservices for automation?
anantatman 04-04-2002, 03:30 AM All these Control Panels,
Hsphere, Cpanel/WHM, Ensim, Plesk etc..
they lack one thing. . . a way to EASILY integrate them with sales/account creation, billing, and most importantly maintenence.
Most of you don't know about XML webservices, but they could really help.
Lets say someone has 10 Cpanel/WHM servers. How does he manage the creation and deletion of accounts? Or how does he write a signup script to see the availability of accounts on a server and add them.
One way is to go to all 10 servers and use the web based admin on each of them see the status.
Another way is to use Web services. If each Cpanel/WHM server had a webservice running exposing some of its functionality to the world using XML,
people could write applications to manage them all. If they did it to the WSDL spec, heh you could even write it in .NET and make a VB.net form application to run on your windows box where you sit.
Yeah.. so ENSIM has something to control all of their webppliance, but who wants to buy their whole system?
Better yet, if all the control panel people standardized the functions being exposed, you could use different control panels and still use your central program/script.
What if you have resellers? Well you could write a proxy webservice which takes requests from resellers and pushes it to your team of servers.
Maybe i'm just dreaming, but wouldn't that make you're life easier?
Rahul Singh
VP, Applications
http://www.anantsystems.net
P.S. if any of the control panel people want to collaborate....
iseletsk 04-04-2002, 09:23 AM Lets say someone has 10 Cpanel/WHM servers. How does he manage the creation and deletion of accounts? Or how does he write a signup script to see the availability of accounts on a server and add them.
H-Sphere does it automatically. It automatically detects which server to go to to signup user. You can disable some server for signups, and enable another one. It will detect it, and from one single point setup account on remote server. It can handle cases where mailserver is in one place, dns is in the other server and web is on the third server.
It also has a way to define new account in XML and create it from command line.
allan 04-04-2002, 10:10 AM Ensim and Sphera offer products that handle at least some of the features you are looking for, and I believe Cobalt offers a central management server (or they used to), that would allow you to control multiple RaQs through a single interface.
You make a good point about using an XML interface, that would allow a CP company to provide a better API that hosts could use to truly customize the installation, and mack the existince of multiple servers.
I think the reason most companies don't do this is that the development cycle for something as comprehensive as a control panel is so long, that many of these companies are not going to completely trash their existing interface and start from scratch.
anantatman 04-04-2002, 10:41 AM well the beauty of XML webservices is that they can have their existing API but would only need either a PHP/Java app sitting on a secured port as a wrapper API.
The development time would be a bit burdensome,but only in the planning.
Once they figure out exactly what to expose as a XML-RPC , they'd have maybe 10 lines of code per function.. (hopefully)
CreateSite(domainName, userName, password, ip, .. ..)
DeleteSite(domainName)
..
..
..
iseletek: H-Sphere's functionality is great , probably much better than the others.. but the XML that i'm talking about isn't about specifying the account information as a XML file and using a command line to parse through that information to create it.
here's an example of a SOAP code.. the first is a soap call, the other is a regular low level call which parses the XML manually..
<?
// include soap client class
include("class.soap_client.php");
print "<html><body><br><strong>wsdl:</strong>";
$soapclient = new soapclient("http://services.xmethods.net/soap/urn:xmethods-delayed-quotes.wsdl","wsdl");
echo $soapclient->call("getQuote",array("symbol"=>"ibm"));
unset($soapclient);
print "<br><strong>non wsdl:</strong>";
$soapclient = new soapclient("http://services.xmethods.net:80/soap");
echo $soapclient->call("getQuote",array("symbol"=>"aapl"),"urn:xmethods-delayed-quotes","urn:xmethods-delayed-quotes#getQuote");
unset($soapclient);
/* low level api
// create message
$soapmsg = new soapmsg("getQuote",array("symbol"=>"ibm"),"urn:xmethods-delayed-quotes");
// invoke the client
$client = new soap_client("http://services.xmethods.net:80/soap");
// send message and get response
if($return = $client->send($soapmsg,"")){
if($return->name != "fault"){
echo array_shift($return->decode());
} else {
print "got fault<br>";
print "<b>Client Debug:</b><br>";
print "<xmp>$client->debug_str</xmp>";
die();
}
} else {
print "send failed - could not get list of servers from xmethods<br>";
}
*/
?>
Originally posted by anantatman
well the beauty of XML webservices is that they can have their existing API but would only need either a PHP/Java app sitting on a secured port as a wrapper API.
You keep saying "webservices" - and you were talking about .NET; but whay you really mean is SOAP - right?
So basically you're just saying that we need to have controlpanels with some kind of RPC - and a "easy to use" interface for that.
ScottD 04-04-2002, 01:13 PM Web Services isn't specific to .NET, but more a term used to define one application of SOAP and/or XML-RPC.
Something I find odd about the "control panel" industry as a whole is that it is lacking severely in regards to technology. There really isn't a well designed control panel out there that I have seen -- and I've looked at quite a few.
HSphere is the best bang for your buck but still lacking in areas of openness and is very difficult to navigate in terms of extending without any architecture docs.
What would be extremely cool is if a PSoft were to extend HSphere by exposing interfaces via SOAP so we could more easily integrate with it. Since they are already using a Java Servlet base it wouldn't be too difficult to add a few components that wrapped their system objects, but only they have the knowledge to do so.
Rahul, you are on the right track. Maybe your advocacy here will inspire folks to build these things for us. :)
Everyday 04-04-2002, 01:25 PM From what I've seen lately about the only company you might get to even try this would be psoft/h sphere. They seem very in tune to their customers and add lots of new features that are requested.
Most of the other control panel companies give you what they build and make you modify your learning curve and business to suite them. Thats not what I call user friendly. If some keep going as they are they might not be around since they don't seem to give customers, mainly us-ISPs-web hosts what we ask for. As noted psoft/hsphere is about the only one who directly communicates with their customers.
Just my 2 cents...
anantatman 04-04-2002, 01:46 PM Finally people are understanding where i'm coming from.
If Psoft does come up with something they must understand that once they do this, everyone will/should follow. That's why good planning and a robust standard will make everyone happy.
iseletsk 04-04-2002, 02:44 PM Regarding SOAP/XML-RPC interface:
Do you want it on the provisioning level or control panel level:
Provisioning level:
Control panel sends XML message, that says "setup mailbox", and someone else (your code) processes that request and sets up mailbox.
Control Panel level:
You send XML message to control panel: setup mailbox, and control panel does what ever is necessary to setup mailbox.
Everyday 04-04-2002, 02:50 PM See what I mean :)
ScottD 04-04-2002, 02:56 PM Both options would be nice. :) Then there could actually be a clear and defined method of extending the control panel by telling it how to communicate with our own custom built services.
On the other hand, it would be really nice to create custom sign up scripts and such, utilizing the control panels already extensive function set for things like checking on a domain name (via OpenSRS), getting instant credit card validations (through the various gateways supported by HSphere), etc. This would actually make it possible to build a completely custom sign-up script that can check for a domain, validate the credit card, and then when all is well and done send a final SOAP request asking HSphere to provision the account and return all of the gory details (IP, instant activation domain name, name servers, total charges, approval code, etc.)
But why stop there? Here's a small list for you to think about:
Single point of authentication (use SOAP to authenticate with HSPhere)
Query various customer details (accounts, domains, etc.)
Query billing details.
Update billing information.
Add and delete domains.
Basically, anything that can be exposed. :D
P.S. Everyday, I know it. Their (PSoft's) support and how well they listen has been great for me since I signed on using HSphere. A most excellent experience so far.
Everyday 04-04-2002, 03:05 PM I would even take this one further.
If they can implement this so that custom scripts can be made then I'm sure a list of preconfigured scripts could be available on the psoft web site that would allow anyone who uses the software to download and install the options they wanted.
That would be real functionality.:)
anantatman 04-04-2002, 07:26 PM a reference signup script would be nice, and the user could then extend it to meet his functionality by seeing the WSDL description of the webservice.
Because Hsphere is already centralized, only one webservice would be needed to expose the functionality.. But the individual services could
also have a small WS that can report information like server usage, uptime, network stats, etc... but even that can be proxied through from the central server.
Of course all this wouldn't be necessary right now. Rudimentary account creation and billing would be nicest thing to have right now.
Rahul
rahul.singh@anantsystems.net
iseletsk 04-04-2002, 08:21 PM Because Hsphere is already centralized, only one webservice would be needed to expose the functionality.. But the individual services could
also have a small WS that can report information like server usage, uptime, network stats, etc... but even that can be proxied through from the central server.
You have to see 2.1 - it will have exactly that.
ScottD 04-04-2002, 08:51 PM I can't wait for 2.1. It really seems like it'll be quite the milestone.
smash 04-05-2002, 02:09 AM The problem with all these control panels is that they are closed. You will still have to adapt your business, your services, your billing method, your signup process, etc to the software. Running a large heterogeneous (different Os's/software) won't be possible. Extending the control panel, how it is controlled, etc will be stay very limited, no matter what.
This is why I am working on my own server management or control panel system. I thought about pretty much what people have been talking in this thread more than a year ago, but I never thought of using a commercial control panel, because I know it would never work the way I want it.
On my implementation each server is running a daemon that administers the various services it is running. It doesn't matter if the server is FreeBSD or linux or whatever else, or if it runs qmail or sendmail, the daemon gets the request (through a XML based protocol) and gets the job done.
The "client" part can be adapted to the ISP needs. It can be a GUI application that connects t a specific server to administer it and/or it can be an intelligent "dispatcher" that performs queued tasks set by web signup script or end-user control panel.
It is a work in progress, and I am thinking of releasing what's done open source. What I would really not want is being swamped by "could you add this specific feature" requests, and I know it would happen. Also I wonder if there would be enough interest for other programmers to bring real contributions....
anantatman 04-05-2002, 02:31 AM The whole point of this discussion is to see the interest. If we didn't dream, half of the things already in the control panel's wouldn't be there.
Of course the control panel's are closed, thats how they protect their brand name. That's what microsoft did until it found out that webservices are the way to go. Realizing it, its now make it easy to integrate with other services. Now frankly if I were to choose a development platform between Borland, Oracle, IBM, HP, or Microsoft, i'd use Microsoft because it's easy to use.
If the control panel companies could focus on making it easier for companies to integrate their internal systems with their server software, People could offer multiple control panel software, and not have to worry about the busy work involved.
iseletsk 04-05-2002, 08:03 AM I don't think the reason of control panels being "closed" is to protect brand name.
Creating trully open system that can be easelly extended requires a lot of additional time and resources. Beyound the basic design, there is also additional development to provide an easy way to plug in external components into control panel infrastructure, as well as large documentation project that has to be completed. Without good documentation and easy way to plug in external components - no one would take advantage of the open infrastructure.
Yet, it is always a traid off - to add a new feature, or to work on the system that are easier to integrate with.
|