Dave Clark

Ranch Hand
+ Follow
since Feb 16, 2005
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Dave Clark

Versant today released the Versant Open Access development tools and JDO 2 / EJB 3 runtime to the open source community, which will continue development as the Eclipse JSR-220 ORM Project.

http://www.versant.com/opensource/orm/en-us

Now you have a quality Object-Relational Mapping development tool and runtime, which also supports the JDO and EJB 3 standards.

The workbench includes tools for visual mapping of classes to relational tables, entity-relationships diagrams, db schema generation and migration tools, ad-hoc object query browser, performance profiling and monitoring, and full round-trip engineering between the Java object model and the DB schema.

And now it's all free and open source! You can download it from:

http://www.versant.com/downloads

cheers,

Dave.
16 years ago
this error -> "Unsupported major.minor version 48.0"
simply means that you've compiled your classes with JDK 1.4, but you're trying to run them with an older JVM, problably JDK 1.3.

So it seems that the path fpor your client code must be pointing to a non-JDK 1.4 JVM

Try typing:

java -version

at a command prompt to verify your path points to a JDK 1.4 before any other VMs you may have installed,

cheers,

Dave.
no - you *can't* make the same case against Java. Java is a specification, with many vendors implementing it. You can get a JVM implementation from Sun, IBM, BEA, others?

Hibernate is a *product*, not a specification (or an open standard). If you build your app with hibernate, then you're stuck with the one and only implementation of hibernate. If you build on JDO, then you can switch JDO vendors without rewriting your app.

cheers,

Dave
you'd be much better off with a JDO-based product than with hibernate - all of the advantages of object-relational mapping technology, but without the single-vendor lockin (API's, query language, configuration and deployment). And most of the major JDO vendors (such as Versant) will be supporting both the JDO 2 and EJB 3 standards.

There are lots of vendors with great JDO products, some of them open source, some commercial. A great resource to go to to compare the vendors is www.jdocentral.com

cheers,

Dave
you shouldn't need to learn how to write ant scripts in order to use Sun's JWSDP - if you need to run ant scripts included with the pack, you just need to install ant, and then call ant by typing 'ant' in the directory with the ant build.xml build scripts.

As for Axis - I wouldn't recommend using this, since it's a proprietary API (even though it's open source, it's not open-standards compliant). It's also not WS-I compliant, so you'll run into interoperability problems if you want to talk to not Axis clients and servers.

The best option of course, would be to go and get yourslef a decent IDE. Have a look at either Eclipse or Netbeans for free IDEs, or Rational v6 if you've got some cash - or just download a trial version at

http://www-128.ibm.com/developerworks/downloads/r/rad/?S_TACT=105AGX14&S_CMP=DWNL

if you just want to have a play with the technology to learn things,

cheers,

Dave.
16 years ago
Microsoft have SOAP toolkit for older COM-based apps, so maybe this is what you need -

http://www.microsoft.com/downloads/details.aspx?FamilyId=C943C0DD-CEEC-4088-9753-86F052EC8450&displaylang=en

cheers,

Dave.
16 years ago
I did a WebSphere 6.0 Server <-> C# / .NET Web Services Client system a little over a year ago, and the development was easier than you'd imagine in regards to getting the two technologies to talk to each other.

The main tricks -
- stick to the WS-I Basic Profile (or the Basic Security Profile if you need to pass security context between the client and the server). So don't use Lists and fancy stuff in your interfaces - stick to arrays
- use Document/Literal binding for your WSDL
- write your Java/WebSphere services first, then generate your WSDL (this is easier that hand-crafting WSDL, then generating Java skeletons)
- import your WebSphere-generated WSDL into Visual Studio .NET and it'll generate client-side stubs for calling your WebSphere services.
- write your .NET client app/GUI/whatever that uses these generated stubs to invoke the services, and you're done!

It's really quite a good marraige of the technologies - WebSphere/J2EE is rock solid for scalable, robust server-side business logic. Microsoft makes great tools for easily and quickly building pretty user interfaces (as long as you're OK about locking your clients into Windows)

PS - I hope you meant VB.NET rather than VB 6, because I don't think that MS gives you a lot of support for web services in their dead-ended old VB platform.

cheers,

