.Net or J2EE?

[Jonathan Li]

Hi there,

I posted a thread in another group. I could not get satisfactory
feedback. I would like to try if anybody in this group can help me out.

My plan was, to develop components at server side (something like EJBs).
For data entry and operation application functions, I can use C#.Net.
For reporting and enquiry functions, I can use ASP.Net. You may aware
that these two packages have a lot in common. Under J2EE environment, I
know how to it through EJBs the 'shared components'. Under .Net, what
should I do? Can I have the environment of C#.Net + ASP.Net + Unix
server (as database server as well as deployment server)?

It seems that the only choice I have is to use VB or Delphi and ODBC. If
that is the case, I would have two piles of shit in my hands: 1) J2EE;
2) .Net.

Any advice?

Jonathan








*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Tim Jarvis]

Re: .Net or J2EE?

Jonathan Li wrote:

[color=blue]
>
> It seems that the only choice I have is to use VB or Delphi and ODBC.
> If that is the case, I would have two piles of shit in my hands: 1)
> J2EE; 2) .Net.
>
> Any advice?
>
> Jonathan[/color]

Hi Jonathan,

it's not totally clear to me here what it is that you want to be able
to do exactly, Perhaps you might like to try and re-word your question
a little bit, to make it a little clearer.

one point though, in case this is what you were asking... it is
possible to have a C# client application that talks to a J2EE server
app, there are a couple of technologies out there that will allow you
to do it. one of which is here http://www.borland.com/janeva/ My
appologies if this appears to be a plug, I would post a link to the
other tech's if I knew them, perhaps someone else will do that.

Rgds Tim.

[Bjorn Abelli]

Re: .Net or J2EE?


"Jonathan Li" wrote...
[color=blue]
> I posted a thread in another group. I could not get
> satisfactory feedback. I would like to try if anybody
> in this group can help me out.[/color]

I don't know what you mean by "satisfacto ry feedback", but I think that the
answers you got in microsoft.publi c.dotnet.framew ork.adonet,
microsoft.publi c.dotnet.framew ork.aspnet and
microsoft.publi c.dotnet.framew ork.windowsform s pretty much covers the most.
[color=blue]
> My plan was, to develop components at server side
> (something like EJBs).[/color]

..NET lacks anything remotely close to the concept of EJBs.

However, ADO.NET have other advantages that can make that a better choice
over e.g. JDBC.
[color=blue]
> For data entry and operation application functions,
> I can use C#.Net.[/color]

You can use pretty much anything for data entry and operation application
functions.
[color=blue]
> For reporting and enquiry functions, I can use ASP.Net.[/color]

You could use ASP.NET for data entry as well.

And you can also pretty much anything for data entry and operation
application functions as well.
[color=blue]
> You may aware that these two packages
> have a lot in common.[/color]

You don't say... :-)
[color=blue]
> Under J2EE environment, I know how to it
> through EJBs the 'shared components'.
> Under .Net, what should I do?[/color]

Here you've got a multitude of possibilities, but...
[color=blue]
> Can I have the environment of C#.Net + ASP.Net
> + Unix server (as database server as well as
> deployment server)?[/color]

At the moment the use of .NET on a Unix server is pretty risky.
[color=blue]
> It seems that the only choice I have is to use VB or
> Delphi and ODBC. If that is the case, I would have two
> piles of shit in my hands: 1) J2EE; 2) .Net.[/color]

That's *not* the case, but your conclusion is interesting, puzzling and
seems a bit confused. At least it's confusing me!

If the case is that your customer (or whatever) demands a Unix server,
certainly the first choice would *not* be to look into "VB or Delphi and
ODBC". Those are foremost used on Windows, and if you have the possibility
to run everything on a Windows server anyway, I would rather recommend some
..NET-solution, such as C# + ADO.NET + ASP.NET.

If you can't do without the Unix server, you still have a lot of choices,
but then you must look further into what the requirements really are. Just
to give a few examples (based on the demand of a Unix server):

- The complete platform independency:
Do *everything* in Java! (J2EE, EJB, servlets, etc)

