Sounds like you are getting into issues of the environment variables. Make
sure that your IIS user has the environment variables required for running
jBASE.

-Bob

"Mark" <marklb (AT) bogus (DOT) net> wrote

It's one of the wonders of using .net (imho) that you can use the technology
from end-to-end...

On the web server (aspx) ... on the web service (asmx), on the application
server (frontending jRCS)...

I've always been in two minds how to implement the web service side of the
equation though... I've played with creating a seperate web service for
each interface, or to provide a generic interface (ie single call) which
passes a "stored procedure" (ie databasic subroutine name) some parameters
(as XML) and returns a dataset.

Maybe I'll find time to provide generic code that works in each layer, which
provides a web service that takes the "generic" interface above, and calls
the databasic subroutine. There would be several different layers:

1. The web service itself - this would convert the call into an entry on
an MSMQ message queue
2. The "middle-application" service control layer - this woudl run as a
Windows service and would control a number of "worker" processes on the
server. This would sit on the jBASE server.
3. The interface between the message queue and jRCS which calls the
subroutine - the number of these processes would be controlled by the
service. This would do the conversion to / from XML/datasets and call
thedatabasic code as necessary.

Each layer isn't particularly difficult, I have them all written though they
are designed for our application. The only issue is designing the data
formats (dataset and dynamic arrays so that dynamic arrays can be
generically converted to and from a dataset or generic XML).

This is a "Microsoft" end to end solution (though the webservice consumer
doesn't necessarily have to be an asp(x) web page - it could be called from
php, jsp or other technology). The whole thing could be converted to
running in other technology replacing all the microsoft technolgies with
other technology. But, for me, this displays one of the hot points of
..net.. You can use the same underlying technology end-to-end and it
interfaces nicely with all the other "bits" (IIS, SOAP, JRCS and MSMQ in
this case) to just "work!

Bugger this,.. maybe I should write it and sell it!! <G>

Regards
Regards

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

You may find the following web page helpful :

http://httpd.apache.org/docs/1.3/howto/cgi.html

It's targetted towards apache and perl but most of the concepts are the same
with IIS/jBASE

Regards
Simon
"Mark" <marklb (AT) bogus (DOT) net> wrote

I really don't want to get into this (I'm feeling much less contrarian
than my normal self lately) but here are a couple casual comments:

About how to do web services, one service with lots of functions or a
bunch of little services: This is the same as designing a BASIC
subroutine: Do you allow a diversity of parameters to be passed in,
and then use a CASE structure to branch around to process different
functions? In most cases we have many subroutines, each of which has
a small number of related functions. This is probably the best model
to follow for web services as well: Provide a concise interface which
isn't subject to too much interpretation or user/developer error.
Don't expose more functions than a given Consumer needs. Keep the
number of possible points of failure for any given service as small as
possible.

I have no idea why you're using MSMQ. Maybe that's just one of your
transport mechanisms - yet another benefit of these for-fee products
is that you don't need to write custom transports like this.

A Windows Service?? Again, I have no idea why you'd need this in the
mix except as a custom listener of some sort.

XML, jRCS, datasets, messagequeue interfaces... Holy cripes that's a
lot of unnecessary infrastructure ! Rube Goldberg would be proud.
Don't let people get scared away thinking this stuff is tough. I
wrote about 10 lines of code and then used a Wizard to generate a web
service wrapper around it. With another wizard to generate a client
to the service, the code was tested and I was off to something else in
just a few minutes.

Write and sell it?! Ah yes, saw the <G>. Haha, almost had me - but
of course, we know people in this market don't buy connectivity tools.

T


"Simon Verona" wrote:

ok.. to explain some of my thinking...

1. Single Web Service vs multiple

Single web service with parmeters is easiest to implement as a
developer. However, a web service for each function can be more descriptive
for the consumer (you can use WDSL to "advertise" each function).
Personally, I still prefer the first method with documentation to support
each function call. This works in our "closed" development environment. It
wouldn't work if you were providing web services for "general" use. It means
for us that all the "middleware" remains static (which seeing as we have
databasic programming at one end and windows/web programming at the other is
a benefit!).

