toggle

AAPL Stock: 562.29 ( -3.03 )

MacNN News

Free WO update to run Objective-C apps on OSX

updated 08:15 pm EST, Sat March 10, 2001

Apple is offering a free update to WebObjects that will run Objective-C applications on Mac OS X for registered users of WebObjects 4.5: "This update will also convert WebObjects 4.5 Java applications to run on WebObjects 5 for Java. It will also help you bring Objective-C applications forward to Java."

by MacNN Staff

(15)

TAGS :

audio

Share the Article

Facebook Twitter Delious Slash Dot Digg

toggle

Comments

0

Joined:

0

03/10, 08:35pm | report spam | close Reply | delete
YES!

This is what developers have been asking for for a long time. Finally Apple is listening to its developer community

0

Joined:

0

03/10, 10:39pm | report spam | close Reply | delete
Web Dev on X

Maybe I haven't read all of the documentation but why pay for a development environment when Apache/PHP/mySql is FREE and is on OSX NOW? Personally, I think Java is a great language for apps, but JSP is much too slow compared to even ASP written in VBScript (as opposed to being written in JavaScript which is faster, although less "supported" by those helping budding ASP'ers.).

What do you think? or have I missed the boat and don't understand what WebObjects is?

-Raman

0

Joined:

0

03/10, 10:46pm | report spam | close Reply | delete
Can someone point me to..

some comparisons with the other Application servers on the market?

The reason I ask is that I rarely hear anything beyond BEA's WebLogic and IBM's WebSphere in the Application server realm. And let's not forget about Oracle's, ATGs, or Allaire's app servers, even if they are bit players in the market.

Is WebObjects implement any standards besides XML???? Can you take EJBs and deploy them with w***? What about JSPs, Servlets, etc, etc?

I understand that the development cycle for w*** is really refined and robust... but, if it's not standard, it's not going to take over the market.

With Apple moving away from Obj-C in favor of Java, is it expected that w*** would start to get closer to other App servers, with really good development tools as the value added feature?

Please don't flame me, I'm not trying to troll... I'm just trying to figure where w*** fits in with the other App servers out there.

Personally, I love Apple, and I appreciate anything positive that comes from them... I just wonder if it would be better if they concentrated on making kick a** machines, operating systems, and apps to go with them, as opposed to continuing work on "YAAS"

0

Joined:

0

03/10, 11:02pm | report spam | close Reply | delete
Benefit of Java...

well, there are a few reasons why Java has caught on for server side development -

- well defined, portable language -- php is neat, but doesn't hold a candle to a full language implentation... anything you can do in java, you can do in a servlet/jsp

- they can keep state -- cgi's have to be re-invoked... therefore, they have no state... it all has to be passed back to it... which brings me to...

- they startup faster. If you have a simple CGI, most of the execution time is the spawning of the process off to handle it, and returning the output... with java, this overhead is reduced... even with the addition burden of the JVM, this usually works out as a win.

- they can use JDBC, JNDI, EJBs, RMI, etc, etc, etc... this is a big gain. If you wanted to have your ASP or PHP code talk to an EJB, forget it. Within a servlet, it's a piece of cake.

I've recently been exposed to all of this... I was of the same mindset. But, after working with it, I realise that it really is sensible.

If you're not getting good performance out of your JSPs, than either a) you don't have enough memory b) you're using a non-JIT JVM c) your server isn't caching the compiled JSPs d) your server isn't keeping the JVM running constantly e) insert some other mis-configuration here. f) you're running on a Windows box :D

now, how this will relate to w***? I dunno... hopefully, Apple has done a really good job integrating w*** with the rest of the Java community... hopefully

0

Joined:

0

03/10, 11:04pm | report spam | close Reply | delete
Agreed.

I totally agree. Java is the way to go for web development. I'm migrating off of PHP to JSP right now for several major sites, and I'm terribly curious as to how Apple support for J2EE is going to play out.

0

Joined:

0

03/10, 11:07pm | report spam | close Reply | delete
w*** and J2EE

the scary part is that J2EE isn't even mentioned in passing on the WebObjects website... I hope this isn't indicative of what's to come...

