OpenEdge AppServer Perspective - Adding a remote server

Remote appserver support is not added in 102B release. Only local appserver is supported

Is there any intention to support remote AppServers in future releases or is that something that is not considered a good idea?

I can see arguments being made both ways:

In favor:

     Developers should be able to deploy code to any development AppServer that they are working with and have it auto-compile in that environment for unit test purposes.

Against:

     Developers may stomp on each other's code.

     Developers may abuse this and deploy to servers other than just development machines.

As far as I am concerned, the againsts are managed by policy and security so it should be possible to do it. If an organization wants to limit it, they can implement the appropriate policies.

Hi Bruce,

I asked this question very early on in the 10.2B beta program and the reply was that it is certainly the intention to support remote appserver. IMHO there is not much added value in supporting localhost AppServers only.

However, I can imagine that it will be pretty complex to support remote AppServers. For example, deploying code to another machine involves ftp instead of copy and compiling for other operating systems and bit-sizes. That will not be easy to implement.

Thanks, Peter.

Hi Bruce,

Welcome back to the OEA forum!

Adding remote publish support for AppServer and Webspeed is on the roadmap. In 10.2B we ran out of time and weren't able to get this feature in time for the release.

In the past, I had asked a few customers for their use case for needing remote plublish and if I can summarize the answeres I got - I need to test my code against multiple environments and if I have to re-create those environments locally, then it defeats the purpose. So provide me the ability to publish remotely for appserver and webspeed environments so I can test.

We are assuming that remote publish feature will only get used for development / testing pupose only and not for deployment.

Do you have a different use case than this?

Regards,

Sunil.

Hi Sunil,

Thanks. It's good to be back.

I would agree that the only use cases that should be supported are the development and test use cases. The problem is that you need to consider a couple of complicated caveats to those use cases.

It is likely that, even in a development configuration, users will (and should) be using NameServer Load Balancing. If this is the case, it is reasonable to expect that the code will need to be deployed to more than one server concurrently. This means that either the servers have to share a code base on a share, or they have to put the stuff in shared PLs - something that I would not recommend in a development configuration.

I have found that one of the best ways of dealing with the deployment issue is through check-in to a branch in the repository and then an automated build from there.

As you are busy figuring out how you are going to implement this, I would also take some time to look at GlassfishV3. Sun has done some interesting stuff to simplify the deployment to Glassfish servers and Progress could benefit by learning from their example.

Regards,

Bruce

Thanks for pointers on load balancing and Glassfish.

Is it a common use case to use load balancing in a development or test environment? Can people on this forum chime-in if you use load balancing in dev or test environment?

Thanks.

Sunil.

> Is it a common use case to use load balancing in a development or test environment?

It better be, because if you are planning to use it in production, you better have a really good understanding of its implication on your application.

Which is, of course, why the PSDN SDK should not have an eval copy of Sonic since one can't then practice the setup of a production system.

I need a button for "Unhelpful Answer" for your answer, Thomas!

There is nothing in anything that I wrote above that implies that NameServer Load Balancing should be part of PSDN, although I do believe it should be. It so fundamentally changes the behavior of an AppServer that developers really need to understand those ramifications in the design of their application.

And as you know, I believe that Sonic ESB should be available as a PSDN download (even if it is an extra charge for the product). But raising that in this context has absolutely nothing to do with the topic at hand.

Sonic is a part of the SDK, but it is an "eval" version which doesn't allow you to do a lot of the configuration which is required in a production environment.  I am agreeing with you that the development environment should have all of the same technology as the production environment.  OEA should support that complexity.  And, the SDK shouldn't get in our way.

Hi Sunil,

At Supercorp we have our Development/Test Environments and servers setup the same / very similar to our Production Environment.  In our case we have quite a complex set of server components to deal with as we use .NET client, connected through IIS / Tomcat Bridge / TomCat / AIA to Load Balanced Name Servers to App Servers to multiple DBs, also have IIS to WebSpeed Servers to multi-DBs.  All the development setup mirrors / is like our hosted SaaS environment.  As we are multi-site as well, we can jump between logging into the hosted environment or development, test or even our inhouse "client" in our other sub-division.  This makes supporting and testing any bugs or issues much easier.

