I have a question: is anybody enrolled in beta for this? I would like to discuss few things about it - best write me an email to firstname.lastname@example.org
P.S.: This seems to me SD 4.5 is far from dead (maybe because HP already found that Peregrine as technology is by far inferior to SD - missing meta-layer, legacy table naming, pre-historic language you have to pay EUR200k to be able to extend the platform, atc...)
I will agree that OVSD 4.5 will be far from dead if the new UI contains IDK Designer. Because without it would be a nearly impossible task to extend OVSD.
HP did a big guff with OVSD 5. Instead of creating an SUN Java client and extend the SLA module they nearly rewrote the whole damn thing . The result was largely inferior that the ancestor! And then they let OVSD die in favor of Service Manager. Though I have heard good words about service manager the general impression is that SM was generally inferior to OVSD 4.5. I don't know about SM7 though!
This is the first time I have seen that statement by HP, from previous HP events I was under the impression that the "new Web UI"(as it was called) would be released in Oct/Nov this year to remove the dependancy on the JVM which is unsupported as of Jan 1st 2008. Clearly HP have AGAIN changed their mind. It would be good to know if anyone has seen the new thick client the statement mentions.
I would like to get hold of it and put it through some tests.
I wouldn't be very skeptical about it not being WEB based. As it is pure Java it is easy to distribute it via Web Start - the same mechanism that distributes SD5.x client which is pure Java as well. Som maybe they just changed the wording but I am sure you'll be able to distribute it via WEB. If not directly supported by HP it will be easy to put together few .jnlp files to make the distribution possible.
However for my evil needs I would do much to get my hands on it now ;-)
Service Manager (SM) is just re-packaged Peregrine Service Center - nothing was taken from SD line. They just added few features to mimick SD (Views, Templates, etc.) - but these are largely just renames from the SC. Architecturally SM is just SC with changed logo. Try the beta available at HP site and see for yourself...
If only the web-api from SD 4.5 would include some more functionality then it would have been pretty easy to build a nice open source GUI as a client replacement. I have already built some Eclipse Rich Clients that act as a GUI for some functions that SD client does not offer. But there is always a certain step where web-api does not offer enough functionality to do the job.
the existing client is not written in WEB-API. It uses other API (I call it internal) that is much more powerful. Such API was officially supported (for customers) until version 4.0. If you're interested, have a look at this document to see what it was (and still is) like: http://ovweb.external.hp.com/ovnsmdps/pdf/sd4apg.pdf
Using that you can really rock and do just anything you imagine...
it is still possible to use that API - I have tested it and it works. What's best is that that part of API is written in "proper" Java so it also works in Sun JVM. However that parts only deals with data - so if you want to build GUI on top of it you're on your own (current GUI is MS specific Java on top of internal API). However the new coming GUI (which this thread is about) should provide new GUI built on top of that API.
Regarding reverse engineering: no need for that . The only thing which you might want to decompile would be the class ITSMExternalEnum (or so - don't remember right now) which contains the enumaration of all classes, their OIDs, attributes, etc. However any decent IDE (like Eclispe) will list all of these without decompilation. Also you could use javap to get the listing of these without decompilation.
that is great news. Last question on this: Can you point me to the classes that I have to use? Do I need a server setup to get the java files or is it included in the client? I cannot find SD_IMPORT.ZIP so can I use some .jar files from my client?
You need to use import.jar that is available from server installation - that contains those enumerations of classes, oids, attributes, etc. It also contains compiled examples (sources can be found in the pdf I mentioned earlier or just decompile the classes). I have tested this some time ago but in the directory where it is set up I also have cache and repo directories that are copied from server (or maybe client) - these are needed to be able to run it!
To compile the examples you would need to include (in this order) servicepack.jar, import.jar and common.jar in the classpath.
To be able to run it I have the following files in classpath: servicepack.jar, import.jar, common.jar, sdcommon.jar, ms_interfaces.jar, JClark.jar
10 points for you, Radovan. Thank you very much. I hope I will ever have some spare time to play around with building my own GUI ( I won't build a new SD client ;-)then I will publish my code somewhere...