Hi Mike,
You're in an area where forums and mailing lists often fall down because
complex tasks can require lots of information to give an accurate analysis.
Whether that information gets across or whether participants take the time
to ingest it all is hit or miss. Keep that in mind because most responses
will, of necessity, be fairly general and you'll have to apply that to your
specifics. You have another problem by being the middleman. Since we don't
know the rationale for using EJB's (or which ones,) it's difficult to make a
meaningful comment.
Also, "'didn't think' the JVM on i5/OS supported it" speaks volumes all
by itself. Aaron is generally right, but you might want to use
message-driven beans for asynchronous operations and getting the net effect
of threads in a way acceptable to managed containers. You can also use a
J(2)EE environment just for the included services. If you want a quick
overview, see the first few pages of the "J2EE/EJB Overview" section of my
developerWorks tutorial "Getting Started with Enterprise JavaBeans." You
can also see them directly at:
http://www.conceptgo.com/gsejb/ov01.html
It does sound like you really are talking about a classic "web service".
Again, I don't know your specifics, but given that you seem to be speaking
of large amounts of data from disparate sources, a web service strikes me as
a bad idea. I have a client who is thinkng along the same lines for a large
volume of monthly transactions. If I get sucked into it, part of my
agreement will be "don't blame me if performance is awful." And I should
say *when* rather than if.
My reasons are based on exactly how web services work. See "Web
Services Overview" at:
http://java.sun.com/webservices/
Web services are great for relatively small, relatively infrequent
pieces of information. They also have benefits that may outweigh
performance depending on the circumstance. See Anne Thomas' article "When
to Use Web Services" at:
http://www.computerworld.com/action/article.do?command=viewArticleTOC&specialReportId=620&articleId=94886
But think of what you've got:
a provider and client for each web service (and associated maintenance)
conversion from data to XML on the server side, conversion from XML to
data on the client side.
a variety of protocols and intermediate transactional operations across
a network.
Last, I don't know where "persistent connections" fit into all of this.
The only place I can see is between the web service provider and its DBMS.
Or does it mean a dedicated port that's always connected between the web
service provider and client?
So there are lots of considerations. I hope this helped somewhat,
rather than increasing confusion. BTW, Java web services are available
separately, and could still be used without a J(2)EE or even web container,
depending on circumstances.
Joe Sam
Joe Sam Shirah -
http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum:
http://www.ibm.com/developerworks/java/
Just the JDBC FAQs:
http://www.jguru.com/faq/JDBC
Going International?
http://www.jguru.com/faq/I18N
Que Java400?
http://www.jguru.com/faq/Java400
----- Original Message -----
From: "Mike" <koldark@xxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Friday, May 04, 2007 9:23 AM
Subject: Re: Enterprise Java
Honestly, I am the middle man here.
Web service: We want a middle tier to use SOAP (or whatever it's called)
to
and from our web server. The java web service would communicate with the
System i, MS SQL and other required databases. This way we only have one
hole through the DMZ to a specific server (if we can even do that).
We are in the planning stages on this and are first determining if we
should
do RPG, Java, or .NET. The web developer said he would like to use
Enterpise
java beans and didn't think the JVM on i5/OS supported it without the
full-blown WebSphere App. Server. I thought it would and we could just
install JBoss to make use of them.
On 5/3/07, Joe Sam Shirah <joe_sam@xxxxxxxxxxxxx> wrote:
Hi Mike,
I think there are opportunities for miscommunication here. "Web
service" means something specific to most Java developers and that's
something substantially different from just accessing multiple
databases.
Secondly, your answer really doesn't tell us anything about the
"enterprise" needs of your application(s.) So we can't really say if
just
a
web container like Tomcat or Jetty is sufficient or if you need
something
that supplies more services. There are a lot of options around.
"persistent data connections" doesn't sound like a very good idea at
first, but that's essentially what connection pools provide, and you
should
probably look to using those regardless of whether you use a web or
J(2)EE container. There are also a number of other factors that
contribute
to database related performance beyond just connection persistence.
Joe Sam
Joe Sam Shirah - http://www.conceptgo.com
conceptGO - Consulting/Development/Outsourcing
Java Filter Forum: http://www.ibm.com/developerworks/java/
Just the JDBC FAQs: http://www.jguru.com/faq/JDBC
Going International? http://www.jguru.com/faq/I18N
Que Java400? http://www.jguru.com/faq/Java400
----- Original Message -----
From: "Mike" <koldark@xxxxxxxxx>
To: "Java Programming on and around the iSeries / AS400"
<java400-l@xxxxxxxxxxxx>
Sent: Thursday, May 03, 2007 3:01 PM
Subject: Re: Enterprise Java
The lead web developer wants to use persistent data connections to
databases. This web service would grab data from MS SQL, the System i,
and
untold # of other databases for use on the main City website. So speed
is
the key here.
midrange.com