2. XML

As the data coming back needs to be serialised through the web service
and brought back in a generic medium, XML is the best choice. For anybody
who is going to consume a web service, bringing the result back as XML will
make life easier. I actually bring the data back as a serialised dataset
(which is in XML structure) which can be loaded into a .net dataset in one
line of code. The transfer to/from XML/dataset is carried out in the
"application interface" layer before the result is put onto the message Q.

3. MSMQ

I use Message queuing to prevent server overload. I can control how
many processes are being run in parallel - as I create a fixed number of
"worker" processes that dequeue the message queue.. It also means that
there are no jBASE connections outside of the application server (so all
jbase connections are local and share a single jBase licence). Using
message queuing also makes it easy to distribute the load over multiple
servers (hot swap fallovers are easy in this environment). Also, network
outtages are sorted by the message-queue which guarantees delivery over the
network.

4. Windows Service

The windows service does nothing more that control the start/stop of the
worker dequeue processes that I refer to in the above. It monitors that
they are running properly. It's about 20 lines of code...


The key to all of the above is that all the technology is wrapped up in
these layers. It provides a simple and consistent development interface for
both the databasic programmer (who works with dynamic arrays) and the web
service consumer works with xml datasets. Al developers are happy. From
a run-time cost perspective, you only ever need one jBASE licence for the
complete web application - (I don't know how this would work with other
variants of MV).

The actual code is pretty simple... The web service is only about 30
lines of code (just puts an entry on the message q and then waits for the
response). The application server code is also only about the same no of
lines of code. The most complex part of code converts a dynamic array
returned from the databasic code to a dataset - but even this is only about
15 lines of code!

Ok, you need to configure message-queuing - but this is pretty simple if the
web service runs on the jbase server.

So, whilst for the people that like acronyms and technology it has lots of T
and F (3/4) LA's and ticks lots of technology boxes. But with .net, 99.9%
of this is encapsulated within the .net framework. and the actual code is
pretty simple..

For example... The web service is a vb.net web project with a single
function as below. It returns a string value (which is an xml
representation of a dataset normaly - though this could simply return a
dataset). Whilst there is some fiddling around with datastreams in the
code, the message queuing code is pretty simple.

I'm way way off topic for this newsgroup. but the point i'm trying to make
is that there is no need to be afraid of the technology! You can build
very stable scalable solutions using this sort of technology. I use this
same technology to interface my windows front end to the application (though
i use remoting rather than a web service to do this and I actually bring
back the dynamic array into my windows application and provide a class
library to work with these and do the databinding locally).

I share Tony's frustration that MV developers generally seem slow to make
use in advancements outside of MV to enhance MV. Using simple (ish!) bits
of home-grown middleware, I feel that MV compares very favourably with
"relational" solutions. The MV data model is superior (imho) but misses this
sort of middleware built into the solution to make is work. I think
Northgate have done some work in Reality-12 to allow a databasic program to
be exposed as a web service and I believe cache can do it..

Anyways, it's Xmas day... I should be doing something with a turkey, or
drinking something ...

So, may I bid you all the best for Xmas... and for 2006.

Regards
Simon

=== code follows ===

Public Function CallProg(ByVal ProgName As String, ByVal Parameter As
String) As String

Dim MessageQueue As New MessageQueue(".\Private$\jBaseQueue")

Dim Message As New Message

Dim ReturnMessageQueue As MessageQueue

Dim ReturnMessage As Message

Dim bw As New BinaryWriter(New MemoryStream)

Dim br As BinaryReader

Dim TmpQueue As Int32

QueueNumber = QueueNumber + 1

TmpQueue = QueueNumber



Try

ReturnMessageQueue = MessageQueue.Create(".\Private$\ReturnQueue" &
CStr(TmpQueue))

'Else

Catch

Try

ReturnMessageQueue = New MessageQueue(".\Private$\ReturnQueue" &
CStr(TmpQueue))

Catch

