I understand the main challenge quite well. I've developed J2ME (and WAP) applications already.
Interfaces and devices capacities make "write once, run anywhere" unrealistic. However if you code yourapplication properly and abstract your logic from display some level of reusabability can be achieved. To what degree will depend and there hasn't been enough history to come up with an estimated range. From personal experience I estimated 60-80%, but this comes from applications that where not games. I would expect games to be lower.
What type of games are we talking about here that performance is such an overiding factor? Who wants to play Quake or Unreal on a mobile phone?
Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.
BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME when they launch thier new service this August.
If your a developers, where would you put your efort first?
J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty (a new high performance virtual machine), Mobile Game API and the Mobile Media API.
I agree here. Acquiring Sun would be a disater that would kill any value/talent that Sun would bring to IBM other then the rights to Java. McNealy is far too strong willed to let it happen without a fight to the death. I think the likelyhood that BEA and Sun would merge are far greater. I'd put a Sun Oracle merger ahead of IBM also.
I think those who are wishing for IBM to aquire Sun just to make Java "open source" or whatever need to get a clue and think about business and not technology when it comes industry matters like these.
Did the submitter ever think of writing their own RFP?
I'm kind of confused by the submitters situation. RFPs for software is pointless really. The job of software (or combinations of) is to provide a solution to a problem.
So the real question is who is providing the solutions? It doesn't matter whether it is internal IT or outsourced. So assuming the submitter is from an internal IT group, they should be the ones writing it.
I haven't had a lot of time to study the UDDI spec, but I have been pondering the topic of Open Services for quite some time and my feeling is they will. I like the term Open Services, as Tim O'Reilly calls them, over Web services because this concept is applicable beyond HTML and just the Web.
I think the biggest hurdle at the moment for this concept, is the perception that Microsoft invented this concept (therefore there must be something sinister and evil behind it!) and its tied to just their technology which is just plain off.
The idea of open services where around before SOAP. I haven't done an in-depth genealogy of the concept, but I can tell you Dave Winer at Userland has been evangelizing it for a couple of year now. There is also Allaire's WDDX and in a looser sense RSS and ICE.
Microsoft did initiate the SOAP spec, but have put they have opened it up and submitted to the W3C. They incorporated IBM's feedback which garnered IBM whole-hearted support. IBM released their Java implementation on AlphaWorks and then donated the code to Apache. Even Sun conceded it was a good idea and gave as much of an endorsement as they could stomach for something Microsoft had initiated.
I would even argue that IBM is excelling beyond Microsoft. Well... at least in the developer community. They've yet to release anything commercially or articulated a product strategy that utilizes it. (Typical them.) Microsoft does seem to be betting quite a bit on SOAP/Open Services and going from there.
What I love about this concept (and why I think it will succeed) is that its fairly easy and straight forward to work with. It also is a more concrete way to get all of these different platforms that are deployed to talk to each other. It will just makes developing easier, better and smarter.
The way I read it, UDDI is just a progression in making solutions built on this concept more robust.
For all of those interested in this topic, here are some good background links on the topic that aren't so Microsoft-rah-rah.
Slashdot Mirror
I understand the main challenge quite well. I've developed J2ME (and WAP) applications already.
Interfaces and devices capacities make "write once, run anywhere" unrealistic. However if you code yourapplication properly and abstract your logic from display some level of reusabability can be achieved. To what degree will depend and there hasn't been enough history to come up with an estimated range. From personal experience I estimated 60-80%, but this comes from applications that where not games. I would expect games to be lower.
What type of games are we talking about here that performance is such an overiding factor? Who wants to play Quake or Unreal on a mobile phone?
Many of these types of games and more where being demonstrated on JavaONE this year on J2ME devices so I would get too hung up on BREW. In fact I wouldn't even bother with that technology.
BREW is currently a CDMA only technology. The majority of the world uses GSM thought. (Americans sometimes forget this since CDMA has a larger, but weakening, footprint in the US.) The majority of carriers and handset manufacturers are committed to J2ME in someway. Motorola has gone so far as to pledge that all of its phones will ship with J2ME by the end of this year. Even CDMA carrier Sprint PCS have decided to forego BREW for J2ME when they launch thier new service this August.
If your a developers, where would you put your efort first?
J2ME has its limtiations though. Then again so do these devices -- With a screen not much larger then an airmail stamp we're not even talking game boy here. The limitations of J2ME are currently being addressed with initatives such as Project Monty (a new high performance virtual machine), Mobile Game API and the Mobile Media API.
<tim/>
---
http://tima.mplode.com/
I agree here. Acquiring Sun would be a disater that would kill any value/talent that Sun would bring to IBM other then the rights to Java. McNealy is far too strong willed to let it happen without a fight to the death. I think the likelyhood that BEA and Sun would merge are far greater. I'd put a Sun Oracle merger ahead of IBM also.
I think those who are wishing for IBM to aquire Sun just to make Java "open source" or whatever need to get a clue and think about business and not technology when it comes industry matters like these.
Did the submitter ever think of writing their own RFP?
I'm kind of confused by the submitters situation. RFPs for software is pointless really. The job of software (or combinations of) is to provide a solution to a problem.
So the real question is who is providing the solutions? It doesn't matter whether it is internal IT or outsourced. So assuming the submitter is from an internal IT group, they should be the ones writing it.
I haven't had a lot of time to study the UDDI spec, but I have been pondering the topic of Open Services for quite some time and my feeling is they will. I like the term Open Services, as Tim O'Reilly calls them, over Web services because this concept is applicable beyond HTML and just the Web.
I think the biggest hurdle at the moment for this concept, is the perception that Microsoft invented this concept (therefore there must be something sinister and evil behind it!) and its tied to just their technology which is just plain off.
The idea of open services where around before SOAP. I haven't done an in-depth genealogy of the concept, but I can tell you Dave Winer at Userland has been evangelizing it for a couple of year now. There is also Allaire's WDDX and in a looser sense RSS and ICE.
Microsoft did initiate the SOAP spec, but have put they have opened it up and submitted to the W3C. They incorporated IBM's feedback which garnered IBM whole-hearted support. IBM released their Java implementation on AlphaWorks and then donated the code to Apache. Even Sun conceded it was a good idea and gave as much of an endorsement as they could stomach for something Microsoft had initiated.
I would even argue that IBM is excelling beyond Microsoft. Well... at least in the developer community. They've yet to release anything commercially or articulated a product strategy that utilizes it. (Typical them.) Microsoft does seem to be betting quite a bit on SOAP/Open Services and going from there.
What I love about this concept (and why I think it will succeed) is that its fairly easy and straight forward to work with. It also is a more concrete way to get all of these different platforms that are deployed to talk to each other. It will just makes developing easier, better and smarter.
The way I read it, UDDI is just a progression in making solutions built on this concept more robust.
For all of those interested in this topic, here are some good background links on the topic that aren't so Microsoft-rah-rah.