- The n-tier solution:

a) Wrap the Entity beans into Webservices (in Java),
which can be called from C#-clients

b) Use the Unix server as a database server only,
and use ADO.NET and ASP.NET on a separate
Windows server for the access from clients

Those were just a few examples, but you have to look further into what the
requirements *really* are.

So, if you question is if .NET can work *on* Unix, the answer can only be
"to some extent, but not recommended (yet) for live business purposes".

If your question rather is if .NET can be used in *conjunction* with a Unix
server, the answer will be a definite "yes, but with that server only as a
backend for some specific purpose", and to be precice, you must define the
overall system architecture to be used.

Finally, the question should rather be why the customer demands a Unix
server in the first place? Why doesn't he/she demand some specific
functionality of the system instead, and lets the developers decide on what
solutions that can make the best choices?

my 2c

// Bjorn A

P.S. There's an obvious reason why Microsoft at this moment doesn't develop
..NET for Unix or Linux. They simply don't wan't to support any OS that is
competing with their own, Windows...

However, if you can wait a couple of years, something might come up in the
new collaboration between Microsoft and Sun.

[Joerg Jooss]

Re: .Net or J2EE?

Bjorn Abelli wrote:[color=blue]
> "Jonathan Li" wrote...
>[color=green]
>> I posted a thread in another group. I could not get
>> satisfactory feedback. I would like to try if anybody
>> in this group can help me out.[/color]
>
> I don't know what you mean by "satisfacto ry feedback", but I think
> that the answers you got in microsoft.publi c.dotnet.framew ork.adonet,
> microsoft.publi c.dotnet.framew ork.aspnet and
> microsoft.publi c.dotnet.framew ork.windowsform s pretty much covers the
> most.
>[color=green]
>> My plan was, to develop components at server side
>> (something like EJBs).[/color]
>
> .NET lacks anything remotely close to the concept of EJBs.[/color]

What about Serviced Components using COM+? These are quite similar to
Stateless Session Beans AFAIK.


--
Joerg Jooss
joerg.jooss@gmx .net

[Bjorn Abelli]

Re: .Net or J2EE?

"Joerg Jooss" wrote...[color=blue]
> Bjorn Abelli wrote:[color=green]
> > "Jonathan Li" wrote...
> >[color=darkred]
> >> My plan was, to develop components at server side
> >> (something like EJBs).[/color]
> >
> > .NET lacks anything remotely close to the concept of EJBs.[/color]
>
> What about Serviced Components using COM+? These are
> quite similar to Stateless Session Beans AFAIK.[/color]

That's quite a restricted view on what EJBs are, ain't it?

;-)

I would be more than interested if someone could show me something similar
to entity beans in .NET. I believe that was one of the types the OP was
thinking about, as the "unix server would act as both DB server and
application server".

To use the entity beans effectively, there would also in most cases be a
need to use *stateful* session beans, wrapping the entity beans for client
exposure.

So, if you can point me to some built in .NET-components that actually can
do this, I'd be very happy! :-)

// Bjorn A

P.S. A colleague of mine created some Serviced Components using COM+, and
compared to the use of EJBs it was APITA. At least in his opinion...

Excuse my (or rather his) French...

[Joerg Jooss]

Re: .Net or J2EE?

Bjorn Abelli wrote:[color=blue]
> "Joerg Jooss" wrote...[color=green]
>> Bjorn Abelli wrote:[color=darkred]
>>> .NET lacks anything remotely close to the concept of EJBs.[/color]
>>
>> What about Serviced Components using COM+? These are
>> quite similar to Stateless Session Beans AFAIK.[/color]
>
> That's quite a restricted view on what EJBs are, ain't it?
>
> ;-)[/color]

No, it's not. It was just a plain statement that Serviced Components are
similar to Stateless Session Beans. You're right regarding the other three
types of EJBs, but saying ".NET lacks anything remotely close to the concept
of EJBs" is not correct. Stateless Session Beans are far and away the most
important and often used kind of EJB, but YMMV...
[color=blue]
> There I would be more than interested if someone could show me something
> similar to entity beans in .NET.[/color]