Err.Raise("9999", "DMS Server Error!")

End Try 'End If

End Try

Message.Label = ProgName

bw.Write(Parameter)

Message.BodyStream = bw.BaseStream

Message.ResponseQueue = ReturnMessageQueue

MessageQueue.Send(Message)

ReturnMessage = ReturnMessageQueue.Receive()

br = New BinaryReader(ReturnMessage.BodyStream)

If ReturnMessage.BodyStream.Length > 0 Then

CallProg = br.ReadString

Else

CallProg = ""

End If

MessageQueue.Delete(".\Private$\ReturnQueue" & CStr(TmpQueue))

End Function



"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

I'd say you're proving the concepts that a lot of diligent work will
yield a fine solution, but just think of all of the things you had to
learn, and all of the various components required to make it work. In
fact, this is almost a testimonial that MV is capable of doing such
things (integration with mainstream technologies), but that there are
tools available which will cut development time by months and reduce
the maintenance effort significantly. IMHO you're doing some cool
stuff and it's great to see it working - I just doubt that even after
your generous postings of code and explanations over the last year or
so of what your doing that anyone else will be able to follow in your
footsteps. Whereas by adopting a tool like mv.NET, someone who is
just getting started with .NET can hit the ground running immediately
- it's like writing Pick BASIC code in Visual Studio rather than ED.
(In fact mv.NET does have a Pick BASIC editor in VS so that you can
write your server code in the same environment as your .NET code.)

About licensing, it seems neat that you're using a single jBASE
license for all of this - let's say you're getting the most for your
money. But what happens when a single request takes longer than a few
seconds? Does everyone else wait on the queue? Do you have dynamic
session pooling to flatten the load? Are you doing any sort of
persistent locking? How are you managing session state? All of these
features are included in mv.NET. I'm sure you can implement these
features if you wanted to just by throwing more code at it, but I'm
wondering exactly how much all of this "free" technology is really
costing you in terms of actual time, lead time to project delivery,
end-user perception of quality and performance, and maintenance costs
should you decide to go on vacation and have someone else figure out
how it works.

And BTW, mv.NET works with a number of MV platforms, including Reality
- if their developers want more than just Web Service connectivity.


Regards,
T

TG@ removethisNebula-RnD .com

"Simon Verona" wrote:

Tony

I 100% agree with you...

You have to remember that my solution predates mv.net and other similar
tools that would work in a .net environment.

The core point that I'm trying to get to is that whilst the technology in my
solution would be alien to somebody coming from a multi-value background,
for a .net specialist this is pretty straightforward.

As you say, my solution has "grown" over time as I've realised more and more
of the potential of the approach that I've taken.

As for the answers to the questions you ask... my solution does have most
of the features that you mention with mv.net. Had I started with mv.net
5 years ago, I would probably have used that in my solution. In some areas
my solution is better than mv.net - but most of these are invalid for the
user community at large, but are due to idiosyncracies in my application.

As far as maintenance of my solution goes, it's pretty minimal (the original
solution was written in a weekend - including most of the databound
"widgets"). Whilst its had time spent on it as my application has evolved,
in terms of a proportion of my total development time spent it's minimal.

But to summarise, you are right... Because my solution uses jrcs, I feel
that it is nice to point out some of the options for extending jRCS in this
way, instead of going to mv.net. You will recall that the OP just really
wanted to call a subroutine and generate a web page. I personally think
that mv.net is OTT for this simple solution - though the OP may recognise
that as his requirements grow mv.net may be a better solution.

Also, I like a challenge... building this interface helped me to learn
some of the more advanced techniques in .net which have helped me to develop
my application software.... Every cloud has a silver lining!

As far as vacations go.. I don't take any! To be fair though, whilst my
solution sounds high-tech to a multi-value world, it's pretty meat and drink
to a reasonable dotnet developer. Ironically, the weakest part of the
solution is actually bugs in jrcs.net - the only third party (ie non
microsoft) library used in the solution - ironic eh!.

Regards
Simon



Whilst I've eval
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote