Monolith VAST application >> THIN WEB CLIENT + SERVER

Hello,

we are planning on migrating one of our VAST applications to the form of: THIN WEB CLIENT + SERVER.

At the moment, the product is a typical monolith application with heavy use of GUI and the business logic is
coded inside Window/Dialog classes. The application architecture could not even be called FAT CLIENT,
since there is no server component at the moment. The application only communicates to the DB
by directly executing SQL queries. Our customers may use up to about 100 concurrently running
instances of the application.

We are planning on providing a thin web client interface to the users while running the business logic
in a user-session manner inside an application server - possibly Oracle WebLogic (could be other).

All the application code is written in VAST and the application server works well with Java.
We would like to make use of our existing VAST code as much as possible. We do not want to convert it to Java.

(a) It seems we need to make it possible for the Smalltalk business logic to be called remotely
from the application server (from Java) possibly using Web Services.

(b) It also seems we need to implement some session management within the Smalltalk code.

Do you have experience with migrating monolith applications (or fat clients) to thin clients and a server?
Do you think the points (a) and (b) are reasonable?
Could you recommend us some specific technology, products, frameworks or tutorials?

Thank you very much in advance for any help and tips!

Regards,
Martin Vavra.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Hello Martin,

Interesting questions!

(a) Yes, you definitely need to separate your business and gui logic. After this seperation you can make the business logic accessible to the outside world using some kind of interface. This interface can be based on XML webservices. You can also use a simpler and faster message format like JSON or some kind of binary protocol like Protocol Buffers (from Google) or MessagePack.

(b) Depending on the way your business logic is setup you can offer a stateless or statefull interface. When you require a statefull interface you have to implement some kind of session management. This is not too difficult but it will make scaling and fail over harder to implement. So it becomes difficult when you have to service more users, requests etc.

Of course there is an alternative solution. Implement the web gui in Smalltalk instead of Java! Than you don't need to call your Smalltalk business logic from the outside. Seaside is an excelent web framework for Smalltalk and much nicer to work with any of the Java web frameworks. Note that you still need to separate the business logic from the current native gui.

A possible technical challenge is concurrency. A server application has to process multiple requests at the same time. You will have to check your business and persistency logic whether it will work correctly in a concurrent environment. If this is not the case than you can try to fix this using semaphores. In our situation it was very difficult to make our legacy persistency framework concurrency-proof. We decided to work around this problem by queuing all requests and handle them one at a time. In a stateless design this works very well.We can simply start additional instances of the server when we need more performance or throughput.

Jan.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.

Hello Jan,

Friday, June 17, 2011, 10:20:45 AM, you wrote:

> Hello Martin,

< snipped />

> Of course there is an alternative solution. Implement the web gui
> in Smalltalk instead of Java! Than you don't need to call your
> Smalltalk business logic from the outside. Seaside is an excelent
> web framework for Smalltalk and much nicer to work with any of the
> Java web frameworks. Note that you still need to separate the
> business logic from the current native gui.

Yes. It will likely be difficult to morph your existing code into a
service that handles concurrency well. In fact, it's  challenge even
with new code. I recommend single threading requests in your smalltalk
image, and run multiple images. I've had good results doing this with
the VA Web Connect framework/parts (Yes. I know it's ancient, and
Instantiations doesn't appear to want to upgrade it to current HTML
specs). It was quite easy to modify the web connect session data
classes to persist the session data objects, so it didn't matter
which smalltalk image processed the next request.

You can use the same (multiple single threaded images) approach if you
want to service XML requests from your Java front end. I would put
Apache serving as a load balancer/proxy in front of the smalltalk
images so the Java requester has no idea how many smalltalk images
there are.

Doug Swartz

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To post to this group, send email to [hidden email].
To unsubscribe from this group, send email to [hidden email].
For more options, visit this group at http://groups.google.com/group/va-smalltalk?hl=en.