I can't see going .NET anywhere near that direction. ObjectSpaces seems to
be a JDOish addition to ADO.NET (nice), whereas current .NET architectures
seem to rely heavily on stored procedures.
[color=blue]
> To use the entity beans effectively, there would also in most cases
> be a need to use *stateful* session beans, wrapping the entity beans
> for client exposure.[/color]

Hell, no. Stateful Session Beans are in general of very limited use and
should be avoided.
[color=blue]
> So, if you can point me to some built in .NET-components that
> actually can do this, I'd be very happy! :-)[/color]

Since I do .NET for fun and J2EE for a living, I'm pretty much in the same
situation like you ;-)

Maybe you should reconsider your architecture approach -- see for example
http://msdn.microsoft.com/architecture/.

Cheers,

--
Joerg Jooss
joerg.jooss@gmx .net

[Bjorn Abelli]

Re: .Net or J2EE?


"Joerg Jooss" wrote...[color=blue]
> Bjorn Abelli wrote:[color=green]
> > "Joerg Jooss" wrote...[/color][/color]
[color=blue][color=green][color=darkred]
> >> What about Serviced Components using COM+? These are
> >> quite similar to Stateless Session Beans AFAIK.[/color]
> >
> > That's quite a restricted view on what EJBs are, ain't it?
> >
> > ;-)[/color]
>
> No, it's not. It was just a plain statement that Serviced
> Components are similar to Stateless Session Beans. You're
> right regarding the other three types of EJBs, but saying
> ".NET lacks anything remotely close to the concept
> of EJBs" is not correct. Stateless Session Beans are far
> and away the most important and often used kind of EJB,
> but YMMV...[/color]

OK, I could rephrase the statement to something like ".NET can only give a
solution for one out of four possible implementations of EJBs".

Better? :-)

[I still think only one out of four
is not remotely close... ;-) ]
[color=blue]
> Maybe you should reconsider your architecture
> approach -- see for example
> http://msdn.microsoft.com/architecture/.[/color]

I hope the OP is still among us to read that. :-)

// Bjorn A

[Joerg Jooss]

Re: .Net or J2EE?

Bjorn Abelli wrote:[color=blue]
> "Joerg Jooss" wrote...[color=green]
>> Bjorn Abelli wrote:[color=darkred]
>>> "Joerg Jooss" wrote...[/color][/color]
>[color=green][color=darkred]
>>>> What about Serviced Components using COM+? These are
>>>> quite similar to Stateless Session Beans AFAIK.
>>>
>>> That's quite a restricted view on what EJBs are, ain't it?
>>>
>>> ;-)[/color]
>>
>> No, it's not. It was just a plain statement that Serviced
>> Components are similar to Stateless Session Beans. You're
>> right regarding the other three types of EJBs, but saying
>> ".NET lacks anything remotely close to the concept
>> of EJBs" is not correct. Stateless Session Beans are far
>> and away the most important and often used kind of EJB,
>> but YMMV...[/color]
>
> OK, I could rephrase the statement to something like ".NET can only
> give a solution for one out of four possible implementations of EJBs".
>
> Better? :-)[/color]

OK, that looks just fine :-)

[...][color=blue]
> I hope the OP is still among us to read that. :-)[/color]

I'm afraid we kind of lost him...

Cheers,

--
Joerg Jooss
joerg.jooss@gmx .net

[Jonathan Li]

Re: .Net or J2EE?


Thanks a lot guys. I believe you have sidetracked the discussion. Can I
pull you back a little bit.

I rephrase my requirement and would like to hear your advice.

1. The server must be Unix
When I say 'server' means 1) database server; 2) if possible also the
application server.

One asked why Unix instead of Windows. Well, it is written in the
bidding document to use Unix.

If I can use Windows as the server, there is no question at all. So
please no need to discuss on this point.

2. I want to make use of the Windows/.Net powers on client side.
The application on client has two packages, one is in C/S mode. The
other is B/S mode. So, I would like to use C#.Net or VB.Net to develop
the C/S package and ASP.Net to develop B/S package.