At the moment, each developer has their own mapped network drive eg U: for their "User" workspace in OEA and an M: drive for access to the development / test product areas on the development server.  What is M: to the developer is D: on the development server.    We use SVN with commit hooks to fire off builds using Hudson and for moving things via SVN into the combined disk based development / product area.   However, each developer has their own appserver that points to their workspace, so they can unit test changes in their workspace before committing.  This was necessary as we have Visual Studio .NET C# client code that needs to changed potentially independently to the ABL code or synchronised depending on if the .NET Proxy APIs change etc.   Through the startup .p in the appserver, we can control upgrades that do not have schema changes.  So Fixes can automatically apply.

I know this sounds complex and to some degree it is.  But the whole process has been setup as we don't have any other way of easily handling remote servers through OEA.

We are eagerly waiting to see if the Remote Server capability will remove the need to use map drives as - it is ok at work but working remote we have to use VPN to retain mapped drives etc, instead of using a publish protocol to a designated personal AppServer.   I still think I'd enforce that the developers unit test in their own environment (.NET running on local PC and Personal AppServer on our development server) then commit through our normal SVN process as it shows up immediately any Build Fails - so feedback is quickly emailed back if an integration issue with other developers arises - typically rare.

Let me know if you need more information.

Regards

Paul Petersen

Good to hear from you after a while! Thanks for the setup info and your use case for needing remote publish.

In your dev/test environment, would you prefer to use the publishing across load balanced name server configuration or just a publish to a remote appserver would do the trick. Let me know.

Actually let me elaborate a bit on what I am saying. In your test environment, lets assume you have 2 brokers b1and b2 configured thru' name server. When we have remote publish capability in OEA, you could register b1 and b2 in OEA's server view and associate the same projects (code) to both b1 and b2. So when some appserver code changes, that code would get published to both brokers. Would this work?

Sunil.

Hi Sunil,

In our dev/test environment it wouldn't really matter if we could only publish to one appserver because in our case the brokers/appservers can all be configured to point to the same code base.  If you had a hetrogeneous environment or multi-VM environment eg testing linux and windows side by side or Windows Vista 32bit and Server 2008 R2 64bit side by side - then it might make a difference.  Also it might make a difference if the code compiled.  We run with source code in our dev/test environments at present but this may in future limit remote debugging.

Your suggestion of providing the ability to register seperate brokers/appservers with the same project sound excellent!  I can see that this would provide the flexibility for a range of purposes - not just the ones above.

Another few questions off topic

(1) Will there be hooks in the publish for us to perform additional actions/activities.   For example - if we wanted to rebuild our .NET proxies ie DLL or republish web services etc??

(2) Previously there has been talk about having .NET proxy build from within Architect is that still on the agenda.

(3) Probably more for Ken but we still have to list the .p's for the proxy build or service creation - instead of being able to use ANNOTATIONS in the code to determine the list of interfaces/services needed.  If OEA was to have proxy building - it would be ideal for it to be able to scan the code base for what code needs to be included in it - automatically.

(4) Different topic again - Language / Keyword HELP in OEA is a bit useless - it would be great to be able to search it like the old HELP.

Regards

Paul  

(4) Different topic again - Language / Keyword HELP in OEA is a bit useless - it would be great to be able to search it like the old HELP. 

Hi Paul,

I have reported this several times as well (and I know about others too) but nobody at PSC seems to understand the problem.

An excellent workaround that we use in the meantime is separately starting an OpenEdge -> Help session.

HTH

-peter

Hi Peter,

Yep - that's how we get around it too - but it continues to be one of my developers complaints.  If it was fixed we would be able to stay 100% in OEA :-)

Regards

Paul

Hi Paul,

