Re: Middle Tier (was Re: Table and Query Classes good or unnecessary?)
Writing from my phone while waiting for a LAX game to start..,
We ran a web client app back around 2008-2010 based in the old Omnis active X controls and we ran the load balancing on two proliant servers supporting around 2000 concurrent users. The back end was Oracle or Sybase and all selects or inserts/updates and deletes were done by stored procedure. This made the applications quite fast and maintenance was simple as we usually need only update a procedure to facilitate new queries or logic to get whatever we needed done without having to deploy anything new to the app. We actually migrated from Sybase to Oracle procedure by procedure. Data was kept synced by the dbas.
Anyway, I just wanted to say the Omnis as an app server is pretty capable as that solution ran pretty much 24/7 for years without suffering any real downtime related to performance.
> On Mar 15, 2018, at 5:24 PM, Reg Paling <email@example.com> wrote:
> Hi Marten,
> What’s your application? If you’re running a high-speed securities trading platform it’s going to have a very different sweet spot from running, say, a school where there is neither the same volume of data nor the urgency. Even on the trading platform only a small percentage of the code has to perform at the high level. So I think it makes sense to develop an architecture where the 80-90% of the code is in Omnis and the critical minor percentage of the code might need to be done with something else.
> >> 1. Omnis doesn’t handle multi-threading / multi process very well.
> It’s my impression that the workarounds for this shortcoming are not too onerous, i.e. the load-balancing setups may be a bit ugly but they work. Can those who have worked in this way, comment on this?
> >> 2. Remote tasks … cached data/objects…
> In my framework I have a handful of core task variables in the main task. My remote task superclass picks up a reference to these core task variables, and that way every remote task instance has access to cached data & the methods of these core instances.
> >> 3. …If a call causes a crash, the complete service is taken down.
> Yes, it is a big problem, and I have no idea whether it’s fixable except via the multiple Omnis instances mentioned in point 1.
> >> 4. When adding a middle tier you add an extra layer…
> This comes back to the 90%-10% principle. The 90% can be developed so efficiently in Omnis, and for this 90% middle tier logic in Omnis is fine.
> My new application is for an educational organisation, so I don’t know to what degree I will ever need the high-performance middle tier we are talking about. Certainly my customers are going to be hoping that they will get occasional good media coverage that results in huge spikes of inquiries on their websites. I think that sort of aspiration plays a big part in the decision to use one platform or another.
> It’s interesting that Bas put forward frameworks as the alternatives, whereas Marten you have put forward languages. If you go with a framework such as Rails, then that will tend pull your whole architecture into the Rails paradigm. If you go with a language, then you can keep your own vision but you have to piece together the whole middle-tier framework yourself.
> I hope I am wrong but it seems to me that points 1 and 3 are always going to be a trade-off for Omnis. I hope Omnis Software comes up with one or two tightly-integrated solutions to say “Here’s how you best manage the high-performance portion of your application”.
>> On 15/3/18 8:39 pm, Marten Verhoeven wrote:
>> Hi Reg,
>> I think there are three problems currently with Omnis as a middle tier (maybe four):
>> 1. Omnis doesn’t handle multi-threading / multi process very well. You have to install multiple instances to get multi process and add an intermediate layer in between to distribute the calls.
>> 2. Remote tasks are currently supposed to handle calls, but they are instantiated on every request which makes it hard to use prepared or cached data/objects. So, if you instantiate a table class, you cannot keep the instance alive for a next request, which means you need to instantiate it every time, or only use the main thread (which basically means you don’t use remote tasks as intended). This means a lot of overhead which kills performance.
>> 3. It is too unstable for a server-process. If a call causes a crash, the complete service is taken down. A crash of a call should only take down the execution of the current call, not the complete service.
>> 4. When adding a middle tier you add an extra layer on top of the (very fast) database access. So this extra layer should be very fast, and Omnis is not very fast. Especially not in manipulating big lists. So core-improvements to get performance gains can be required (depending on what you do). Just making sure to get the data from the middle tier to the client quickly can also be achieved by building an external component just for that, so that might be enough.
>> I have not investigated contenders heavily yet, but I would first look at:
>> – C#: very capable language and I could also build some client side stuff in the same language (windows, iOS and android). It is a big ecosystem backed by and important for Microsoft, so it won’t go away.
>> – Swift: Very capable and fast language and I could build some client side stuff in the same language (iOS only. Not being able to run on windows is a drawback). It will be remain a big ecosystem going into the future, as apple and IBM put a lot of weight behind it. Swift is the future for Apple, so that is pretty safe
>> – Python Lots of libraries on the server-side, but I am not a fan of the language and the tools I currently know and it is not an option for client-side development.
>> – Clojure – This is a very small contender. The only reason I am adding this is that I know common lisp pretty well and know how powerful and flexible the language is, but there probably are a lot of downsides to using it because it is a small ecosystem, not an option for client side development.
>> I would also investigate whether I could use protocol-buffers for communication between server and client in order to get fast transfer between them. I’m not sure if it is dynamic enough though. There still is a lot to investigate for me.
>> I do hope Omnis will be a viable option as well, because it is really flexible and very, very fast to develop in. And I can reuse a lot of code, so that is a big advantage as well.
>> But client side Omnis requires a major update as well, in order to build more modern, dynamic user interfaces instead of static windows 2000 style interfaces.
>> Both areas need focus and vision for me to have Omnis remain a long-term solution to build our software on.
>> Marten Verhoeven
>> —–Oorspronkelijk bericht—–
>> Van: omnisdev-en [mailto:firstname.lastname@example.org] Namens Reg Paling
>> Verzonden: dinsdag 13 maart 2018 0:30
>> Aan:email@example.com >> OmnisDev List – English<firstname.lastname@example.org>
>> Onderwerp: Re: Table and Query Classes good or unnecessary?
>> Hi Bas & Marten,
>> What enhancements do do want to see in Omnis, to better support the middle tier? What alternatives are you looking at, and what are their strengths etc?
>>> On 13/3/18 9:39 am, Bastiaan Olij wrote:
>>> Hey Marten,
>>>> On 12/3/18 8:55 pm, Marten Verhoeven wrote:
>>>> If they just prioritize the JS client I will have to make different choices. If they focus on the fat cl
>>>> ient to build your UI and on a better backend platform I will keep it all in Omnis.
>>> Exactly the choice that is in my head too. The JS Client is nice but
>>> its not a technology that currently interests me a lot. With where
>>> Apple seems to be headed I much rather see a continuation of
>>> enhancements in the fat client and as I’ve said many times before,
>>> hopefully some day an iOS runtime which should be within our grasps
>>> now that Studio 8 has seen the Mac OS X client rewritten.I believe it
>>> is even inevitable as I think we’ll soon see iMacs or similar devices
>>> running iOS. The JS Client I presume will remain a large part of
>>> Omnis’ future seeing how successful it has been bringing in new
>>> opportunities but I hope the company will see chances in the fat
>>> client and improving the middle tier capabilities also helps the JS
>>> client so that one is a given. The question for us is, will it be in
>>> time? Right now the most likely future for us seems to be using Omnis
>>> as a front end but another tool for the middle tier. The choice is not
>>> made however 🙂
>>> That all said, I can only underline how enthusiastic I am for the
>>> change of direction Omnis has shown. It’s definitely a matter of
>>> giving them time for this to start showing fruits. It takes awhile
>>> before a new direction gains momentum but I think we’ll be seeing some
>>> exciting new things soon.
>>> Manage your list subscriptions athttp://lists.omnis-dev.com Start a
>>> new message ->mailto:email@example.com
>> Manage your list subscriptions athttp://lists.omnis-dev.com Start a new message ->mailto:firstname.lastname@example.org _____________________________________________________________
>> Manage your list subscriptions athttp://lists.omnis-dev.com
>> Start a new message ->mailto:email@example.com
> Manage your list subscriptions at lists.omnis-dev.com
> Start a new message -> mailto:firstname.lastname@example.org