So, Poicondai II (Which I think is going to be called "PoiCenDai" because they are just called poison centers not poison _control_ centers anymore) is in the works.
The new service that will be feeding PoiCenDai is going to be giving back a lot more complex information, namely count aggregations based on region and time. Dr. Jeremy Espino has recommended Apache CXF as the service handler (which is basically the next generation of Apache AXIS, which will allow for this new PoiCenDai to work with globus that much more seamlessly should we need to distribute its operations on the grid) and using JAXB as the object marshaller (At least I am anticipating this because the last poison center webservice returned the data as an XML "any" stream with a "schema" stream)
Thus, the PoiCenDai service is going to need to take a command, determine the output type, marshal it all out, and then take the results and filter them into the appropriate regional polygons which were also drummed up with the help of the Gmap Polygon libraries.
Thus it's becoming one of those little moments where it's awkward figuring out where to start, whether I delve in with the new technologies for objectifying the PoiCen data, or start planning ways to keep methods for stuffing PoiCenDai data into polygons simple and relatively agnostic to JSPs.
I think I am going to focus on making the stubs for PoiCenDai closer to the JSP side for a couple of reasons... First off, I have just been dealing with the JSP end of things so it will be an easy bridge, second is that I am not sure of the service endpoints and will need to fiddle with JAXB and CXF and it would be good to know where the resulting objects are going to go.
Of course this is all liable to change as assumptions will probably be made and then be proven wrong or not feasible. Another wacky day in coding big enterprise type things.
Showing posts with label JAXB. Show all posts
Showing posts with label JAXB. Show all posts
Monday, January 26, 2009
Saturday, September 13, 2008
RODSAdai, PoiConDai, and NPDS-ws
Today I started off by having a productive discussion with the folks who helped me with RODSAdai: Dr. Jeremy Espino from Pitt (who brings the RODS) and Mario Antonioletti and Alastair Grant from University of Edinburgh (who bring the OGSA-DAI).
We discussed future developments, concerns about security, scalability, and automating installation and configuration as much as possible. We also talked about our availability being reduced for the next phases... But mainly we talked about the fact that one of the things that got lost in the making of RODSAdai 1.0 was a quick and descriptive design document that explained what we were all trying to do and how. Something so that Alastair, Mario, or Jeremy would be able to go "oh, well to connect it that way you should try configuring it like this..." Furthermore it is much more likely that the whole Axis/Globus conflict would have been found earlier and mitigated sooner since Alastair was already familiar with that particular limitation. Thus, the first step for the next phase of RODSAdai is to take the ideal-state and current-state diagrams of RODSAdai that I made, and more information about what they mean, how they currently work, and how I hope to get them working to focus advice and let anyone search for red flags.
But I won't be able to do that until Thursday of next week, because right now I am in demodemodemo mode to get PoiConDai in some form of pretty graphical display so we can show that yes, we are pulling Poison Center call data into the CDC.
This was greatly moved forward this morning with the help of Dr. Espino, namely because he already wrote code that used AXIS to consume the NPDS webservice a couple of weeks ago and had already incorporated all of the JAXB libraries needed for parsing the "any" response returned by the web service. The codebase is called npds-ws-client, and I am going to use it because it is pretty and is along the lines of what I was going to do, only with the properties file and return serializing I was planning on doing already implemented (and thank goodness for it).
Let me pause here to say how much I love maven again. It has extensions for generating axis stubs and jaxb code, so all you need to do is have the WSDLs handy and you don't have to worry about constantly regenerating the parsing bits and movig them about manually. How cool is that!?
Meanwhile, my next step is to incorporate a few of those unit tests I posted about earlier, and then set up a web-client front end that I am going to call PoiConDai web for showing the data in an ever-snazzier JSP. I think I am going to get something really nifty ready by Tuesday Evening.
We discussed future developments, concerns about security, scalability, and automating installation and configuration as much as possible. We also talked about our availability being reduced for the next phases... But mainly we talked about the fact that one of the things that got lost in the making of RODSAdai 1.0 was a quick and descriptive design document that explained what we were all trying to do and how. Something so that Alastair, Mario, or Jeremy would be able to go "oh, well to connect it that way you should try configuring it like this..." Furthermore it is much more likely that the whole Axis/Globus conflict would have been found earlier and mitigated sooner since Alastair was already familiar with that particular limitation. Thus, the first step for the next phase of RODSAdai is to take the ideal-state and current-state diagrams of RODSAdai that I made, and more information about what they mean, how they currently work, and how I hope to get them working to focus advice and let anyone search for red flags.
But I won't be able to do that until Thursday of next week, because right now I am in demodemodemo mode to get PoiConDai in some form of pretty graphical display so we can show that yes, we are pulling Poison Center call data into the CDC.
This was greatly moved forward this morning with the help of Dr. Espino, namely because he already wrote code that used AXIS to consume the NPDS webservice a couple of weeks ago and had already incorporated all of the JAXB libraries needed for parsing the "any" response returned by the web service. The codebase is called npds-ws-client, and I am going to use it because it is pretty and is along the lines of what I was going to do, only with the properties file and return serializing I was planning on doing already implemented (and thank goodness for it).
Let me pause here to say how much I love maven again. It has extensions for generating axis stubs and jaxb code, so all you need to do is have the WSDLs handy and you don't have to worry about constantly regenerating the parsing bits and movig them about manually. How cool is that!?
Meanwhile, my next step is to incorporate a few of those unit tests I posted about earlier, and then set up a web-client front end that I am going to call PoiConDai web for showing the data in an ever-snazzier JSP. I think I am going to get something really nifty ready by Tuesday Evening.
Subscribe to:
Posts (Atom)
Posts
