We currently have a 4GL Application written in PowerBuilder and C.    The
PowerBuilder deals with the UI and the C does most of the business logic.
We want to convert the C to VB.NET (as we use that in our web app and so am
familiar with it), but don't know the best place to deploy it.     The code
is DB intensive, but also does a lot of calculations.    We could just
create an assembly that we call from PouwerBuilder on each client, or we
could put it in a web service, or finally put it in the DB inself though
that would mean our customers would have to upgrade to SQL Server 2005
(currently using 2000).

Any thoughts ?

Hello Adrian,

From your description, you have an application originally developed through
powerbuilder(front UI) and C (components) and now you want to convert the
project to .NET framework based solution, correct?

Based on my experience, for your application's migration you can consider
the following strategy:

1. for front UI part, use VB.NET 2005 winform programming interface to
rewrite it

#Windows Forms in the .NET Framework 
http://msdn2.microsoft.com/en-us/library/96bef039.aspx

2. for data accessing, I would suggest you consider rewrite them through
the ADO.NET interfaces:

#ADO.NET 2.0
http://msdn.microsoft.com/data/ref/adonet/default.aspx

3. for those calculation components, are you encapsulated them through
native C dll? If so, you can either rewrite them through .net class
library(assembly) or still use the original native C dll directly through
.net interop (platform invoke):

#Consuming Unmanaged DLL Functions
http://msdn.microsoft.com/library/en-us/cpguide/html/cpconconsumingunmanaged
dllfunctions.asp?frame=true

Hope this helps some.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Steven,

No, you missed the point entirely.

As I said, we're going to rewrite our business logic C code in VB.NET, but
don't know the best play to deploy it.

Is it best to just compile it into an assembly and call it directly from the
powerbuilder client

Or Is it best to deploy it to a web service and call it via SOAP (args are
simple datatypes)

Or should we embed it as SQLCLR code inside a SQS2005 database  (our concern
here is how much extra load this places on the DB server)

Or some other middle tier deployment platform

?

-Adrian




Show quoteHide quotehttp://msdn.microsoft.com/library/en-us/cpguide/html/cpconconsumingunmanaged
Show quoteHide quotehttp://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
Show quoteHide quote

Thanks for your quick reply and the further description.

Well, now I get that your concern is which deploy approach should you
choose for your rewriten VB.NET based business logic component.

Is there any particular requirement that you need to make the business
component a distributed component like webservice? If this is not
necessary, I would suggest you simply design it as a normal .net class
library and call data access component to access backend database. Thus,
the component library assemblies will be deployed with the client
application. This will provide us better performance since directly access
to backend database will use database provider specific binary protocol
which is much more effeicient than XML webservice.

Also, I don't think it is necessary to use SQL-CLR here.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

Doesn't it depend on how much DB access we're doing ?

Some logic might be creating 500,000 transactions, depends on (in this case)
how big the company we're calculating the payroll for.

This particular logic can be called from the desktop app or from a
background server app running on a dedicated machine, or in the future,
called from a webpage (would only do calc for one person, not the whole
company in that case)


Show quoteHide quote

Hi Adrian,

Generally, directly ADO.NET access will has better performance and XML
webservice will add additional overhead as it transfer XML based soap
message and any binary data should be encoded.

As you mentioend that the business or data access logic will be reused by
other application front, then, move the business component to server-side
and isolate it as a separate layer should be reasonable. However, if you do
not have critical interopability requirement, there are other binary based
distributed communication options in .net framework such as remoting  you
can consider.

In addition, the real world performance consideration for XML webserivice
or other binary based distributed component also depend the processing time
at server-side, if the processing time is much larger than the network
transfer time, then, the performance overhead of webservice can be omitted .

#Choosing a Distributed Technology
http://msdn.microsoft.com/webservices/choosing/default.aspx

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

Of the three choices, I'd go with the web services (or WCF services).

Creating a client dll that you distribute means also distributing the .Net
framework and, in general, dealing with all the hassles of rich client
deployment.  You already deploy the powerbuilder client.  No reason not to
have it call the web service.

You also get a couple more benefits:
-- your app moves some functionality to the web server.  This reduces the
dependency on the rich client.  You will be able to deploy a server-based
application that consumes the same services, allowing clients the ability to
choose if they want a rich client or a thin client.
-- business logic changes frequently.  Moving the business logic to the
server reduces the cost of rolling updates out across an enterprise.

You have some concerns to deal with,chief among them is security of the
service.  You also have to be concerned about the amount of communication
your app expects to do with the web service.  It used to be 'free' for PB to
call the C code, but now it will cost resources for each call, so you want
to make fewer calls and make them more meaningful.  If the PB portion of
your code expects to be very very chatty with the library, then a web
service may be less performant than you would like.

Calling code from the db is not a preferred solution, in my experience.
YMMV.

Show quoteHide quote

A question on 1.1 and 2.0 interoperability
ClickOnce Deployment and the ConfigurationSection
Help with creating a search engine in excel vba
How would you do a time estimate of a conversion from VB6 to dot net?
comparison reporting -- technique suggestions?