Is it possible to add an AppServer that is not a "localhost" server to the Server Explorer view in 10.2B?
I tried this using the New Server wizard and the minute I type anything other than localhost in the host name, the option to add a Progress server goes away.
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:
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.
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.
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.
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?
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.
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?
> 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.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
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.
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.
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?
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.