Home > Archive > Cobol > September 2006 > Microsoft .NET?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| JohnCrowley 2006-09-08, 7:55 am |
| I have been asked to investigate whether we should consider using
Microsoft .NET for some of our services. I've done a few searches but I
can't find a succinct summary of what it's about.
Does anyone have a view as to whether this is something worth
exploring?
Thanks.
| |
| Michael Wojcik 2006-09-08, 6:55 pm |
|
In article <1157716289.081610.281000@m79g2000cwm.googlegroups.com>, "JohnCrowley" <johncrowleyuk@yahoo.co.uk> writes:
> I have been asked to investigate whether we should consider using
> Microsoft .NET for some of our services. I've done a few searches but I
> can't find a succinct summary of what it's about.
Probably because it can't be summarized succinctly, I'm afraid.
..NET is a number of things:
- A brand for marketing.
- An execution platform that sits on Windows (primarily) and Linux
(via the Mono project, now owned by Novell). It provides a number
of features not available in the base OS, such as a better code-
signing model, improved versioning, better security partitioning,
etc.
- An implementation of the Common Language Runtime (CLR), an
intermediate language invented by Microsoft (and now standardized
by ECMA, IIRC). All .NET languages are compiled to CLR, which is
JIT-compiled to native code at runtime. CLR provides a "managed
code" environment which improves security and robustness, much as
the Java JVM sandbox does.
- A "framework", or (large) collection of classes, for all sorts
of things: GUI components, system services, utility routines, etc.
(Much of the framework is Microsoft-specific and not available
under Mono.)
> Does anyone have a view as to whether this is something worth
> exploring?
Well, you could read the thread "Could this save COBOL?" which is
going on right now at a comp.lang.cobol near you. It's all about OO
COBOL and .NET.
There have been a number of discussions of .NET as it relates
specifically to COBOL on c.l.c; a Google search would no doubt turn
up plenty of material. You probably don't want to wade through all
of it, but it might be worth your while to skim a few messages.
We (that is, Micro Focus) have various materials about COBOL and
..NET available on our website; I imagine other vendors of COBOL for
..NET do as well.
If the "services" you refer to are distributed services - Web
Services or the like - then .NET does give you some useful
frameworks. In particular, there's Windows Communications Foundation
(WCF, formerly known as "Indigo"), which is a quite decent comms
stack. For popular protocols such as SOAP, there are high-level
frameworks and toolkits.
--
Michael Wojcik michael.wojcik@microfocus.com
Cooperation is just like two pagodas, one hardware and one software.
-- Wen Jiabao
| |
| Clark F Morris 2006-09-08, 6:55 pm |
| On 8 Sep 2006 04:51:29 -0700, "JohnCrowley"
<johncrowleyuk@yahoo.co.uk> wrote:
>I have been asked to investigate whether we should consider using
>Microsoft .NET for some of our services. I've done a few searches but I
>can't find a succinct summary of what it's about.
>
>Does anyone have a view as to whether this is something worth
>exploring?
>
>Thanks.
The major problem with .NET is that it locks your organization to both
an operating system and a computer architecture. This means that if
the platform is not scalable for your organization's needs, and you
find out three years down the road, it will be "fun". On the other
hand most solutions tie an organization to a platform to some extent.
There is more flexibility if you use a solution that is multi-platform
(Websphere or its competitors for example), especially if the base is
open source. Another problem with any solution is that it tends to be
replicated within an organization for tasks which it can handle so the
initial use isn't the only consideration. Be wary of all vendors. If
possible financially attend user group conferences for the product and
talk with the users.
| |
| JohnCrowley 2006-09-08, 6:55 pm |
| Many thanks Michael, just what I needed.
| |
| Stephen Gennard 2006-09-11, 7:55 am |
| Hi Clark,
I do not believe the .NET architecture locks your organisation into a
operating system or computer architecture.
Why?
The environment (CLI - Virtual Machine) and the C# language were both
submitted to ECMA and have been approved.
Because the environment and the C# language are backed by a ECMA standard,
it
has allowed Novell (with mono) and GNU chaps to produce CLI/C#
implementations
for many different platforms (over 7 chipsets on various platforms [mono]).
Therefore I do not think Microsoft are trying to lock you into anything!
Of course if you stray from ECMA standard you may find your code is not
as portable as you would desire but Novell are trying very hard to provide
compatibility for various Microsoft specific components such as WinForms,
and ASP.NET too.
I think the ECMA .NET architecture is in fact more open that its
competitors!
But don't just take my word for it, have a read yourself.
ref : http://msdn.microsoft.com/netframework/ecma/
ref :
http://www.ecma-international.org/n..._CSharp_CLI.htm
ref : http://www.mono-project.com/ECMA
ref : http://www.mono-project.com/Supported_Platforms
ref: http://www.mono-project.com/ASP.NET
ref : http://www.mono-project.com/Windows_Forms
ref : http://dotgnu.org/
-
Stephen
"Clark F Morris" <cfmpublic@ns.sympatico.ca> wrote in message
news:ri33g2h0ivnku0qr96hqjqhl5i29fiaocp@
4ax.com...
> On 8 Sep 2006 04:51:29 -0700, "JohnCrowley"
> <johncrowleyuk@yahoo.co.uk> wrote:
>
> The major problem with .NET is that it locks your organization to both
> an operating system and a computer architecture. This means that if
> the platform is not scalable for your organization's needs, and you
> find out three years down the road, it will be "fun". On the other
> hand most solutions tie an organization to a platform to some extent.
> There is more flexibility if you use a solution that is multi-platform
> (Websphere or its competitors for example), especially if the base is
> open source. Another problem with any solution is that it tends to be
> replicated within an organization for tasks which it can handle so the
> initial use isn't the only consideration. Be wary of all vendors. If
> possible financially attend user group conferences for the product and
> talk with the users.
| |
| Richard 2006-09-11, 6:55 pm |
|
Stephen Gennard wrote:
> The environment (CLI - Virtual Machine) and the C# language were both
> submitted to ECMA and have been approved.
ECMA is the European Computer Manufacturers Association, it is just a
group of companies. They will approve almost anything as long as a
company is willing to pay the costs.
> Because the environment and the C# language are backed by a ECMA standard,
> it
> has allowed Novell (with mono) and GNU chaps to produce CLI/C#
> implementations
> for many different platforms (over 7 chipsets on various platforms [mono]).
>
> Therefore I do not think Microsoft are trying to lock you into anything!
Of course MS are trying to lock everyone in, that is what they do.
They failed to take over Java by extending it so they did their own.
They will continue to have new additional features at every opportunity
just so that mono is at least one step behind.
> Of course if you stray from ECMA standard you may find your code is not
> as portable as you would desire but Novell are trying very hard to provide
> compatibility for various Microsoft specific components such as WinForms,
> and ASP.NET too.
Exactly.
> I think the ECMA .NET architecture is in fact more open that its
> competitors!
It may be, but the actual MS implementation and all the useful
extensions are not.
|
|
|
|
|