3. Because the C/S package is operating on the same data set as of the
B/S package, there are a lot functions (or components) in common for
these two packages. Actually, I want the two packages share the
components as much as possible.
Under J2EE, we can have EJBs to have that. Under .Net, what should I do
because ASP.Net cannot work under Unix.

Thanks.

Jonathan



*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Joerg Jooss]

Re: .Net or J2EE?

Jonathan Li wrote:[color=blue]
> Thanks a lot guys. I believe you have sidetracked the discussion. Can
> I pull you back a little bit.
>
> I rephrase my requirement and would like to hear your advice.
>
> 1. The server must be Unix
> When I say 'server' means 1) database server; 2) if possible also the
> application server.[/color]

You say "if possible also the application server". But what does that mean?
Will there be a J2EE application server or not? This has a dramatic impact
on the architecture.

OTOH, save for product preferences, it is rather irrelevant what DB is being
used and on what OS it runs, as long as there are either the appropriate
JDBC drivers or .NET data providers available.

[color=blue]
> One asked why Unix instead of Windows. Well, it is written in the
> bidding document to use Unix.
>
> If I can use Windows as the server, there is no question at all. So
> please no need to discuss on this point.
>
> 2. I want to make use of the Windows/.Net powers on client side.
> The application on client has two packages, one is in C/S mode. The
> other is B/S mode. So, I would like to use C#.Net or VB.Net to develop
> the C/S package and ASP.Net to develop B/S package.[/color]

The only way how I can see ASP.NET fit in this picture -- assuming you *do*
use a J2EE application server -- is to use it as thinc lient presentation
layer that talks to the EJB backend using WebServices or some custom-made
(binary) protocol.
[color=blue]
> 3. Because the C/S package is operating on the same data set as of the
> B/S package, there are a lot functions (or components) in common for
> these two packages. Actually, I want the two packages share the
> components as much as possible.
> Under J2EE, we can have EJBs to have that. Under .Net, what should I
> do because ASP.Net cannot work under Unix.[/color]

I highly doubt that there will be a lot of common code between the Windows
Forms UI and the ASP.NET UI other than validation classes. Since you're
supposedly using an application server, that's where your businsess
components will reside.


Cheers,

--
Joerg Jooss
joerg.jooss@gmx .net

[Jonathan Li]

Re: .Net or J2EE?


Joerg, thanks.

When you say that there is not much in common for the client UI and
ASP.Net UI. You might be right. But my requirement is not only to
develop UI but the whole application. I am developing the application.
Some modules for data entry operations in Client/Server mode (I call
these modules the C/S package). Another part is in Browser/Server mode.
They HAVE much functions in common for example interest calculation.

When I say 'application server' meaning that I do want to share code for
the c/s package and b/s. Under J2EE, we know that it is easy to do that
- to develop c/s package in JBuilder and b/s package in JSP. The
'shared' parts can be implemented through EJBs.

Now, I want to switch to .Net, completely. Not to have J2EE and .Net at
the same time. But I do not know how to do it under Unix environment as
the server. Actually my understanding is that there is no solution for
that at all (simply because Mr. Gates does not know anything about Unix
so he does not like it, whilst my clients insist on Unix).

Any advice?


Jonathan

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

[Bjorn Abelli]

Re: .Net or J2EE?


"Jonathan Li" wrote...
[color=blue]
> Now, I want to switch to .Net, completely. Not to
> have J2EE and .Net at the same time. But I do not
> know how to do it under Unix environment as
> the server. Actually my understanding is that
> there is no solution for that at all[/color]

What you're seem to be looking for is *possible*, but probably not *stable*
at this time.

As you insist to share components between the Unix and the Windows
platforms, the only way I know of is to use Mono in some way or another.

http://www.go-mono.org/

It does have an implementation of ASP.NET, which can work as an Apache
module or in Mono's XSP server.
[color=blue]
> (simply because Mr. Gates does not know
> anything about Unix so he does not like it, whilst my
> clients insist on Unix).[/color]