0

Joined:

0

03/10, 11:34pm | report spam | close Reply | delete
RE: Web Dev On X

What do you think? or have I missed the boat and don't understand what WebObjects is?

I understand that the development cycle for w*** is really refined and robust... but, if it's not standard, it's not going to take over the market.

I think you should read up on what WebObjects is before saying anything more about it. w*** is not a competing againts PHP in the same way that a Jaguar is not competing against a Vespa. w*** is an application server.

Start here.
http://www.apple.com/webobjects/techspecs.html

For more detail, go to the developer's area.
http://developer.apple.com/techpubs/webobjects/webobjects.html

0

Joined:

0

03/11, 12:16am | report spam | close Reply | delete
J2EE integration in WO5

The reason you don't hear about J2EE etc with WebObjects is because right now there isn't any. With WO5 there is, but WO5 is not out yet. WO5 is not a J2EE app server though. It does allow J2EE integration, from the presentations at last years WWDC. PHP/mysql/Apache do notcompare at all to w***. w*** is a full object oriented web application develpoment and deployment environment. PHP allows you to build scripted sites that behave kind of like apps. PHP is enough for some sites. But for real, robust, scalable, and maintainable sites w*** is a lot better.
Chad

0

Joined:

0

03/11, 12:24am | report spam | close Reply | delete
Not new news

This has been known for a while now, however. An open memo was sent around on January 12 by Ernest Prabhakar of Apple detailing the 4.5.1 intentions of supporting ObjC w*** on OS X. www.stepwise.com as well as various w*** related mailing lists had the memo.
Chad

0

Joined:

0

03/11, 01:39am | report spam | close Reply | delete
Diff between w*** and JSP..

There is a major difference between w*** and other Web environments (JSP, ASP, PHP, CF ...). In a nutshell w*** is a different approach and paradigm. w*** components are very re-usable. The same cannot be said about the other environments.

w*** is:
-HTML, Javascript, XML neutral (it really does not care what client side language you want to use)
-Database independant: Connect to Orable, Informix, OpenBase, FrontBase. You can also connect to multiple database at the same time.
- You can use w*** as a middle tier (Pure Java Apps on the client side, built with JBuilder for example)
- 100% object oriented
- 100% damn cool

You really have to study WebObjects to get an appreciation for how different it really is.

0

Joined:

0

03/11, 11:06am | report spam | close Reply | delete
WebObjects vs. PHP

Why WebObjects?

- PHP/MySql sucks for anything but casual development. For casual development, it is awesome.... for building sites where uptime, response time, and scalability matter, it sucks. Key fault; it encourages the developer to integrate the HTML, code and SQL all into one file. Yuck. What happens when you want to change the UI? Your screwed; you have to have a developer that understands HTML, the PHP scripting language AND SQL.

WebObjects has the *best* separation of UI from control from business logic of *anything* out there. Development costs are lower, maintenance costs are lower and scalability is AMAZING.

b.bum
bbum@codefab.com
(feel free to email me with questions/comments)

0

Joined:

0

03/11, 11:21am | report spam | close Reply | delete
WebObjects vs. EJB

First things first; EJB is basically just an architecture document. Compatibility between EJB containment systems is non-existent. Comments like "to design a portable EJ bean, you must assume that some containers will provide pessimistic locking others will provide optimistic locking. Your bean must work with both" abound.

Of course, few people outside of developers understand what that means. The marketers are perfectly happy to say "pessimistic vs. optimistic" is not a big deal.

In any case, the EJB implementations tend to be inconsistent and incompatible. As well, the *only* way an EJB platform vendor can make their product "stick" is to offer goods/services above and beyond the specification. If you choose to leverage them, then you are locked to that platform. If you choose not to leverage, then you are in for a h*** of a lot of work!

SO; the most common statement of "EJB is good because it is a common standard, WebObjects is bad because it is proprietary" is a complete load of hogwash.

The reality is that choosing *any* vendors middleware-- be it WebObjects, ASP, PHP, EJB, JSP, whatever-- you *are* looking yourself into *that* vendors implementation, standards or not!

