Web Servers To Handle Java Servlets And WAP? 111
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."
Roxen (Score:3)
buyer beware (Score:1)
just something to think about..
cheers,
-o
Forget about WAP (Score:1)
Just my 2c
J.
Re:WML can work anywhere.. (Score:2)
Re:WML can work anywhere.. (Score:2)
Now it starts to make sense..
WML can work anywhere.. (Score:4)
Re:Enhydra (Score:2)
-Peter
Re:Slashdot and wap (Score:1)
www.slashdot.org should work
HTH
Re:Excuse my ignorance, but... (Score:1)
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.
Use URL-rewriting based session management (Score:3)
"Wap-Enabling a Website with PHP3" (Score:3)
Besides, check out the rest of their website. All around cool guys...
Re:"All around cool .." (Score:1)
Mike
Re:Use URL-rewriting based session management (Score:1)
That said, does WAP include ECMAscript (essentially, standard Javascirpt)? If not, then this solution won't work for WAP devices...
Re:Enhydra (Score:1)
php4 [php.net] 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.
IBM WebSphere Transcoding Publisher (Score:3)
Wapsody [ibm.com] is a Java WAP development environment. Might find that worth looking at too.
Re:Slashdot and wap (Score:1)
Also, you can go through the google search engine, which will translate the site into wml...
Re:XSL Considered Harmful (Score:1)
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 [exceloncorp.com] 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 [headlinewatch.com], where it provides all HTML content, as well as RSS and WAP feeds.
Other Options... (Score:2)
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
XML + XSLT = WAP (Score:5)
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 [apache.org] (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 [caucho.com]. 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.
WAP and cookies don't mix with WAP 1.1 (Score:1)
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.
Re:WAP has a very limited future (Score:1)
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.
Re:Slashdot and wap (Score:1)
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.
Get a clue (Score:1)
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.
Re:Excuse my ignorance, but... (Score:1)
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
Re:Use URL-rewriting based session management (Score:1)
There is no such thing as server-side DHTML. Unless you're talking about dynamically-generated pages, which is exactly what the person you're replying to had a problem with.
and to allow people to browse off-site and return to the same session we dropped a cookie which also had the sessionId in it
The whole point of this discussion was: in the absence of client-side cookies, how can we maintain state? Your solution: use cookies!?!
HTH
IDTID (I Don't Think It Did)
-bp
Re:Orion Server (Score:1)
Markus
--
Re:Use URL-rewriting based session management (Score:1)
At lest, that's the problem I've found using URL rewriting as session management. It's not so bad when using embedded HTML in your servlet, but that is just a bad way to do servlets in the first place.
MMBase (Score:1)
It's a very nice open source dynamic content management system. It seems to be wap enabled also.
Roxen (Score:1)
I have never tested those capabilities though.
Re:Use URL-rewriting based session management (Score:2)
Anyone know any way around this?
----------
Re:XSL Considered Harmful (Score:2)
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.
----------
Re:Enhydra: beware XMLC (Score:2)
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.
----------
Re:Use URL-rewriting based session management (Score:2)
----------
Re:Enhydra: beware XMLC (Score:2)
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.
----------
Re:Enhydra: beware XMLC (Score:2)
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.
----------
Solution for others: PHP and WAP gateway. (Score:2)
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.
Re:Use URL-rewriting based session management (Score:2)
Scaling is a function of the workload, not of the CPU. If the CPU speed is half or twice, scaling is still proportionally the same. In other words, if you need twice the CPU to get the job done because the code performs at half the speed, then that's going to be the case at any workload level. What a higher CPU usage of something like HTML parsing will do is just make your tolerance threashold be reached sooner. Funny how it is people will switch and say CPU is not the issue if I bring up how their favorite tool is a CPU hog.
So.... get the best of both worlds. What you need is pre-parsed HTML templates that generate your servlets. Parse the HTML once, and the servlet code then "identifies" the session key insertion points by means of its (now) built-in code. Then compile the servlets down to binary once debugged.
Re:Enhydra (Score:1)
Re:Enhydra: beware XMLC (Score:1)
Re:Enhydra: beware XMLC (Score:1)
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.
Enhydra (Score:5)
Re:WAP has a very limited future (Score:1)
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.
Re:Enhydra (Very Good Tool) InstantDB not!!! (Score:1)
WAP and sessions (Score:2)
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)
Orion Server... (Score:1)
Re:Enhydra mini-howto + sample app (Score:2)
http://www.wirelessdevnet.com/training/WAP/wape
The fault is in your servlets not the web server (Score:1)
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 [colorline.no].
Roxen (Score:3)
Roxen Web Server [roxen.com] (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.
Re:Enhydra (Very Good Tool) (Score:1)
Enhydra [enhydra.org] also comes with InstantDB [enhydra.org], a pure-Java RDBMS designed for the web and Enhydra Director [enhydra.org], 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
Re:Use URL-rewriting based session management (Score:1)
If someone registers credit details at a site and then emails a link to a friend then that could be a potential security problem.
+++++
Re:Use URL-rewriting based session management (Score:1)
Somebody from bigcompany.com is likely to follow that link within the 20 or so minutes it takes the session to expire. If the session expire time is shortened then the site kicks people mid surf - also not desirable. If the victim keeps browsing the site for a while then the session could be open for hours after the mail is sent. Anyone in their company could buy books with their card.
+++++
Re:Use URL-rewriting based session management (Score:1)
Our session management code took care of resolving any conflicts between the two sessionIds.
I've not got enough experience of WAP to be able make any useful comparisions yet.
HTH,
fRoGG
Slashdot and wap (Score:1)
ah well. hopefully soon i can read slashdot from just about anywhere
Re:You can also embed the session ID in the path (Score:1)
You can also embed the session ID in the path (Score:1)
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 [sun.com].
I haven't tried it for WAP, but I suspect it would work.
Re:You can also embed the session ID in the path (Score:1)
The problem in the WAP arena is that there are a lot of phones that don't support cookies.
Source code for session servlet (Score:2)
-------------------------------------
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>
---------------------------------------------
Fix to allow phone.com browser to work, too (Score:2)
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!
Re:Excuse my ignorance, but... (Score:4)
Re:Use URL-rewriting based session management (Score:1)
Anyone know if there's a way to enable URL rewriting when using Tomcat?
xml.apache.org (Score:5)
You should definitly check out the Cocoon project. XML, XSL/T and whatever you might need.
Re:WAP enabled servers without IIS (Score:1)
www.hawhaw.de...
Cheers,
-/r
WAP enabled servers without IIS (Score:2)
Check it out
Cheers
-/ramas
Sounds like your web designers need a compile step (Score:2)
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.
We have a solution. (Score:1)
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
AFAIK (Score:1)
Re:Remember it's a different architecture (Score:2)
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).
I don't get it... (Score:3)
Really no big deal, just the syntax is different, and the mind has to be set to think little (cell phone display and keypad).
Re:WML can work anywhere.. (Score:1)
I think the easiest, most cost effective solution would be to suck it up and use IIS. The next best might just be to change the way you maintain session. (however, I'm not familier with Enhydra...)
Re:Excuse my ignorance, but... (Score:2)
Re:Excuse my ignorance, but... (Score:2)
(my apologies to all of the WASP's I just insulted)
Re:Other Options... (Score:1)
Why the click-through spec license ? (Score:2)
(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 [slashdot.org] 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.
Re:That's the funniest thing . . (Score:1)
___
Re:WML can work anywhere.. (Score:1)
Re:WAP (Score:1)
Re:Use URL-rewriting based session management (Score:1)
<a href="/servlet/ServletName?sesid=<!--#echo var="sessionid"-->">link>/a>
Check out the package (it's GPLed!) at http://www.freecode.com/cgi-bin
Remember it's a different architecture (Score:2)
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 [wapforum.org] 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/ [arsdigita.com].
wap is the problem, this is the solution (Score:1)
Since the java servlets are no problem in this case I'd reccomend you'd check out the WAPorizer at Dimon [dimon.is] 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
Enhydra (Score:3)
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...
Re:XML + XSLT = WAP (Score:2)
By creating content as XML, you can now create XSLT scripts to transform [...] XML content into XHTML or into WAP.
Dream on 8-(
Like everyone and their dog (well, everyone who's dog is an XML/XSL geek), I too thought this was the way to go. Bitter experience shows that although it's technically possible, the sheer broken-ness of WML makes it almost useless. There are two big problems you need to work around; neither of which is conducive to an easy solution in XSL alone.
What this means in practice is that your presentation-free XML content needs to be heavily marked up with "WML deck - Cut here" markers, so that when you slice it into decks, then you break it across somewhat functional boundaries. Break it in the middle of (e.g.) a news story and the phone has to go and deal with both decks, just as the user scrolls to read it. More traffic, more delay as the phone leaps around from deck to deck, generally a pretty nasty way of mis-using WAP.
For interface building, I managed to make it work with XSL transforms of my common XML. It still sucked - what I'd built turned out to be a standard interface hard-coded in XSL, with a bit of templating based on the content of the XML. For the one example I was looking at (a newsfeed service, to re-invent the cliche), this worked OK, but my XSL was entirely dependent on the purpose of this content. There's no way I could even have re-used it for a weather forecast or traffic service, without entirely re-coding the XSL.
The more I see of WAP, the less I like it. I now see the point of 4K Associates and their "WAP considered harmful" piece of last year. XHTML-Basic [w3.org] is a much better thought out protocol, and it doesn't have this problem of being squeezed so thin that it's no longer big enough to support palmtops.
I'm not convinced of the commercial future of WAP. Wireless wil be mega-, mega-huge, but I don't think it's going to be built out of WAP. You still have sourcing difficulties for handsets (in the UK) and if the handsets aren't out there, then there's not the same drive to build content. Any new tech in this market only gets one short slot at the championship, and I think WAP might miss it in favour of the Next New Thing.
Roll on Bluetooth.
WAP != WML (Score:3)
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.
WAP on Free ISP (Score:1)
WAP (Score:1)
Re:Excuse my ignorance, but... (Score:1)
Re:Enhydra: beware XMLC (Score:1)
Modular programming results in a performance hit too, but in most cases it's worth it.
How to do WAP the easy way. (Score:1)
HOW to do WAP ( Taken from http://ali.as/ [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 [phone.com]
AdamK
Re:Enhydra (Score:1)
APACHE!!! where is the problem (Score:1)
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
Re:List of your choices: (Score:1)
Re:List of your choices: (Score:1)
Re:List of your choices: (Score:1)
Anyway, Mr.G. talk to you later.
Re:List of your choices: (Score:2)
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.
List of your choices: (Score:3)
www.davinci.ca (here is the competitive analysis document I had to write: download) [geocities.com]
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.
Re:List of your choices: (Score:1)
When you set a cookie on a WAP device, the gateway manages the cookies, not the device. In the case of the UP.Phone simulator, if it is working in HTTP Direct mode, it will manage the cookies itself, which is good enough for testing.
Easiest way is to use the cookie to identify a server-side session... then the WAP device looks like any other web client, and you deal with the same issues as you have in web browsers.
I couldn't get to the document you linked to...
Give me a call, we can discuss...
Re:Use URL-rewriting based session management (Score:1)
WAP Gateway Session Support (Score:1)
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:
Nokia and BEA agreement (Score:2)
Re:Enhydra (Score:2)
I have it working (Score:2)