Perhaps I got this wrong. But maybe you can clarify a thing or two for me. Firstly is it possible to get a LINUX Application Server? If so is it possible to get a LINUX Application Server toact as a container for EJB's.

Incase you are wondering where I am coming at this from. Basically I recieved the following blurb:

"A workflow application is to be developed for a telecoms company. If a customer requests a new account, makes a billing enquiry, requires new services set up, etc, all these must go through the workflow app.
The customer service team will use the workflow app to manage and track these requests. Requests may be sent out to teams working in other departments, e.g. billing, before issues can be resolved.
A rich GUI style application is required by the customer service team, but many of the teams are distributed geographically who require access to the application.
The billing process, for speed purposed, is run on a cluster of LINUX boxes, with the billing process carried out by a custom built C++ engine. The workflow app must talk to the billing process to get status and account info.
The system must be able to export data in a format which can be recognised by the accounts system for reconciliation purposes.
If new workflows are required, a ‘power-user’ must be able to create these workflows and assign roles and responsibilities."

I was thinking of just proposing an EJB application running on a LINUX Application Server. The c++ engine could talk to the EJB's via CORBA / IIO, but perhaps it might be better to argue that the "billing process" be developed as an enterprise bean too??? Perhaps it might be possible to buy and customise a generic "billing process" component???

To deal with the idea of "A rich GUI style application is required by the customer service team" - A java application could be proposed again communicating via RMI-IIOP. But again a better solution may be to use Java Servelets or applets as "many of the teams are distributed geographically who require access to the application"

The other issue that "The system must be able to export data in a format which can be recognised by the accounts system for reconciliation purposes." To tackle this I was thinking of utilizing J2EE's we service technologies and exporting / saving  the required data as an XML file. Most accountants use Excel religiously and surely Microsoft have a function to import XML. If not another solution would be simple to export the data to delimited text file and then import them in Excel - this will also overcome any Excel version issues

I think I have tackeld most of the issues at play here. I was just wondering what you as experts though of this. Also is any of this incorrect or just impracticle.

Any advice, suggestions, imporvements, alterations, etc are more than welcome and truely appreciate. Thanks a million :)

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Here's the short answers:
Firstly is it possible to get a LINUX Application Server?
If so is it possible to get a LINUX Application Server toact as a container for EJB's.

And I find your further consideration quite reasonable. :)
bowemcAuthor Commented:
WelkinMaze  - Thaks for your comment. Do you tihnk I would need to make any consideration for the fact that it is a "workflow appliction" or do you find this irrelevant to the desifn of my solution????


>>And I find your further consideration quite reasonable.

Do you mean all of them? For example I start one argument my suggesting the c++ engine be connected via CORBA/IIOP, but follow it up by stating may be buying and customizing a componet would be a better solution.

Are both these approches valid?? And am I correct in stating the procurement of a component would on the basis of the info provided be a better route?

Again, I have a similar Query regarding my state ment about a Java application Vs Servlets/JSPs and again regarding exporting of the data to excel via XML Vs. delimited text file.

Finally do you think I have neglected any other factors / issues or have any better suggestions??

Thanks again for your inital input - its very much appreciated :)
Hi again,

I think either way that you've mentioned is suitable and I don't think that the "workflow application" has so much of an impact itself.
Concretely about you alternatives - I think that you can afford to purchase or develop the needed component then it is a good option. "billing process" doesn't sound to me like something needing an immense speed or resources so that the only option to be C++.
Furthermore I think that Servlets/JSPs approach is a good one. When they are well used quite a rich GUI could be done with them.
And finally about XML I think it's a more universal format than delimited text file. It's quite easy to manipulate it and also it's easy to convert/export it to other formats if it's necessary.

Finally, I think all of your alternatives are applicable but of course it always depends on many things. For example if you are required to have lower net trafic the plain text files will have an advantage over the XMLs.
Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

EJB for aix,linux, unix, windows - a big yes - JBOSS.org - free for use
There are many others -  Sun have their ejb server also. (another solution is 'Jonas')

Here is schema which I know because I used to make workflow applications:

Jboss with running EJBs contains bussiness logic
Client side you can make JavaWebStart.
webstart can communicate via XML-RPC to server, you can make servlet to accept requests.
Your servlet or ejbs can communicate to c++ application via xml-rpc again(CORBA is too heavy). I know there are xml-rpc implementations for java and c++ (lucky).

JSP and HTML are limited in interactions with user(they are request based - you know based on 'turns') while javawebstart is fully functional java application running on client.

Basically your schema can look like:

Servlet(Jboss-tomcat/jetty) - XML-RPC - C++ - DB
JavaWebStart application


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I think "request based" as borislavmarkov has defined it is even more suitable for workflow applications, so this could be considered as a plus in this case, not minus.
Request based is not suitable as there is issue "A rich GUI style application ". HTML application cannot be "rich GUI style".
I don't think that "request based" is contrary to "A rich GUI style application", neither that there is a relation between them in their definitions.

borislavmarkov, you can look here, for example for opinion opposite on yurs:
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Java EE

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.