Thanks for your quick response.

 
In our dev/test environment it wouldn't really matter if we could only publish to one appserver because in our case the brokers/appservers can all be configured to point to the same code base.  If you had a hetrogeneous environment or multi-VM environment eg testing linux and windows side by side or Windows Vista 32bit and Server 2008 R2 64bit side by side - then it might make a difference.  Also it might make a difference if the code compiled.  We run with source code in our dev/test environments at present but this may in future limit remote debugging.

Currently in 10.2b, we do support ability to publish either .r's alone or .p's and .r's. We intend to retain that functionality for remote publish. Hopefully that should help in debug use case.

Another few questions off topic
(1) Will there be hooks in the publish for us to perform additional actions/activities.   For example - if we wanted to rebuild our .NET proxies ie DLL or republish web services etc?? 

If I am not mistaken, I believe in 10.2b we fire events for before and after publish. Does that help? Also, are you looking for ABL events or Java events or Eclipse extension points and also for source or destination ?

(2) Previously there has been talk about having .NET proxy build from within Architect is that still on the agenda.
(3) Probably more for Ken but we still have to list the .p's for the proxy build or service creation - instead of being able to use ANNOTATIONS in the code to determine the list of interfaces/services needed.  If OEA was to have proxy building - it would be ideal for it to be able to scan the code base for what code needs to be included in it - automatically.

Integrating Proxygen in OEA is on the roadmap but at the moment its not on the top of the priority list. If you think this needs to be higher-up on the list, feel free to provide your input. Also, integrating a proxygen with annotations at source level has depedency on annotations in the language (in r code), which is also on the roadmap for ABL.

(4) Different topic again - Language / Keyword HELP in OEA is a bit useless - it would be great to be able to search it like the old HELP. 

I have not heard of this issue before, can you or Peter please elaborate on the issues with existing HELP?

Thanks,

Sunil.

Like Paul, I use automated build software to get around this problem today. My automated build takes code from a subversion repository, compiles it and makes it available on shared drives. The problem is that there is a lag between the time the code gets checked in and the time it is actually available.

Furthermore, the AppServer doesn't necessarily know that the code has changed, so you have to have a way of trimming and re-adding agents.

Where this is a real problem is when you have 32-bit and 64-bit linux machines servicing the same AppServer partition that are all behind the same NameServer. You cannot deploy through the NameServer. The only way to do this is via platform-specific builds.

But I think we are trying to solve too many problems. This is intended as a development tool and let's not lose focus by trying to expand its scope beyond that. If you can have the tool support deploying the code to the AppServer, compiling it and having it available on a central share for all agents and then have the agents automatically trim and re-add to accommodate the changed code, we are all set.

Yep - that's how we get around it too - but it continues to be one of my developers complaints.  If it was fixed we would be able to stay 100% in OEA

I did use the separate prowin32 session for the online help also for a way too long time. Right now I've got used to the "Help" view in Eclipse. It offers a search for keywords as well. I'm using that as a Fast View (like the class browser). Makes it almost as good as the old online help...

Hi Sunil,

The major complaint about Help sounds like a very simple one but it annoys them a lot. 

My developers just want to be able to search from within Keyword Help View - ie Shift-F2 .  Typical use case -  Developer looks up a keyword by highlighting text and/or Shift-F2 to bring up the Keyword Help View.  Then they need something else eg some phase etc or need to jump to something else.

They can only do this by one of two 'longer' ways:

   (1) Click on the Index Button and then do a Ctrl-F to find what they are after within the Index only.  Not always satisfactory as it isn't doing a full help search.

   (2) Start up Full Help via Alt H,E to get to Help -> Search and then type in the search term and GO.  Slower to access after reaching Keyword Help, also search without a scope is slower until indexed etc.

Solutions they have proposed are:

  (1) Allow a Search Help button or similar capability from within Keyword Help

  (2) Have a way to put the current code text/keyword into the Help -> Search with simple keystroke.

Easy right :-)

Paul

Hi Paul,

Thanks for the detailed description - I understand the usability issue now. I would appreciate if you could log this as an usability issue in the ERS for me.

Regards,

Sunil.