Now, look at the architecture of EJB.

- intra-bean communication is defined as being a remote method invocation. I.e. all arguments are copied and there is a boatload of overhead

- worse: every bean MUST assume it is running in its own thread. Combine this with the first; if bean A asks bean B a question, bean A will likely lock its interface (or parts of it) because of potential threading issues. If bean B then asks bean A a question to generate the answer for bean A's original request (very common when creating business logic with intent for massive reuse), then your bean A/B are now in a dead lock state. Ooops.

- EJB's database persistency model is pathetic. Result sets are a thing of the past; they are ineffecient, scale poorly, and there are *much* better ways to manage the ObjectRelational mapping (the best out there is Enterprise Objets Framework included with WebObjects). EJB does not offer relationship traversal; employee - Manager must generally be expressed as a second SQL statement written by the developer. That's just dumb.

- There are a number of object persistency solutions availabel in the Java space [TopLink, for example]. They do a pretty good job of providing something better than JDBC and the default bean persistency model, but they are relatively immature products in comparison to, say, EOF.

EOF has *12* years of development history behind it. However, unlike the Mac OS API, that does not mean 12 years of effectily minor refinement, but 12 years of very active development! This API WORKS and it works damned well.

- EJB doesn't attempt to address the whole GUI-as-template problem with any

0

Joined:

0

03/11, 11:38am | report spam | close Reply | delete
WebObjects Successes

Apple hasn't ever really flexed its marketing muscle behind WebObjects. Here are some of the stories that you may not have heard:

- w*** is being used to implement a solution for the DOD to track health care services for all enlisted individuals. Huge problem; w*** can handle it.

- WebObjects is used by the US Postal Service to implement a call center support application. Again, a HUGE problem, but one that WebObjects can scale well to handle.

- There are many others but, as I'm not an Apple Employee, I don't know what I can talk about (the above were one that I know have been mentioned in public).

The point is that WebObjects is being used to build incredibly large/complex intranet solutions. Why? Because the organizations and developer have confidence that it can scale to handle the massive needs of the problems at hand.

The initial learning curve is fairly high, but-- then again-- so it is for PHP and EJB. However, once over that initial learning curve with WebObjects, *everything* in the system is built on top of that knowledge. With EJB or PHP, every new twist requires significant learning.

Example; when scaling a WebObjects application, you simply add more Application Servers. If you have exceeded the capacity of your server box, add another box and serve apps off of it. Obvoiusly, there will be synchronization issues associated with doing this-- but the solutions do not require knowledge of new paradigm to solve.

With PHP/MySQL, scaling in this fashion can be a major headache. First, it requires one to revisit all of your data persistency code-- code that is likely spread out throughout the entire project. Next, one must consider how to deal with result set synchronization and avoide the common problem of requiring everything to be refreshed all of the time. Then comes the exciting intra-application, intra-machine notifications associated with state that MUST be updated. Since everything is result set based and pretty much raw data from the database, it is up to the developer to invent their own solution for representing object/data references between applications (primary key being the obvious, but not always correct, solution).

EJB poses a similar set of problems.

The bottom line is that it is *extremely* hard to design a system to handle *all* possible uses in the future. Systems are generally much better if the development environment leads developers into a codebase that doesn't fundamentally have to change as the system scales or is extended. WebObjects does an *excellent* job of rendering just such an environment.

b.bum
bbum@codefab.com

0

Joined:

0

03/12, 02:38pm | report spam | close Reply | delete
JSP slow

How come? It should be, after one invocation,
the cost of a preloaded Java method call, which will most
likely be compiled to native code depending on your
JVM, start options, etc., etc.

My experience is that this stuff is basically
quite fast. What you do with db access, etc., is
of course going to have some impact . . . :D

0

Joined:

0

03/14, 12:22am | report spam | close Reply | delete
JSP performance

JSP performance-- or any web based application services performance-- has little to do with how fast it executes JVM instructions or prints a string to stream.

The primary performance bottlenecks will be centric to session based state management [for high traffic sites with intra-session dependencies] or effeciently managing communication to/from the database.

