Originally posted by Ulf Dittmer:
What does "I couldn't get" mean? What happened?
Originally posted by Ulf Dittmer:
Since the text explicitly mentions Axis, I'd use that instead of JWSDP. Point its wsdl2java tool at the WSDL given in the text, and you'll end up with a bunch of Java classes you can use to implement a Java client for the web service.
The XML Open Gateway (XOG) is Clarity�s Web service interface.These Web
services are available on the same HTTP and/or HTTPS port as the Clarity HTML web
browser interface. XOG, however, uses Simple Object Access Protocol (SOAP), an
open-standard, human-readable, XML-based protocol. Using XOG, you can read and
write data objects from Clarity, execute NSQL queries, and execute other serverside
actions.7.5.3 272
Each XOG service includes a Web Service Description Language (WSDL).The XOG WSDL is available on your Clarity server at the following URL:
http://<servernameort>//wsdl.
7.5.3 294
As previously mentioned, the XOG WSDL is compatible with the following platforms: Apache AXIS 1.3
Originally posted by Ali Hussain:
Another option is to consider a more product specific career in IT. For example becoming a specialist in an Application Server. These do not change as often as other Java frameworks and mostly you will be doing configuration work than programming.
Originally posted by Michele Martone:
I currently work as a QA manager for an automation team. I value and hire people that can understand and write tests using programming concepts. We use Silktest which has a language that is roughly based upon C. I can't speak about other QA tools, but in Silktest we have common includes which are functions that we can all share. We have coding standards, and we try to create readable test scripts. We have weekly code review meetings to ensure we are creating consistent scripts. So yes, in my team you would have to "program", but it's not as detailed as in our programming team.
Our QA people need to really understand our business also. To me the scenario creation is a fun time because I get to use my business skills, and then figure out how to invoke the scenarios with the QA tools I know.
We also have manual QA testers. If you join a manual test team you will not program. This team runs through a checklist of items that could not be automated for every release. They also must be strong in business, but not strong in technology.
If you go for QA you want to join a company that values QA. If the company values QA you will be paid fairly well if you do automated QA. Not as well for manual QA. If they don't value QA then the team will have no influence and you don't want to work there anyway. So make sure to ask them how much say QA gets in releases, how involved QA is in each production release, and who QA reports to in the company.