RE: [Geoserver-devel] Web Browsers and POST - impossible!

  1. not using SLD POST (As far as I can tell, geoserver is the only

WMS server to support it)

Definitely the first to be public about it.
http://maps.massgis.state.ma.us/mapaccess/main.jsp has supported
SLD-POST (the discussion paper from the OGC archives) with
inlineFeatures as a proprietary extension for about 3.5 years. The
codebase for the project is a complete wreck, though, and the company
that wrote it is out of business.

I'm actually really suprised that they havent actually made all this

easier to do.

dave

To be honest, this is probably why SLD-POST WMS Requests (WMS GetMap via
XML) is not in any way a real part of the WMS specification.

It seems as though OGC has defined two general "classes" of
specification:

Class 1 -
XML In/XML Out web services. These are SOAP web services simulacara,
except that they are not self-describing and none of the real-world
implementations can use XML Schema because it's all broken at
schemas.opengis.net. Well, at least GML is broken in the Xerces
Parser...which means most Java-based implementations are in a tough
spot.

Examples of these web services:
WFS, Gazetteer, Geocoder, some OLS services

Class 2 -
XML In/Data Out web services. These are services that are designed to
be used from within the <img src="" /> tag in a web page. They pre-date
the real "webservices" work that underpins SOAP/WSDL, OASIS, and really
all true machine-to-machine web services. These services are basically
a standard for creating image URL's via GET parameters on a URL string.
That's *it*.

This is mostly just applicable to the WMS standard.

This is a real problem, because neither class-1 services nor class-2
services are actually in any way shape or form enterprise-level web
services. It is extremely hard for web services programmers from the
"real world" of .NET/J2EE who are used to real enterprise web service
stub creation to work with the rather ad-hoc and mostly incomplete and
incompatible OGC interfaces.

The work required to work with a "web service" as interpreted by a major
J2EE vendor is something like the following:

1) Write your Plain Old Java Object (POJO).
2) Run a "Web Services Stub Creator Tool" on the POJO. Optionally
explicitly indicate which methods you wish to expose via a WS call.
3) Watch as a SOAP-compatible marshaller/unmarshaller is created, along
with a platform-neutral WSDL description file is written.
4) Use whatever prorpietary SOAP stack you wish to use to expose SOAP
interfaces to your POJO. This part can be hard, since every vendor does
this differently. Many are starting to use Apache Axis here...but it's
still hard and not anywhere near as easy to do as the .NET equivalent.
5) Distribute your WSDL file, which contains ALL the information
required to access your POJO via SOAP, to the world. Anyone anywhere in
any languange that properly implements the SOAP standard can take this
WSDL file and generate a language-specific binding for that language.
It will then speak standard SOAP to your POJO, via SOAP and it should
*just work*.

Other than step 1, which is tough to say is the responsibility of an
IDE, steps 2 and 3 are often well-accomplished by four clicks (including
the click on the "ok" button) in an IDE. Step 4 is tough, but often
HOWTO scripted quite well. Step 5 is accomplished by email. Or a web
page.

The vast divergence between OGC "web services" and this SOAP/WSDL model
as extensively adopted by both the java world *and* the .NET world is a
big big problem.

In an ideal world, the solution here would be to create a SOAP <-> OGC
proxy platform which allows the bajillions of programmers sitting in
front of:

* NetBeans
* Eclipse
* Visual Studio .NET
* etc.

To simply take the WSDL file that a geoserver developer/administrator
emails to them, import it, and then get "autocompletion" for methods
like (pardon the java centricity...this could be any language):

"public BufferedImage getMap(String names, String styles, ...)"

Or, alternatively (for those who like object models):

GetMapModel m = new GetMapModel();
SLDModel s = new SLDModel();
s.addLayer(new SLDNamedLayerModel("MyLayer").setStyle("MyStyle"));
...
GetMapService wms = new
GetMapService("http://geoserver.sourceforge.net/demoserver&quot;\);
Image i = wms.getMap(...);

// or
Image i = wms.sendPost(m);

Combine it with a bit of documentation about the methods, and VOILA!
WMS as an interface would be extremely widespread, and would *just work*
in a variety of languages with a great deal of programmer-level
integration.

Contrast this with the following code:

//generate a WMS request, either as SLD-POST or as a GET string
String wmsRequest = "...";
HttpURLConnection con = (HttpURLConnection) \
  new
URL("http://geoserver.sourceforge.net/demoserver&quot;\).openConnection();
con.setDoInput(true);
con.setDoOutput(true);
con.setRequestHeader("Content-Type","text/xml"); //what's the right
mime-type for a WMS requset, anyway?
OutputStream out = con.getOutputStream();
out.write(wmsRequest.getBytes());

InputStream in = con.getInputStream();
byte inputBytes = new byte[1024];
ByteArrayOutputStream imgData = new ByteArrayOutputStream();
int bytesRead = 0;
while ((bytesRead = in.read(inputBytes)) != -1)
  imgData.write(inputBytes, 0, bytesRead);

Image i = ImageIO.read(new
MemoryCacheInputStream(imgData.getByteArray());

Not to mention that this method is tied explicitly to the HTTP
transport. What about HTTPS? What about XML over SMTP? What about XML
over RMI-IIOP (not that this is a great idea, but what about it?)

Whew, this turned into a bit of a rant. Well, the idea is that such a
SOAP<->OGC proxy is both necessary and very very hard, due to the
different incompatibilities inherent in each vendor's implementation of
the WMS specification and the manner in which the different actual W*S
standards are defined.

To make it "easier to do" would be totally awesome and totally possible!
It would also be a whole lot of work, without the extensive cooperation
and transformation of the OGC standards themselves.

--saul

----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/

-------------------------------------------------------
This SF.Net email is sponsored by Yahoo.
Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
Search APIs Find out how you can build Yahoo! directly into your own
Applications - visit
http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
_______________________________________________
Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel