Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: Comparison of Java, C# for development on Windows and futurefor them
Marco Qualizza wrote:
> > .Net is just what
> > MS calls its current offering that allows you to leverage those technologies
> > (arguably better than anything else right now, at least from a development
> > standpoint for sure).
>
> Since you're obviously a MS afficionado, I'm going to need your help in
> figuring out eactly what the MS APIs are that leverages, for example, XML
> better than, again for example, Xerces does...
You mean besides that fact that:
<%@ WebService Language="VB" Class="BookWholeSaleInfoClass" %>
Imports System
Imports System.Data Imports System.Data.SQL Imports System.Web.Services
Public Class BookWholeSaleInfoClass
Public Function <WebMethod()> GetWholeSaleInfo(strISBN as String) As DataSet
Dim Connection As SQLConnection = _ New SQLConnection("server=localhost;uid=sa;pwd=;database=pubs") Dim strSQL as String = _ "select Title, Price FROM Titles WHERE ISBN = Convert(Varchar,'" & strISBN & "')" Dim Command As SQLDataSetCommand = New SQLDataSetCommand(strSQL, Connection) Dim DS As New DataSet Command.FillDataSet(DS, "WholesaleInfo") Return DS
on the remote side, and:
<%@ Page Language="VB" Debug="true" %> <%@ Import Namespace="System.Data" %> <%@ Import Namespace="BookReviewNameSpace" %> <%@ Import Namespace="BookWholeSaleInfoNameSpace" %> <%
dim wsWholeSaleInfo as New bookWholeSaleInfoClass dim dsWholeSaleInfo as Dataset = wsWholeSaleInfo.GetWholeSaleInfo(request("ISBN"))
dim strTitle as String = dsWholeSaleInfo.Tables("WholesaleInfo").Rows(0)("title")
dim decWholeSalePrice as Decimal =
dsWholeSaleInfo.Tables("WholesaleInfo").Rows(0)("price")
%>
on my local server are all I need to make and use a webservice? dsWholeSaleInfo.GetWholeSaleInfo() is a call to a *remote* method, which returns a Dataset with all it's associated properties and methods. Yet the entire transaction is SOAP and the data itself is XML during transmission. No parsing the XML necessary, the SOAP/XML transaction is *entirely transparent*. wsWholeSaleInfo.GetWholeSaleInfo() could be accessing a local method on a local class, you can't tell the difference from a code standpoint.
Not to mention that webservices create their own "web page". I could have gone directly to the remote site and seen a form, where I could enter an ISDN number and click a button to get back the same XML that is retrieved via wsWholeSaleInfo.GetWholeSaleInfo() (assuming I have the necessary permissions).
That same web page that exposes the functionality of the web service has the stub that you need to embed in VisualStudio to use all the remote classes and methods as if they were local to your machine.
All of this is covered in <url:
http://msdn.microsoft.com/theshow/Episode013/default.asp /> Of course it's full of
self-serving nonsense, but it's also extremely interesting to see a webservice
producer/consumer go together and be utilized in a few minutes.
As well, the framework does include XML processing for dealing with it directly, *including* classes to manipulate the XML data as if it were a relational DataSet object (complete with SQL-like queries/filters).
> > You know probably all too well that the java
> > community has been RACING to catch up in this regard.
>
> You could say this from a certain view point (maybe the same view point that
> claims that the wheel has replaced stairs, but I digress). From other view
> points, you could also say that MS is desperately trying to catch up to Java
> (with the usual MO of copying and rebranding the competitor's offerings)...
I'm probably wrong, but I don't think Java has anything nearly as transparent as the way a < WebMethod() > goes together. It creates a default page to not only invoke the webservice but provide all the information someone might need to invoke it remotely. If the webservice produces a DataSet, that's the return type when I invoke the method remotely. Simple.
Also, nothing in the design stops non-Microsoft SOAP from invoking the method and reading and parsing the returned XML. I'm not entirely certain, but I believe that the default webservice page also provides the XSL necessary to make sense of the DataSet returned.
> > MS has certainly made
> > its fair share of mistakes in the past and still does, but a claim that
> > Gates and Ballmer aren't as aware of the future of IT as anyone else is
> > naive wishful thinking.
>
> Not a claim that they weren't aware. A claim that they were slow to react to,
> slow to embrace, the inevitable.
It depends on what you consider to be "inevitable". It's easy to look back now and say "the way we use the Internet today was inevitable when Microsoft has no plans to embrace the Internet. But was it? Mostly low-speed connections were all that was available. It took a fairly large amount of technical expertise to get TCP/IP working right. And many other reasons why the Internet may not have been successful.
Not to mention that as a corporate executive, I'm not going to embrace something that may not fit my current business model. I will attempt to shift the market to something more profitable for myself.
The auto industry *should* be building small, fuel efficient cars because it's "inevitable" that we will run out of fossil fuel in the future. But what are they doing instead? Building larger SUVs because that fits their business model and it's more profitable.
> >>So why would you
> >>need a proprietary GUI? In B2B applications, the GUI doesn't even
> >>exist!
> >>
> >
> >
> > What planet are you on man?! B2B is not an "application", it is a
> > technology (for lack of a better word) for linking applications, all of
> > which have UI's of some sort.
>
> Actually, B2B is a definition, a conceptual framework, at most. My servlet
> backend which talks to Xyzzy server somewhere and grabs data to reply to the
> query that you asked. Yes, there is a UI, between my backend and you. And
> I'm sure Xyzzy has a gui for its regular users. but UI has no place in the
> transaction where I grab data from Xyzzy...
The entire "proprietary GUI" argument aside, .NET makes the "My servlet backend ... reply to the query that you asked" part so *easy*.
The nice part is I can embed the same code that puts the results of your webservice on my web site, I can also embed it in an application that users can load on their laptops and take with them. Heck, we could sync their data with your data, and the call to the "WebMethod()" that their local apps makes could simply return data from a locally residing database or XML file. I don't need to change the way I consume the data. I need only change the output and how it's produced (trivial really, since the GUI components let you bind DataSets directly for grid views, etc. And producing the data is just a matter of re-writing the producer code to read from a different database or file).
> > And if you read the trade rags at all you're aware of the recently
> > increasing number of articles suggesting that the idea of a browser-only
> > client sounded good but in the end just isn't going to cut it for most
> > enterprise applications.
>
> I'm sorry, I don't read the rags. I build the apps. I think you'd be amazed
> at can be done with IE and Mozilla now-a-days...
While I am a big fan of browser-based applications, especially in terms of self-service (banks, airline online ticket ordering, etc), I don't think they are good for everything. Certain data entry oriented or reporting systems either require too much control over input masking, or in the case of reporting, too much bandwidth to output the results.
-- | Grant Wagner <gwagner_at_agricoreunited.com>Received on Tue Jan 14 2003 - 13:35:43 CST