JSP simply does not provide the tools to provide any kind of high level abstraction that assist with effecient data management or database communication. It just isn't there and it is *entirely* up to the developer to manage that stuff; typically, the developer will use some combination of optimized SQL and result sets.

Basically, what you were indicating in your message.

w***-- specifically EOF (Enterprise Objects Framework)-- provides an *amazing* tool set for effeciently managing communications to the database. Example; the default behaviour is that after an object is fetched from the database it will not be refreshed from the database unless the developer asks it to be refreshed. This is not as hard as it sounds-- objects are usually fetched in groups and the set of rules via which that group is populated is called a Fetch Specification. The Fetch Specification can *easily* (as in totally trivial click of a button) be configured to refresh refetched objects, to sort according to complex rules, to automatically batch load data from other tables that is related to the fetch (but not in the table from which the fetch is occurring) and do a myriad of other things.

More importantly, a Fetch Specification is *not* magic. There is nothing about its architecture or implementation that cannot be gleaned via its API and the provided documentation. In other words, you have *total* control over fetch behaviour!

What this means is that it doesn't matter if you have 10 or 10,000 active sessions against your application.... if they are all focused on browsing through the latest HOT Sale Items in your onlin catalog, those objects will be fetched from the database once, will not be copied between sessions, and will only be refreshed when you, the developer, deem it to be appropriate.

The end result is that a WebObjects developer concentrates on implementing a solution to the business problem at hand... and doesn't focus on implementing the basic, generic infrastructure necessary to support the solution to the business problem.

b.bum
(bbum@codefab.com)

Show More Comments

Login Here

toggle

Network Headlines

05/26	Apple updates iOS 5.1.1 release for...
05/25	Sotheby to auction Jobs Atari memo,...
05/25	Apple hiring new chip engineers for...
05/25	Third-gen iPad coming to Philippines...
05/25	Apple to integrate Baidu search into...

Show All

05/27	Manufacturing problems delay blue Samsung...
05/25	Sotheby to auction Jobs Atari memo,...
05/25	Apple to integrate Baidu search into...
05/25	Google picks up webOS Enyo team, Open...
05/24	Apple submits surprise optical stylus...

Show All

05/25	Sotheby to auction Jobs Atari memo,...
05/23	Google launches redesigned Search app...
05/22	Leaked next-gen iPod touch part hints...
05/22	Hulu Plus updates with iPad Retina...
05/22	TiVo Stream to push TV to iPhones,...

Show All

03/02	Save $330 on refurb. 15.4-inch, 2.4GHz...
03/01	Pre-owned 8GB iPod touch 2G, drops...
02/29	$150 off Nikon Coolpix S80 Compact...
02/28	Plantronics BackBeat 903 Bluetooth...
02/27	Refurb. Seagate 1.5TB GoFlex Portable...

Show All

toggle

Free WO update to run Objective-C apps on OSX

updated 08:15 pm EST, Sat March 10, 2001

YES!

Web Dev on X

Can someone point me to..

Benefit of Java...

Agreed.

w*** and J2EE

RE: Web Dev On X

J2EE integration in WO5

Not new news

Diff between w*** and JSP..

WebObjects vs. PHP

WebObjects vs. EJB

WebObjects Successes

JSP slow

JSP performance

Login Here

Register for our weekly email newsletter:

Connect tools:

Subscribe

to our RSS

Follow us

on Twitter

10 Most Read

10 Most Discussed

MacNN Marketplace

Free WO update to run Objective-C apps on OSX

updated 08:15 pm EST, Sat March 10, 2001

Related Articles

Recent Articles

YES!

Web Dev on X

Can someone point me to..

Benefit of Java...

Agreed.

w*** and J2EE

RE: Web Dev On X

J2EE integration in WO5

Not new news

Diff between w*** and JSP..

WebObjects vs. PHP

WebObjects vs. EJB

WebObjects Successes

JSP slow

JSP performance

Login Here

Register for our weekly email newsletter:

Connect tools:

Subscribe

to our RSS

Follow us

on Twitter

10 Most Read

10 Most Discussed

MacNN Marketplace