Dave
16 years ago
why would you want to have a table without a primary key?? primary keys are kinda one of the underpinnings of relational database theory...

how would your persistence layer know which row to update if you fetched an object, changed it's value, and wanted the changes to be persisted? You need a unique identifier for this - i.e. a primary key on the table.

Or are you actually asking a question about JDO's facilities for application identity (ID's visible to the app), versus datastore identity (IDs managed by the JDO runtime, but still stored as primary keys in an RDBMS).

cheers,

Dave
Another option is learning JDO rather than (or as well as) hibernate.

JDO queries are expressed in a syntax much like ordinary Java, so it's easy to do basic stuff really quickly, and then learn more of the intricacies (caching, disconnected object graphs, etc) as you go.

Both JDO and hibernate are about 90% of the same as the forthcoming EJB 3 POJO persistence. The main difference of course is that hibernate is a proprietary API implemented only by a single vendor, whereas there are a few dozen JDO vendors, including some pretty good free & open source implementations.

So JDO will more than likely be a better investment of time and effort learning, since there are plenty of JDO vendors to maintain compatibility with the JDO APIs and Spec, whereas developing against hibernate APIs will probably mean you'll *have* to migrate to EJB 3 in the future. Most JDO vendors on the other hand, will give you the *option* of migrating to EJB 3, by supporting both JDO 2 and EJB 3 persistence within the same product.

cheers,

Dave.
each appraoch - Java -> WSDL or WSDL -> Java is just as valid. It basically depends on your requirements.

If you're starting from scratch writing both a client and server for your web service, then it's often easiest to write the service interface (perhaps with a Stateless Session Bean), then generate the WSDL and client-side stub, then write your client against your generated stub.

However, if you're writing a service and another development team is writing a client, or if you want fine-grained control over the details of the WSDL interface, then it's often best to write the WSDL by hand, then generate client-side stubs and server-side ties/skeletons and go from there. This way you can publish the WSDL, and it'll often be a little 'tighter' or more efficient than generated WSDL.

cheers,

Dave
16 years ago
right-cllick on the project, -> Properties -> Java Build Path.

another good option is Help Menu -> Help Contents -> ... ;-)

cheers,

Dave
not "they were an alternative to EJB", JDO **is** an alternative to EJB.

JDO is alive and well - the JDO 2.0 JSR was just accepted by the JCP a couple of weeks ago, and there are a couple of dozen commercial and open source implementations which work very well today, and will continue to work into the EJB 3 timeframe, which is still a year or more away.

A great JDO resource is www.jdocentral.com.

btw - Versant have a great JDO implementation also (I work for Versant) - www.versant.com,

cheers,

Dave
JDO = Java Data Objects - It's basically lightweight persistence for Plain Old Java Objects, rather than heavyweight components like Entity Beans that need to run inside an EJB container. A good starting point for learning about JDO is www.jdocentral.com

If you want to use JMS (again, I wouldn't worry about network latency unless you measure it to be a problem - lots of web services for instance, run synchronously over the web), you may want to have a JMS server on your client, and another JMS server on your remote DB server, and cluster them, so that messages sent to your local JMS server will automatically be propogated to your remote JMS server, and both your client and remote database can talk to a local queue,

cheers,

Dave.
One approach is that you could use JDO rather than Entity Beans, then you simply have 2 PersistenceManagerFactory's which are configured to talk to your 2 databases (it doesn't matter that one is on a LAN and the other over the 'net).

When you want to update the 2 databases, you simply ask both factories for an instance of a PersistenceManager, then ask each of the PersistenceManagers to store your object. You should do this within a transaction, which can be container managed if you do your persisting from within a Stateless Session Bean. The only other thing you need is XA-compliant database drivers for your 2 databases configured for your datasources used by JDO, and they'll work together for a 2-phase commit transaction.

It's not really possibly to do this with Entity Beans, since they don't use PersistenceManagers - you'd have to have 2 separate Entity Bean classes and 2 seperate mappings etc. Certainly not as clean a solution.

If you're really worried about network latency over the internet (I'd only worry if you measure the time and it's actually a problem), then you'll want to send a message to a JMS queue on one side and an MDB listener on the other side. That way you can write to the queue within the same transaction as your local DB update, but still guarantee that the remote DB will also get updated.

cheers,

Dave.