Call-In U via???

Author: (Thomas.Young)

Hi, maybe to start another discussion, I am interested in your point of view. In our projects we discuss the opportunities to integrate UNIFACE and Java. We have several application for different customers developing since UNIFACE 6 and now in UNIFACE 8. On the other side we have newer projects in JAVA which need to interact with UNIFACE (just Call In). We want to read and write Data in UNIFACE and to have the business logic in UNIFACE. It should be a small kind of SOA. So we discuss about ->WS ->CORBA ->JNI Call In ->RMI Call In WS: So the easiest way and state of art is to use WebServices via the WS-Interface of the application server. But this mean to buy an WASV for every customer. The benefit is support through CPWR but the disadvantage are the cost and your are not able to influence the wasv. CORBA: It won't be supported from U9, so no future. JAVA/C Call-In: The problem about JNI is, that one application can have only one access to UNIFACE, because it is all in one process. We haven't found a solution to create several UNIFACE instance from java to handle themselves in several threads. So you have to start for each Call-In a separate process. Then you have to notice the 10k limit on parameters. But on the other side, if we build an own Call-In Handler, we don't need the WASV. Cost are only once and the Handler can be adapted to our purpose. So my questions are, if there are other opinions, points I missed or solutions? Best regards THOMAS YOUNG


  1. Interesting question Thomas but I'm not sure about the original observation on costs. I recently found this link that compares cost of ownership for a jboss and a "proprietary" application server. Check it out for yourself. Enter a four cpu machine and Uniface webserver and jboss look comperable....ish. take it up to 5+ cpu's and hoo wee, we are practically giving Uniface web app server away. Considering how easy it is to create Uniface web services in 9 and based on cost estimates from non-other than jboss themselves Uniface has to be your most cost effective way of doing this. I can see why you want Uniface at the back end and not JAVA J2EE, now that would be expensive! BTW what do you mean by "you are not able to infuence the wasv"?

    Author: George Mockford (
  2. Thanks for your opinion. It is an nice link. But what is if you have e.g. five customer with a small amount of interaction. So each customer have a similar application and you need a standard interface, which are not necessary web-services. It would be nice to have a technique which is similar. The WASV than is a little bit oversize and you can not handle kind of statefull session if it is needed. So that is why we are looking at the JNI to interact with UNIFACE. Then you can build your UNIFACE services with XML parameters and call them through the interface. Regards THOMAS

    Author: Thomas.Young (
  3. Does this have to be JAVA Thomas? because you might want to look at Microsoft web services. I've built an example using COM interop to call Uniface services at the back end and passing an xmlstream parameter as a string. In C# I simply serialized/deserialised the Uniface xmlstream to a datagrid so this would need to be changed into a webservice instead. In 8 there is a limitation, if I remember correctly, of about 500K for string parameters with COM. In 9 I can confirm that this has changed and from testing is more like 10MB. So in effect you would have a .NET webservice (c#) ->COM->Uniface service. You might want to explore the parameter size for Uniface / JNI in 9 as that might have changed also.

    Author: George Mockford (
  4. Hi GMockford, I became very happy to read what you have written. The solution that you create is exactly what I'm trying to do these last days. But, I'm facing a error message when I try to create COM's components form my Uniface's services. Here I'm using Uniface 7.2. I've followed the steps describe in "URB Interfaces Manual" and after type the command idf /STO /MWR=COM /CFG=usys.ini AD_CALCCONT SRV_AD_CALCCONT a error message appears telling me that the DLL sclw3230 is missing and I have to reinstall it to fix this problem. Do you have any idea about this DLL? If you have any better reference describing how to do this, I would be very pleased to read. Best regards, Sebasti?o Mendes

    Author: sebastiaomendes (
  5. Hi Sebastiao, not sure about the sclw3230.dll as I can't find it in any Uniface install. However I did notice that your command line /STO /MWR=COM /CFG=usys.ini AD_CALCCONT SRV_AD_CALCCONT appears to have a config file of usys.ini. I believe that this setting should be the name of the configuration definition created by the Uniface COM configuration utility. I can appreciate that you are working with 7 but I tried this with 8 and 9 and it appears to be working. So try creating one of these and see if that solves this issue. Regards George

    Author: George Mockford (
  6. Hi Sebasti?o, The DLL sclw3230 is part of the SOLID Embedded Engine 3.0 Client, which the Uniface SOLID Connector (sol3031c.dll) requires to work properly. Normally the SOLID Client DLL's are installed in the Windows System32 directory. But since Uniface cannot find the DLL this probably means that you do not have the SOLID Embedded Engine 3.0 installed on your system. I however assume that are using another database then SOLID for you repository. I also assume that there is no COM configuration called usys.ini, which means that Uniface is most likely not using the "correct" ASN file (with the correct repository DB path). By default all database paths are mapped to Solid. Bottom line is that this problem disappears when you specify the "correct" COM configuration (which includes a reference to the correct ASN file, etc.). Hope this helps. Best regards, Daniel

    Author: diseli (
  7. Hello everybody, Just a remark about Uniface WebServices and WASV. As far as I know, you do not need to buy WASV, you will need the Uniface Virtual Machine. Just create your signature using /STO /MWR=WS ... and publish it at Tomcat or WebContainer that can handle Uniface servlet. Marcelo

    Author: MartinsM (