Slashdot Mirror
Web Servers To Handle Java Servlets And WAP?
Yousef asks: "We're trying to develop a WAP enabled Webserver, that can work with Java (Servlets). Currently the only working option is M$ IIS running the New Atlanta plugin. Now I'd rather NOT run IIS, so if anyone else has a solution to this, it would be much appreciated. We've tried Inprise IAS and Apache JServ (We're deploying to a Sun Solaris box). Any help would be nice. Getting the servlets to run is quite easy -- The problem is getting them to work with WAP!"
"WAP creates its own session ids, and that stops other serverside objects from sharing the same objects.
In short, we have an existing Servlet based system. Now we are trying to incorporate WAP into it (WML). It seems to us as though WML passes cookies around differently to HTML: HTML stores them with the browser, and WML stores them on the server. We've tried just about every server under the sun, and they all behave in the same way."
Try the new version of Roxen. Support for PHP4, Servlets, WAP, Pike scripts etc. etc. http://www.roxen.com
This is a terrible way to maintain sessions if you are worried about caching. Cookies are the best with regards to caching, because the unique session string will require a cache to store a copy of the document even if it is identical to other pages.
just something to think about..
cheers,
-o
It's too little, too late. It's not very userfriendly and it's a kludge on top GSM (or whatever you are using) 3rd generation mobile systems like GPRS are around the corner, and IMHO we (developers) need to focus on them, rather than that horrible kludge the WAP is. Don't waste your time on WAP...
Just my 2c
J.
See above responses.. It's all about cookies..
-- I'm the root of all that's evil, but you can call me cookie..
Ahh, I had never even thought about using cookies on WAP devices. Personally, I've always based the session information on data contained within the form, aka, URL based, along with form attributes.
Now it starts to make sense..
-- I'm the root of all that's evil, but you can call me cookie..
I'm confused. Nearly anything that can serve HTML can serve up WML, provided the content type is configured correctly, and it spits out valid WML. Why would one need a specific API set to spit out WML code?
-- I'm the root of all that's evil, but you can call me cookie..
The cool thing about Engydra (that I'm suprised the original poster didn't mention) is that the development is entirely opensourced. It's sponsored by lutris. They make their money off support contracts for this thing. I've seen some demos of the product, mostly just using cell phone emulators (that I think they ship with enhydra, or they will very shortly), one java, and two win32's, so you can test all your wap apps before fully deploying them. There's also a sample app or two in there. go check them out .
-Peter
> I didn't know /. had a WAP page... what is the URL?
;)
www.slashdot.org should work
HTH
> This together makes WAP that much faster and better suited for use over a wireless connection than HTML.
Yeah. And if there would be devices/browser software that would fully support it and gateways that wouldnt suck it might actually someday be usable.
Just sad that by that time the devices probably dont need to rely on the slow GSM connections anymore and the displays and processors should be big enough to support normal HTML rendering.
We use Apache together with Resin to create cookie-less session management. Almost all servlet/JSP engines have support for creating sessions this way; the critical thing to remember is to *not* just write links the normal way, but to use the response.encodeURL method to make sure the servlet engine appends the ";jsessionid=" string to the URL in all links.
Besides, check out the rest of their website. All around cool guys...
-------
Warning: Slashdot may contain traces of nuts.
Wow, I never thought we were cool - but thanks to Jacco for saying so. If anyone wants to pick up the php3 templates we use on the site, I've packed them into a gzipped tar archive and put them on the site at this location - they will extract into the current directory, so be careful where you unpack them. They aren't a lot of use by themselves except as a source of ideas, but please feel free to explore them - and let me know if you spot any errors! The server will lie and tell you the archive is in text/plain format; just click on `save as' and then unzip it in the normal way. It's only about 9K.
Mike
php4 has extensive session support - you can encode the session info into the URL, or as a cookie, or even use http authentication. That would go a long way towards ensuring uniqueness.
Wapsody is a Java WAP development environment. Might find that worth looking at too.
I didn't know /. had a WAP page... what is the URL?
Also, you can go through the google search engine, which will translate the site into wml...
--Rob
Basically, these views are correct, however, they also seem to miss the point of XSL. :-) XSL is not, nor is it likely to ever be a full-fledged programming language. XSL is a declarative translation language used for converting from XML to other forms of XML and/or HTML.
XSL separates the programming logic of the site from the display logic in a relatively clean manner. The advantage of this is that it allows Designers to use advanced graphic oriented tools such as eXcelon Stylus to develop the look and feel of the site, rather than relying on developers.
You can see an example of an entire site run by XSL/XML at HeadlineW atch.com, where it provides all HTML content, as well as RSS and WAP feeds.
Throw the bums out!
Anyway, I'm sure that there are plenty of other options, but I've used both of those and found them to be of good quality and performance (Orion being the fastest).
------ Jess
Throw the bums out!
I don't know the particulars of your application, but by decoupling the content from the presentation, you gain an enormous amount of flexibility and power.
By creating content as XML, you can now create XSLT scripts to transform that pure content into an arbitrary presentation form. So you can write an XSLT script that transforms your XML content into XHTML or into WAP. This is powerful because now you can serve multiple different requestors with the same content.
There is a project called Cocoon (from the Apache Software Foundation) that does this exact thing. Cocoon itself is a servlet, so it gives you a choice of what servlet engine to run it on. It provides good caching, XSLT transformations, and even a "sitemap", which is a central location for binding look&feels to content.
There is an open source servlet engine that has built in XSLT processing, XPath processing, and XML parsing. It is extremely fast and has a lot of features. It is Resin. I recommend this one. Because this is a full blown servlet engine, you have JSP processing, session support, and it is even a small web server.
The current generation of WAP 1.1 gateways don't deliver cookies to the micro-browser, as there isn't the memory space on the handset.
Whilst some gateways, most notably Phone.com's, will manage cookies for you, you're best off using the good old URL extension model for handling session information.
Dynamic URL generation is a given here for any HREFs, though alternatively you could hack around with postfields and the like. You will need to be careful with your dynamic pages not to exceed 1387 bytes per deck of WMLC at the gateway, if you wish to deliver to Nokia 7110s...
This means that you can use any servlet engine and web server combination. I'd recommend reading Steve Mann's "Programming Applications with the Wireless Application Protocol" [Wiley 2000] as a good starter. It's a bit too focused on Phone.com, but still worth a look at how to develop WAP servlet applications.
In the future WAP 1.2 devices and their associated gateways will support cookies and other session mechanisms through the use of the WIM, an enhanced SIM with PKI features. However, don't expect them for 8 months or so - and then be prepared to comletely rewrite your applications!
S.
Yes and no.
If you are looking a year or so out, then possibly as we transition to MExE from WAP for 3G devices, but there'll always be a place for WAP no matter what the wireless layer - purely because it is designed to work with the familiar handset.
EPOC devices will be part of the transition through GPRS and EDGE - but the SDKs for Quartz are not even in closed beta yet...
It's my job to think about mobile device strategy, and there's a lot happening that you don't know about. However the first GPRS networks will only run at 30Kbps and there's not really any scope for more complex devices until we hit EDGE roll out towards the end of 2001 - and that's unlikely to occur now with the up front costs of 3G licences...
S.
Slashdot pages will be very difficult to WAP-enable without a major rearchitecture, as they'll go over the deck size limits of 1400 bytes of compiled WMLC very easily...
And if you've got a 7110 you're limited to 1387 bytes of deck due to a nasty bug in the Human Technology micro-browser - one that's taken over 20 versions of firmware to fix!
S.
In addition to the above, one may develop a distrust of a manufacturer because of bad experiences in the past, even when the product is indeed viable in its current state. My father stopped buying Pontiac cars when his third Pontiac developed the same premature problems that the first two had. Can you blame him? I've spent the better half of my professional life learning the bitter lesson that you can't depend on Microsoft products for one reason or another, after starting out as a Microsoft supporter. I'd consider myself a fool to continue to give Microsoft a chance, when in every single experience with them in the past they've severely disappointed me. Can you blame me?
If you think the only reason people stay away from Microsoft is that they're just Microsoft haters and for no more specific reason than jealousy or mistrust of big companies, then you've been living with your head in the sand (or you don't have enough general computing experience to know better.)
One more point, what's wrong with hating Microsoft anyway? Why should you even care if someone does? It's just a software company! Do you have Microsoft stock perhaps? If you want to rail against bigotry, fight racal or sexual bigotry and do some good instead.
WML is actually a lot more than simply a cut down version of HTML. While it is true that gateways exist to take HTML pages and turn them into WML, WAP in reality does a lot more than that.
First of all, WML is designed for presenting data on unorthodox screen sizes, and uses a "card" system to show pages on a small screen. It is a lot more efficient, but more limited at present, than HTML.
Secondly, the WAP gateway takes this WML content and compiles it, so that it is firstly much smaller, and secondly it executes on the client device much faster (remember, most mobile phones aren't yet endowed with Pentium III Xeon performance!)
This together makes WAP that much faster and better suited for use over a wireless connection than HTML.
David
Markus
--
You might want to look at MMBase.
It's a very nice open source dynamic content management system. It seems to be wap enabled also.
Roxen (www.roxen.com, distributed under GPL) could be able to handle both Servlets and WAP.
I have never tested those capabilities though.
In either case, as the poster above said, the real point of XSL is that you don't have to be a full fledged programmer to use it. While XSL can definitely be painful, I think it is better than writing a computer program in {Perl,Java,Python,*} to do the same thing. Unfortunately, it's not easy enough for just anyone to pick up, so it doesn't completely allow for designers or HTML coders to assume all control of layout without an engineer showing them the ropes, unless of course they are particularly bright and can pick it up.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
A better approach is to statically do the base XML to HTML conversion, with JSP (or PHP, mod_perl, whatever) to introduce the final dynamic content. (I.e. convert the XML to a JSP with scriptlet tags for the true run time dynamic content.) Caching algorithms would alleviate this, but I don't see the advantage of doing it runtime, when it works just as well doing it statically. Even with caching, your performance will clearly be better.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
I think something like XML/XSL at compile time, followed by JSP/PHP/whatever at runtime, works better, because you have the same content/design separation as XMLC, but not the performance implications.
BTW, even though you're speaking of WML in particular, I'm speaking of content serving in general.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
There is a difference between static and dynamic content, vs. how static content is generated. For example, a basic web page that doesn't vary for anyone could be generated on the fly with XMLC/Cocoon, but it's still essentially static content. If the page shows the current time on each access, then it's dynamic, even if it's a simple PHP HTML template.
So, for basic content generation, I think XML to HTML is a great idea. XMLC is one solution. XSL is another. The problem with XMLC is that it only works at run time, which is a non-trivial performance hit. (Especially when you consider static content, that can no longer be served as a plain HTML file, and has to go through a servlet engine.) With XSL, and perhaps other technologies, the XML to HTML processing can be done at build time, resulting in HTML files that can be served faster.
The reason I mention JSP or PHP is because then you have to insert dynamic content into the resulting HTML, and at that point, you need JSP/PHP/whatever. But keep in mind that if you apply the content/logic separation with JSP/PHP clean, then making sure that your XML to HTML translation adds the right JSP tags is easy. So, you still maintain your content/logic separation throughout the whole process. And you get an additional performance boost over XMLC because you are simply outputting new strings, as opposed to manipulating a DOM tree, which is harder and slower.
Bottom line: XMLC combines static content generation with dynamic content generation. Both are slow, because (a) it happens at run time, and (b) DOM manipulation is slow. My suggestion is to move static content generation to build time, and use a simpler technology, like JSP, that gives you the same content/logic separation, to do the dynamic stuff. This still involves using XML to keep the distinction between logic and presentation nice and clean.
----------
In a real emergency, we would have all fled in terror, and you would not have been notified.
While this isn't a possible solution for the original poster, because he's tied to servlets, it might be a possible solution for others.
PHP allows for effective session management, and with a bit of work, I'm sure you could make it compatible with the WAP cookie things. It might even be possible to do so without having to mod the base system.
There are also several good looking WAP/HTML gateways either in early production or late development, and I'm sure those will be interesting.
Note that I have not looked much at either the gateways, or the possability of server side cookies in PHP. I'm just throwing the idea around incase it might help anyone.
Terje Elde
BTW, Enhydra *is* open source. It supports session via cookie/URL rewriting. Session is not tied to IP address.
Actually, you generally generate the DOM tree before hand. It's true that loading a DOM tree can be taxing, but I wouldn't guess that your average WML document (meant to be displayed on a cell phone) is going to be of the magnitude that would put much of a strain on even the lamest of app server boxes. Even with a bit of performance hit, the design clarity that something like XMLC provides (as opposed to embedded code-presentation mixes like JSP, PHP, etc.) is worth it.
You are right that a DOM tree must still be instantiated at runtime. The point I was making (as you have gathered) is that you don't have to parse and create the DOM from scratch at runtime.
When talking about how expensive a procedure is, you need to consider both the runtime performance/resource utilization as well as the cost of maintenance. You say that JSP/PHP give you the same content/design separation as XMLC, but that just isn't true. I have done a fair share of JSP in which the presentation has changed rapidly on top of static business logic. The bottom line is that these technologies just aren't good for that. Somewhere/somehow somebody who knows about programming has to get in the mix. Code (albeit small chunks) *are* embedded into the middle of the presentation.
XMLC, on the other hand, allows for the kind of separation in which a static HTML (or WML) mockup can be uploaded to a server by a designer and changes will automatically take effect. The cost to maintain XMLC based projects vs. JSP based projects is significantly different.
On the topic of expensive operations, just how expensive is DOM manipulation? When you already have the document parsed and the DOM created, where do you pay the performance prices? I haven't done a lot of benchmarking (have you?), but it would seem to me that the only real price you would pay is that of memory consumption. Otherwise, you're talking about loading an existing class into memory and executing lightweight methods on it. With the right sort of caching, I don't seem this as being much of an issue.
http://www.enhydra.org Has a servlet engine (built around tomcat) with an Apache/ISS/Netscape based load balancer. Built-in support for WML via an extension to their GPL'd XMLC technology.
I have to disagree, WAP/WML has a very good design, and I think that we'll see it for quite a while. There's only going to be more appliances that are internet ready, which require very prudent use of requests. The "card" design of WML allows you to send multiple "pages" to these devices in one request.
It likely will be extended in the near future to add new features like it's bastard cousin HTML. I see devices becoming more empowered, but I think WML will be used for quite some time. I think it has far too much momentum for it to just die out.
Beware InstantDB. Tried to use it a couple of months ago with a ad server and had nothing but problems. Major memory hog made worse by memory leaks and poor performance. I switch to MySQL and performance tripled and it hasn't crashed since.
Cookies and wap don't go together afaik. You should make the session-id in a hidden value in the wmlfile. You can do this with postfield. You'll have to make sure your sessions time out and some more.
But it is the way to go.
Also. You've got to look out for & and $. The need to be encoded no matter what. Or the gateway will go berserk (i.e: not respond)
-- Thorkild
www.orionserver.com is one of the best J2EE servers out there. It will support servlets, JSP, EJB, JNDI, etc..
Justen Stepka
By the way, here is some more info :n hydra.html, with a nice mini-howto and a HelloWAP application !
http://www.wirelessdevnet.com/training/WAP/wape
The solution is to ensure that your 'pages' (I'm quoting this since the correct WAP term is 'decks') are not cached. There are several ways to do this. I suggest that you read the WAP FAQ at wap.colorline.no/wap-faq.
Roxen Web Server (former Roxen Challenger) is a quite good choice (amongst many others it has native servlet/Java modules support and speaks WML natively (also knows to generate WBM)). Plus, it's GPL'd.
Petru
Enhydra also comes with InstantDB, a pure-Java RDBMS designed for the web and Enhydra Director, a very good load-balancing tool.
Other nice features are the MultiServer which, among other things, allows easy local developement without needing to setup a server like Apache. It also allows debugging live servlets.
All in all, Enhydra is great! Use it!
Adam
P.S. Also, there are facilities to use an IDE like JBuilder or JDeveloper with Enhydra.
--
Adam Sherman
--
Adam Sherman
Freelance Geek
This may be slightly off topic but, i was just wondering what the state of slashdot's wml site is like and if rob and co. are still working on it. so far i can get the headlines but was hoping that i'll be able to read the stories as well. With the nokia 7110 i cant follow on from the headline links.
:)
ah well. hopefully soon i can read slashdot from just about anywhere
Call me a simple-minded clod, but what is wrong with just putting the session ID into a cookie instead of going through all the trouble to embed it into every URL? Tarzan not understand!
If you don't mind managing your own session table, you can do sessions with a slight variation on URL rewriting. Instead of embedding the session ID in the parameter section of the URL, you put it in the path section. You then have a servlet that is invoked for every reference to that path.
For example, you set up a servlet to handle /appdir/. Now every request for /appdir/, like /appdir/index.html goes through the servlet. The trick is, you generate a random session ID and send the user to something like /appdir/9859738579834/index.html. When they click on a link in index.html, assuming the link is relative to index.html, the phone will request /appdir/9859738579834/whateverlink.html or a servlet/JSP. All you need to do in your /appdir/ servlet is parse the key, look up the session-oriented data, place it in the request object and then do a forward to the real page.
There was a message about something similar (doing multiple sessions for a single browser instance) on the JSP interest mailing list.
I haven't tried it for WAP, but I suspect it would work.
In case anyone is interested, you can use this servlet to insert the session ID into the URL and filter the ID out of the path, even if you use a WML file. This doesn't seem to work in the Phone.com simulator, though. It works fine in the Nokia. I think it may have something to do with the Phone.com server supporting cookies, but I can't be sure. If anyone gets it to work, let me know. I'll keep playing with it, too.
/appdir " +fullPath).
-------------------------------------
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class FakeSessionServlet extends HttpServlet
{
public void service(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException
{
response.setHeader("Content-Location", request.getRequestURI());
String extraInfo = request.getPathInfo();
// Locate the next slash in the path (assume there is one at position 0)
int slashPos = extraInfo.indexOf('/', 1);
if (slashPos > 0)
{
// Get the subsession id and the real path to access
String virtSession = extraInfo.substring(1, slashPos);
String fullPath = extraInfo.substring(slashPos);
if (fullPath.indexOf(";jsessionid") < 0)
{
fullPath = fullPath + ";jsessionid="+virtSession;
}
// Assume the real path is under
getServletContext().getRequestDispatcher("/appdir
forward(request, response);
}
}
}
---------------------------------------------
Using Resin, you need to add the following items to your resin.conf file:
---------------------------------------------
<servlet-mapping url-pattern='/appsession/*' servlet-name='fake-session-servlet'/>
<servlet servlet-name='fake-session-servlet' servlet-class='FakeSessionServlet'>
</servlet>
<path-mapping url-regexp='^/appdir/' real-path='h:/jprogs/sesstest/'/>
<mime-mapping>
<extension>.wml</extension>
<mime-type>text/vnd.wap.wml</mime-type>
</mime-mapping>
---------------------------------------------
Now, you send your phone to this main page that redirects you through the FakeSessionServlet to get to the real main menu:
---------------------------------------------
<%
response.sendRedirect("/appsession/"+
session.getId()+"/Menu.wml");
%>
---------------------------------------------
The menu.wml file looks like this:
---------------------------------------------
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="mainmenu">
<p>
<a href="Test1.jsp" title="Put Into Session">Put Into Session</a><br/>
<a href="Test2.jsp" title="Get From Session">Get From Session</a>
</p>
</card>
</wml>
---------------------------------------------
The Test1.jsp file looks like:
---------------------------------------------
<%@ page language="java" contentType="text/vnd.wap.wml" %>
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<%
session.setAttribute("foo", "Bar!");
%>
<wml>
<card id="test1">
<p>
I put <%= session.getAttribute("foo") %> into the session.
<a href="Menu.wml" title="Back to Menu">Back To Menu</a>
<a href="Test2.jsp" title="Get From Session">Get From Session</a>
</p>
</card>
</wml>
---------------------------------------------
Test2.jsp looks like this:
---------------------------------------------
<%@ page language="java" contentType="text/vnd.wap.wml" %>
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//WAPFORUM//DTD WML 1.1//EN"
"http://www.wapforum.org/DTD/wml_1.1.xml">
<wml>
<card id="test2">
<p>
I found <%= session.getAttribute("foo") %> in the session.
<a href="Menu.wml" title="Back To Menu">Back To Menu</a>
</p>
</card>
</wml>
---------------------------------------------
You just need to explicitly store the session ID in a cookie. After the section:
if (fullPath.indexOf(";jsessionid") < 0)
{
fullPath = fullPath + ";jsessionid="+virtSession;
}
Add this line:
response.addCookie(new Cookie("jsessionid", virtSession));
Frogg mentioned that he has something that did this and sure enough, that was the trick. Thanks for sharing, Frogg!
WAP and WML are things that allow webpages to be seen over portable conncections like web enabled cell phones and PalmPilots...From what little i have read about it, it takes the HTML and strips thing like img tags and such and parses it into a form portable devices can understand
You should definitly check out the Cocoon project. XML, XSL/T and whatever you might need.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Sorry I forgot to post the URL..
www.hawhaw.de...
Cheers,
-/r
- ramas opines !!
If you can go the PHP way there is the option of going with the hybrid web server HAWHAW - HTML and WML Hybrid Adapter Webserver which delivers content depending on the browser capabilities.. so you no longer have to create separate HTML and WML pages to deliver similar content..
.. wonder if it helps the the person who wanted to use Servlets/JSP on a non IIS server but this info might be useful to others,
Check it out
Cheers
-/ramas
- ramas opines !!
To use URL rewriting all of the links of the template need to be interpreted by a servlet. This can be done one of two ways, by using a HTML parser to find all of the links and manipulate them, or by using some kind of tag in your template to specify a link. The first seems way to CPU intensive to scale well, and the second is going to be nasty for the web designers.
The concern that the first might be "way too CPU intensive to scale well" presupposes that the page will be parsed by the server on-the-fly every time it is serverd.
Why not precompile it, having the compiler insert the tags?
Then the web authors can work on normal HTML, directly or using arbitrary tools. But the server can work with the fast, tagged form.
There are several ways to manage the compilation so the designer's process is either unmodified or requires just an extra click or so to view the page-under-construction as it would be seen externally.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Thanx to all the guys and grrls that responded. We sorted the problem at our end, with out making any chages to the existing Servlet model.
The way we got around it was to make the first page that is called be a Servlet that will generate the WML. This way the first session id is not superceded by a second session id created for the WML. This is the same session id that gets passed around between all the rest of the servlets now.
We found that the solution requires WAP 1.1 on the gateway/phone - WAP 1.0 doesn't work - we don't know if that is the gateway or the phone causing the problem, but we suspect it to be the gateway.
Thanx again for all the info,
ys
-- "To ask a question is to show ignorance; Not to ask a question means you'll remain ignorant."
IIS doesn't even have a decent servlet story. To run a Java servlet on IIS requires a per web server licensed add-on like JRUN. With Apache on the other hand, you have JServ which is open source and free also. So, unless WAP is all bottled up by M$ I see no reason you need to use IIS for this project at all. Even if WAP was bottled up (I presume at server side) then you could use a CORBA-COM bridge to call the M$ WAP stuff. Presumably your clients are not M$ restricted.
Judging from the Wireless Session Protocol Specfication at http://www.wapforum.org/what/technical.h tm it looks like most of the session handling stuff is
geared to handling the connection between the phone and proxy.
Well, of course! That is because the air interface (or radio-transmissio part) is located in that segment, and which is the source of interruptions, timeouts, lost packets and delays. The air interface is much less reliable that the Internet in general (we ae talking celular network here, not (yet) 3G), so all those complicated handshakes, receipt and delivery confirmations explained in the WSP (wireless session protocol) specs make tremendous sense. The WAP protocol stack is a little bit like X.25, but at even lower speed.
However, WAP is also scalable, it's designed to support future air transmission techniques, coming with G3, like GPRS, for example, or some of those non-cellular radio networks you already have in some US cities (Ricochet, for example).
Sigged!
What is so difficult about it? I actually have signed a NDA so I am not going to tell details here, but our solutions all use Netscape Enterprise Server, but I have also used Apache on Linux to serve WAP. Actually WML and WMLS. The logic behind generating WML and WMLS is the same old **** that today generates dynamic HTML.
Really no big deal, just the syntax is different, and the mind has to be set to think little (cell phone display and keypad).
Sigged!
WAP is either a White Anglo-Saxon Protestant... or go to Wapforum.org
hehe, OOPS.
(my apologies to all of the WASP's I just insulted)
(As near as I can tell, the license agreement is meaningless; perhaps someone with more legal understanding can explain what they get from this that is not already granted to them by law ?)
You might also be interested in this slashdot article which talks about patent and licensing related issues in WAP.
On the whole, there seems to be enough uncertainty associated with the WAP licensing/patent issue that I decided not to use it for what I was working on.
. . I've read this week!
___
people get confused because you need a WAP Gateway to handle transforming wml into the approp format before it reaches the wap browser. but that is mostly handled by those providing the devices with wireless access anyway.
The thing to realize is that in WAP you have a proxy/gateway sitting between the cell phone and web server.
Judging from the Wireless Session Protocol Specfication at http://www.wapforum.org/what/technical.h tm it looks like most of the session handling stuff is geared to handling the connection between the phone and proxy.
In a perfect world we'd simply use cookies to track session just like in HTTP, but sadly these don't seem to work reliably yet in WAP. In the meantime, you'll have to resort to either passing session identifiers as form variables or else in the URL.
For anyone interested, I'm working on an overview article on how to add wireless users to your web service. The draft lives at http://dev.arsdigita.com/asj/wireless/.
Everybody is having trouble trying to build wap pages or more important trying to convert old html stuff into wap.
Since the java servlets are no problem in this case I'd reccomend you'd check out the WAPorizer at Dimon software.
It automatically converts html into wap and creates different wml pages for different screen sizes of the phones.
----------------
Páll Melsted
melsted@hie.is
Stupidity is like radioactive material, it can be used for good or for evil. But you don't want any on you!
They are currently in the process of upgrading to the servlet 2.2 API, and their FAQ details the finer points of running Enhydra with Apache and Apache JServ.
All in all, it's a fine solution. It took me just a little bit of research, but once I got it up and running, I found that it was very reliable, and more than ample speed-wise.
Hope this helps...
Nearly anything that can serve HTML can serve up WML
Serving up WML is easy (as you say). WAP needs some extra stuff doing though, mainly to deal with handling session state in an entirely different way to the traditional HTTP (and thus the cookies are different too).
Think about it. Phones have fixed IDs (from the telco network), but nowhere big enough to store client-side cookies.
http://www.uklinux.net/ is a UK free linux ISP to do this. ! Is any one making a list of these things ?
Get a life get a motorbike !
I don't see why you would need a special web server, etc. for WAP... it's just a different HTTP content type... and then the WML isn't any more difficult than HTML. What's the big deal?? yer_blues
Hell, I thought it was We Are Satans People ... :)
Modular programming results in a performance hit too, but in most cases it's worth it.
I don't see what the fuss is, to be honest. WAP is the easiest technology conversion I've had to make in the last two years.
.wml files ( or anything else ) to text/vnd.wap.wml and that's it! WAP server setup complete.
HOW to do WAP ( Taken from http://ali.as/ )
Simply set the MIME type for
Example: http://ali.as/wap/wap.wml ( doesn't work in a normal browser )
The other thing you want to do is set index.wml as an index file... since every keystroke they have to type in will be a pain for mobile users, at least the phone ones anyway.
Next, CGI ( or servlets, or whatever ).
Given you now know the magic WAP MIME type ( text/vnd.wap.wml, simply get your program to spit out the MIME type. Perl example would be
print "Content-type: text/vnd.wap.wml\n\n";
I imagine it would not be THAT hard to change the Content-type line of the header in JSP... A collegue is mentioning to me that all you need to do is something like
Method addHeader( 'Content-type', 'text/vnd.wap.wml' ); in the interface HttpServletResponse in the class javax.servlet.http
All you have to do then is write in WML, which isn't that difficult to learn.
To do that, I highly recommend the WAP Phone Simulator provided in the Unwired Planet SDK 4.0
AdamK
Just set up apache and add wml to the types defined in the httpd.conf file.
The real work of WAP is done by the gateway at the service provider all you do is serve WML pages to that like you would html.
Javaserverlets shouldn't be a problem as long as you can find a way of maintaining the states, serve the data in chunks using the WML methods provided for that reason.
I serve WML with apache, php, mysql no problems.
enjoy
blog and junk
something strange happened to the link! here it is again.
You can't handle the truth.
WTF is wrong with Yahoo Geocities? Here is the fucking link: http://www.geocities.com/SiliconValley/Lab/5200/co mpetitiveanalysis.doc
You can't handle the truth.
Obviously, that is what the article is all about, they want to set the cookie on the device, not on the WAP server.
Anyway, Mr.G. talk to you later.
You can't handle the truth.
Forgot to mention:
There are also multiple Servlet Engines available.
There is New Atlanta Servlet Exec, there is IBM Servlet Engine used in WebSphere, there is a servlet engine from Sun, there is Caucho servlet engine for Apache *nix or JServ, there is a webserver Jasper that currently confirms with Servlet Engine 2.1 specifications, there is Allair JRun, there is 10BaseJ servlet engine, there is an engine called cocoon.
Basically there are so many more of them now than there were 2 years ago when I started looking at New Atlanta that it's easy to loose your head.
All you really need is an engine that supports Servlet Engine 2.2 specifications and that is fast reliable and runs well under your OS. Make sure that if you get an engine that it can be pluged in as a filter into your current WebServer, otherwise you'll have to get yourself a whole application server or another WebServer.
You can't handle the truth.
You can use the following solutions:
www.davinci.ca (here is the competitive analysis document I had to write: download)
www.724.com
www.microstrategy.com
www.zope.com
www.orionserver.com
The fact is that neither phones nor PDAs currently can not accept cookies. Obviously this is a memory and bandwidth restriction and a good one - imagine you have a phone and every site you visit sets a cookie on it, pretty soon you'd run out of space.
To keep your user's session you can use either URL Rewriting technique or a server side Session identifier (the later one is harder to implement for unregistered users.) Don't forget that a user can have more than one session at a time on any server with multiple devices.
Look at 'resin' if you need good authentication and session implementations.
Good application servers also provide all possible techniques for storing session: Cookies, URL Rewriting and server side sessions, so check out these: www.weblogic.com (www.bea.com), www.gemstone.com, www.orionserver.com, www.zope.com, www.websphere.com
The product I am working on currently is an XML server that allows easy implementation and separation of business logic from layout module and has a granular cache for storing data results from varios functions for all users, so check out 'Trinity' project from www.davinci.ca
In general, there are many solutions but none will help you to store the cookies on the mobile device itself.
Good Luck.
You can't handle the truth.
Serving WML really involves three major components: the phone, a WAP gateway, and an HTTP server.
The phone has a conversation with the gateway using the WAP protocols over some bearer network. That conversation may be either session or non-session oriented, and may be either secure or insecure. Your carrier's GSM network is one option for the bearer; a dial-up PPP connection is another. (If your phone is using a dial-up connection, it will need to connect with a WAP gateway using UDP ports 9200-9203.) In any case, the phone does not actually open an HTTP connection directly to your HTTP server; the connection the phone sees is to the gateway.
The WAP gateway makes the actual connection with the HTTP server. It's basically a proxy server. The WAP gateway may open a separate HTTP session on behalf of each phone, or it may open a new session for every request.
I'm not aware of any WAP enabled phones that store their own cookies. However, the gateway may support cookies on behalf of the phone, though some will downgrade persistent cookies to session cookies. Even if the gateway stores persistent cookies, there's still the problem that the phone may not always use the same gateway, so the persistent cookie store may not be available.
The result of all this is that your HTTP server may or may not see session cookies, and persistent cookies may or may not really persist. About the only thing that is pretty reliable is that you'll get lots of requests from different users using the same gateway IP.
One possibility to deal with missing session cookies is to use URL mangling. This is discussed at some length in another thread, so I won't go into the technique here. However, there are a couple caveats:
Just have a look on this link http://www.bea.com/press/releases/2000/0508_Nokia. html
WML is ridiculously easy to get running using Servlets. Trust me, I've done it.
The main problem the author seems to have is that he hasn't read the Java docs.
Use URLEncode() to automagically store all the session details in the URL.
And use response.setContentType("text/vnd.wap/wml");
And that's it!
This will work on pretty much and servlet-capable server. Some, like Orion Server can even be set up to recognise whether cookies are present or not, and handle the URLencoding with no effort on the writer's part.
Any other problems are most likely due to the various bugs involved in different companies' implementations of WML.
-Ciaran
WAP is definitely not very well designed. There are good ideas, but not a single one is implemented 100%.
-You have a -tag to go back one page, but not several
-You have variables, but can only set them within anchors, prevs. No chance to change a variable when actually *entering* a page
-You cannot send postfields to an image
-There is no standard for a WAP browser to report its display size to the server - which would be very useful for dynamic charts or other images that can automatically resize to fill a page.
-
-
Not counting the millions of bugs most WAP browsers have in their implementation of the WAP caching model. You have the alternative of either implementing many workarounds or completely disabling the cache - guess which way most page writers choose.
In short: WAP sux.
Word on the street suggests that Hypersonic SQL is superior to Instant DB in terms of functionality and performance, but has more bugs than InstantDB (I cannot verify this personally as I have only used Hypersonic SQL, so consider the above hearsay until verified independently). It is, however, open source (on Sourceforge) and implemented in pure Java. Documentation as to source is okay and it is simple enough to dig into most parts of the source without having to be a Java guru. No concrete information on scalability to real loads at this point, but it works well for development and prototyping with simple to moderate dataabse complexity. Another advantage is its small footprint and different operating modes, allowing it to be embedded in other applications (it can even realistically run in an applet).
Reinventing the wheel is also a bad thingTM
You could transform anything to anything using Perl or Java, why bother with XML in the first place? Alone XML is just a simple syntax to program with, but with XSL it ought include every possible way to program with it doing stuff that really should get you migraines using perl instead.
IMHO I hope for W3 standards to make perl programming obselete for static content casting with lots of ready-to-use XSL examples to use.
Though you might notice that I haven't really gotten into it myself, but the XML syntax with all those BRA, SLASH, KET's just is to much to hack with - they should have stuck with some wierdo TEX all char's are active syntax instead : )
Transforming XML-conformant data to a rendering format using XSL will give you a migraine for any non-trivial layout. You would be better off translating content on the fly using mod_perl - while perl is not a W3 kinda-standard, it certainly has more robust support in web servers, and unlike XSL, its a real programming language. If you don't like perl, there are Java and Python equivalents - my point is - you will want to use a real programming language unless you really enjoy serious pain.
Our solution was to roll our own, in Java. Works great. All it serves are JServlets and WML.
Enyhdra is a possiblity.
The next generation of phones won't need WAP at all. They will have larger screens, the Symbian EPOC OS built in, 128Kbps download speed and fast ARM CPUs.
It doesn't really make sense to re-develop entire sites for WAP when the next generation phones do not use it.
Government of the people, by corporate executives, for corporate profits.
Great topics here -- I thought I was going to have to use the specs on wapforum.org to write my own; nice to know there are so many options already available..
I hope you want to find out how to setup a webserver to serve WML (Since the WAP part happens after a WAP gateway, pulls the WML content from a WML webserver and sends it over the Internet). I have it working and have tested this against real and emulator phones. I run Apache with JServ. In simplest of requirements, all it requires is setting up the mimetypes (atleast for vnd.wap.wml and possibly 4/5 more). Then in your servlet you will setContentType("whatever you want to server"). Note that it is also possible to setup the webserver to intelligently serve pages depending on the end-agent (browser?!) and serve either wml or html etc... in Apache.
WAP doesn't create it's own session ID's. Session ID's are set by the Servlet engine. How those ID's are passed around between GET/POST's is different. If you are depending on Cookies for session management, then you are going to run into problems with WAP phones, Palm devices and people who disable Cookies. Stay away from using Cookies for session management, use URL rewriting instead. Posted by Cliff on Sunday May 21, @12:17PM from the getting-it-working dept. Yousef asks: "We're trying to develop a WAP enabled Webserver, that can work with Java (Servlets). Currently the only working option is M$ IIS running the New Atlanta plugin. Now I'd rather NOT run IIS, so if anyone else has a solution to this, it would be much appreciated. We've tried Inprise IAS and Apache JServ (We're deploying to a Sun Solaris box). Any help would be nice. Getting the servlets to run is quite easy -- The problem is getting them to work with WAP!" "WAP creates its own session ids, and that stops other serverside objects from sharing the same objects. In short, we have an existing Servlet based system. Now we are trying to incorporate WAP into it (WML). It seems to us as though WML passes cookies around differently to HTML: HTML stores them with the browser, and WML stores them on the server. We've tried just about every server under the sun, and they all behave in the same way."
Theo. Antoniou