The commercial world of constructing a development and runtime environment
is a bit more complicated than that. Why should Mr. Gates have any interest
in supporting a platform other than his own, Windows?

Aren't your clients rather narrow-minded to demand a specific platform,
instead of demanding specific functionality?
[color=blue]
> Any advice?[/color]

There are several possibilities, some I pointed out in a previous message:

1. Skip the idea of .NET and go for a complete
Java/J2EE-solution.

2. Try Mono. It's not any guarantee that all of what
you're needing for the project is implemented yet,
but it could be worth a try.

3. Say "no" to the client. If he insists on Unix for the
application server, and you insist on developing the
system in .NET at this time, this could possibly be
the best solution... ;-)

As I said before, there's other possible approaches as well, but for the
type of combination of Unix and .NET that you're looking for, I think not...

// Bjorn A

[Joerg Jooss]

Re: .Net or J2EE?

Bjorn Abelli wrote:[color=blue]
> "Jonathan Li" wrote...
>[color=green]
>> Now, I want to switch to .Net, completely. Not to
>> have J2EE and .Net at the same time. But I do not
>> know how to do it under Unix environment as
>> the server. Actually my understanding is that
>> there is no solution for that at all[/color]
>
> What you're seem to be looking for is *possible*, but probably not
> *stable* at this time.
>
> As you insist to share components between the Unix and the Windows
> platforms, the only way I know of is to use Mono in some way or
> another.
>
> http://www.go-mono.org/
>
> It does have an implementation of ASP.NET, which can work as an Apache
> module or in Mono's XSP server.[/color]

There's also the DotGNU project (see http://www.gnu.org/projects/dotgnu/),
but I have no freaking clue what stuff they have so far.
[color=blue]
>[color=green]
>> (simply because Mr. Gates does not know
>> anything about Unix so he does not like it, whilst my
>> clients insist on Unix).[/color]
>
> The commercial world of constructing a development and runtime
> environment is a bit more complicated than that. Why should Mr. Gates
> have any interest in supporting a platform other than his own,
> Windows?
>
> Aren't your clients rather narrow-minded to demand a specific
> platform, instead of demanding specific functionality?[/color]

Probably they are, probably not. If I ran a UNIX shop, I'd be *very*
reluctant to introduce a Windows Server based solution (or any other new
platform for that matter and disregarding TOC, stability, reliabilty etc.),
only because there's probably nobody around who's got the skills to run and
integrate these Windows boxes.
[color=blue][color=green]
>> Any advice?[/color]
>
> There are several possibilities, some I pointed out in a previous
> message:
>
> 1. Skip the idea of .NET and go for a complete
> Java/J2EE-solution.
>
> 2. Try Mono. It's not any guarantee that all of what
> you're needing for the project is implemented yet,
> but it could be worth a try.
>
> 3. Say "no" to the client. If he insists on Unix for the
> application server, and you insist on developing the
> system in .NET at this time, this could possibly be
> the best solution... ;-)
>
> As I said before, there's other possible approaches as well, but for
> the type of combination of Unix and .NET that you're looking for, I
> think not...[/color]

I guess Jonathan is pretty much stuck with a J2EE solution for now...

Cheers,

--
Joerg Jooss
joerg.jooss@gmx .net

[Bjorn Abelli]

Re: .Net or J2EE?


"Joerg Jooss" wrote...[color=blue]
> Bjorn Abelli wrote:[color=green]
> >
> > http://www.go-mono.org/
> >
> > It does have an implementation of ASP.NET, which can
> > work as an Apache module or in Mono's XSP server.[/color]
>
> There's also the DotGNU project (see
> http://www.gnu.org/projects/dotgnu/),
> but I have no freaking clue what stuff they have so far.[/color]

I have seen some notes about that too, but it seems to be somewhat limited
in comparison to Mono. What I have seen is that DotGnu have come very far on
the part of WebServices (DGEE), but Mono seem to have gotten further on most
other aspects, including ASP.NET, which in the aspects of the OP should be a
necessity.

It will be very interesting to see how fast Mono can come up with their
special port of SharpDevelop, called MonoDevelop.

// Bjorn A