Web services - service and potential product from me - survey
Jim Idle
I am contemplating two things that I would like to sound out your interest on to see if it is worth the time.
Firstly, I have created some code that can interface jBASE subroutines directly to web services both as a service itself and as a client of some other web service such as stock quotes, financial market information, and of course anything that is a SOAP compliant web service. This does not involve tying yourself to .Net, Java, PHP or anything else at all. It is basically native C code and can even serve the web services directly without a web server, which is very much faster than IIS or Apache cgi integration (though the services can be configured to work as apache mod, Isapi and so on. The services support all the latest specs and https and so on and are interoperable with the latest tools.
So, I can do two or three things here:
1) Offer a service whereby you give me a spec of what your service should supply (either written or as a wsdl etc); basically methods it should have. I give you the source code that handles everything and just calls subroutines (which you supply), for a fixed fee. Obviously I can also do the same for clients - you give me the URL of the wsdl such as the one here: http://www.xmethods.com/ve2/ViewListing.po?key=425860 , or the actual wsdl, and I give you the source code for a native client that you can call by just calling a jBASE subroutine. In both cases you write the application parts of the subroutines of course but this is just the usual jBC/BASIC coding. This would be fixed price based stuff.
2) Develop a more automated tool with a simple language that allows you to specify the basics of the web service, how to map the XML into dynamic arrays and variables and so on and then you run it and it generates everything for you. This is of course quite a lot of work, so there is no point me doing this unless enough people were interested. My feeling is that this is actually less useful than looking at requirements and building a maintainable solution.
3) Another possibility is for me to pre-build a library of subroutines an C code that already knows how to be a client of and serve up a set of known useful services for certain industries, such as obviously, banking and just keep adding to this. So basically you kind of buy a subscription and keep getting updates as you or others ask for new services. This also seems a good idea if enough people were willing to sign up. There is no risk of giving away internal secrets of course as all the services would be secure an encrypted and used in different ways by you applications. Of course here I am mostly thinking of banking organizations as there are thousands of public and private web services in that arena.
There are lots of web services that you may no have realized are out there, for instance there is even a web service that will cal people and make pre-recorded announcements at them - sometimes even ones they might want to get such as "Your order has shipped" and sometimes ones that they don't such as "We are trying to collect $200 from you..." ;-). Financial services include interbank rates, stock quotes, forex, private data services and so on. And of course all of these can be integrated with other systems such as MQ Series or Rendezvous. Here are a few that might peak your interest if you have never looked into them before: http://www.xmethods.com/ve2/index.po
As services you will find that web services are really excellent for integration, especially with desktop apps as Visual Studio has a little wizard that points at the URL for the WSDL (Web Service Description Language) file and then builds the entire interface for your client. It is then 2 or 3 lines of code to make the call to the server and you get back (or can if you spec it that way) a complete object, rather than a Pick dynamic array.
If you think you might be interested in any of this then please send me an email off list. The lack of any replies might well tell me something ;-)
Thanks for your time,
Jim
Tom Turkington
Jim, I have to say this opens up too many questions for me to even know where to start. So far, Proco hasn’t had a need to deal with web services, but if anybody ever decides to invest a ton of money in Proco (and hire a ton of helpers), I could see uses for this, but doubt my knowledge could help you pick a direction for the product. A couple of comments though...
1. The one instance where we’ve approached needing web services was/is per needing a Web Service Client that we could access via jBasic. I figured if push came to shove we could write/use a .net web service client to retrieve data, but it would be nice to be able to just CALL WS.REQUEST.SUB(URL,CREDENTIALS,SERVICE.NAME,REQUESTDATA,RESULTS) (or something similar in my imagination...). It sounds like a jbasic WS client might be part of this product. So, maybe making the client available as a standalone product, might make sense. (Again, my ignorance is such that perhaps writing a client is so trivial, this isn’t really necessary...)
2. I’m wondering if this would effectively make the rest of idiots capable of writing a JRCS replacement in a week’s time, as you indicated a couple weeks ago, we’re supposed to be able to do. The one thing that JRCS does that I don’t have a clue how to accomplish (again per ignorance) is i.d. user’s credentials, id’s user correctly in JBase accordingly via SYSTEM/USEREXIT’s etc, and, presumably, respects windows security accordingly. I’ve never checked the latter, ... In any event, ability to ID user via PORT.LOGON = OCONV('','U50BB') is somewhat important to us, so I guess my question is does the Web Server’s SUBROUTINE Call’s set user id properly?
Jim Idle
Jim, I have to say this opens up too many questions for me to even know where to start. So far, Proco hasn’t had a need to deal with web services, but if anybody ever decides to invest a ton of money in Proco (and hire a ton of helpers), I could see uses for this, but doubt my knowledge could help you pick a direction for the product. A couple of comments though...
1. The one instance where we’ve approached needing web services was/is per needing a Web Service Client that we could access via jBasic. I figured if push came to shove we could write/use a .net web service client to retrieve data, but it would be nice to be able to just CALL WS.REQUEST.SUB(URL,CREDENTIALS,SERVICE.NAME,REQUESTDATA,RESULTS) (or something similar in my imagination...). It sounds like a jbasic WS client might be part of this product.
So, maybe making the client available as a standalone product, might make sense. (Again, my ignorance is such that perhaps writing a client is so trivial, this isn’t really necessary...)
2. I’m wondering if this would effectively make the rest of idiots capable of writing a JRCS replacement in a week’s time, as you indicated a couple weeks ago, we’re supposed to be able to do.
The one thing that JRCS does that I don’t have a clue how to accomplish (again per ignorance) is i.d. user’s credentials, id’s user correctly in JBase accordingly via SYSTEM/USEREXIT’s etc, and, presumably, respects windows security accordingly.
I’ve never checked the latter, ... In any event, ability to ID user via PORT.LOGON = OCONV('','U50BB') is somewhat important to us, so I guess my question is does the Web Server’s SUBROUTINE Call’s set user id properly?
MYSERVER(PORT.LOGON
When connecting to the app, you can give them that information to store locally on the client (and it is encrypted on https services of course.
Anyway, as the grand total of inquiries has been zero, it is rather a moot point. I will stick to waiting to announce my new jBASE related product that everyone on this list would be completely crazy not to use, whether you are a 2 user windows box or a 1000 user bank. But, that can wait a little yet until I have QA'd it.
Jim
CLIF
that I'm all for it. All of our clients have multiple jBASE
environments on the same hardware i.e. a test account and a live
account plus there maybe multiple versions of the same webservice just
with a different url. What I need is a webservice that can have
multiple instances running so they each can start up with their own
environment variables such as: HOME, PATH, and JBCOBJECTLIST. Is that
something you can do?
Gary Calvin
need multiple instances of your web server to do what you want to do.
What you're really looking for here is multiple web sites, which can
still all be served by the same web server. You can either run them on
separate TCP ports (http://host.domain.name:8081/path/,
http://host.domain.name:8082/path/, etc.), or assign different host
names to the same IP address, and use the different names to identify
the different sites (http://site1.domain.name/path/,
http://site2.domain.name/path/, etc.). You may even be able to set
different environments on different directories within the same site
-- I don't know IIS well enough to tell you how, since I use Apache
more often, but it can probably be done. Apache on Linux can be
configured to do http://host.domain.name/~username/path/ which makes
the rest of it quite simple.
Web services are about integrating code from different sources and
running on different machines into a common project. For instance,
let's say you want your company's web site to have a dealer locator
that finds a list of the geographically closest dealers to a given
address. The bulk of the app will be written in some web development
language -- ASP.NET, PHP, ColdFusion, something like that. And there
will be a back-end component written in VB.NET, C#, Java, whatever.
But you still need a way to talk to jBASE and get the dealer data. And
your VB.NET or C# or Java developer doesn't know much about jBASE. So
you have them develop the whole app with a "stub code" web service for
the function that's going to get the jBASE data. Within the app, the
web service call looks pretty much like any simple function call --
like DealerList = ws.jbFindDealers(Latitude, Longitude, DealerType) --
something like that. The developer will create a web service in the
language they like to use, and the back-end logic will be stub code --
just creating the data structure they need, and filling it in with
hard-coded sample data. They will also deliver a WSDL -- Web Service
Description Language -- file that specifies all the technical details
of how the web service will be called, the data structures it uses,
etc.
The key point here is that the non-jBASE developer doesn't need to
know anything about jBASE, and the jBASE developer doesn't need to
know anything about the app. The jBASE developer must provide a web
service that conforms to the WSDL provided by the non-jBASE developer.
Building a web service that conforms to a particular WSDL document is
not easy to do from scratch, but at least it is testable and provable.
That's already a big advantage in an integration project. For a
developer to be able to say in a bug report, "the WSDL says X but your
service is doing Y" is a huge improvement over the finger-pointing and
differences in interpretation (or often just plain lack of
documentation) that often goes on in integration projects.
What Jim was proposing was a way to convert that WSDL into a usable
web service that runs on jBASE -- dealing with all the grunt work of
converting the data structures into jBASE dynamic arrays, etc. as well
as parsing/generating the necessary XML that web services use. All
that would remain would be to write a jBASE subroutine to perform the
actual operations -- in our case, finding the nearest dealers to the
given latitude/longitude.
There's quite a bit more to it than that, and I'm sure Jim's product
would have included plenty of nifty features to make developing and
calling web services as straightforward as can be for jBASE
developers.
Actually, I think the service-based version of Jim's idea is probably
still viable. If you can advertise a flat rate for WSDL-to-stub-code
conversion (with perhaps a limit for number of methods, complexity of
data structures, etc.) you might get some takers. I would certainly
point Kenwood toward taking a good look at it (I'm not employed there
anymore, but still do some contract work for them).
-Gary-
CLIF
web server. However when IIS starts up any webservice that runs
inherits the environment variables from the system and start up user.
Any subsequent call or execute also inherits those variables. You can
issue a putenv which will change the variable however there is a big
difference between changing the variable and actually having it take
affect and its the later it won't do. The only way I've been able to
get around this is to use the shell command from the webservice and
shell to a command file which sets up a new environment. Its more
overhead but it does work.
On Jun 13, 11:53 am, "Gary Calvin" <gary.cal...@gmail.com> wrote:
> A web server is not the same thing as a web service. Still, you don't
> need multiple instances of your web server to do what you want to do.
> What you're really looking for here is multiple web sites, which can
> still all be served by the same web server. You can either run them on
> -- I don't know IIS well enough to tell you how, since I use Apache
> more often, but it can probably be done. Apache on Linux can be
Gary Calvin
-Gary-
CLIF
informative....Thanks for taking the time to explain all that.
Jim Idle
Jim I use IIS as my webservice and if what your proposing replaces that I'm all for it. All of our clients have multiple jBASE environments on the same hardware i.e. a test account and a live account plus there maybe multiple versions of the same webservice just with a different url. What I need is a webservice that can have multiple instances running so they each can start up with their own environment variables such as: HOME, PATH, and JBCOBJECTLIST. Is that something you can do?
I don't think i am willing to put in the effort to make this 100% automatic unless there are a lot more takers, but it is perfectly practical to produce services (with source code of course) that you would be able to tweak and rebuild without knowing what the C source really does.
Let me know off the list what your services or server stuff currently does. Getting IIS out of the mix is probably worth the effort alone. At this point the first few volunteers gets a "pay-if-it-works" price so long as they will talk about it afterwards :-)
Jim
Jim Idle
A web server is not the same thing as a web service.
Still, you don't need multiple instances of your web server to do what you want to do. What you're really looking for here is multiple web sites, which can still all be served by the same web server. You can either run them on separate TCP ports (http://host.domain.name:8081/path/, http://host.domain.name:8082/path/, etc.), or assign different host names to the same IP address, and use the different names to identify the different sites (http://site1.domain.name/path/,
http://site2.domain.name/path/, etc.). You may even be able to set different environments on different directories within the same site -- I don't know IIS well enough to tell you how,
But you still need a way to talk to jBASE and get the dealer data.
The key point here is that the non-jBASE developer doesn't need to know anything about jBASE,
and the jBASE developer doesn't need to know anything about the app. The jBASE developer must provide a web service that conforms to the WSDL provided by the non-jBASE developer. Building a web service that conforms to a particular WSDL document is not easy to do from scratch, but at least it is testable and provable.
What Jim was proposing was a way to convert that WSDL into a usable web service that runs on jBASE -- dealing with all the grunt work of converting the data structures into jBASE dynamic arrays, etc. as well as parsing/generating the necessary XML that web services use. All that would remain would be to write a jBASE subroutine to perform the actual operations -- in our case, finding the nearest dealers to the given latitude/longitude.
There's quite a bit more to it than that, and I'm sure Jim's product would have included plenty of nifty features to make developing and calling web services as straightforward as can be for jBASE developers.
Actually, I think the service-based version of Jim's idea is probably still viable. If you can advertise a flat rate for WSDL-to-stub-code conversion (with perhaps a limit for number of methods, complexity of data structures, etc.) you might get some takers. I would certainly point Kenwood toward taking a good look at it (I'm not employed there anymore, but still do some contract work for them).
Anyway, feel free to ask questions and thanks to you Gary for explaining web services from a jBASE application guy's point of view - a few different views and perspectives probably goes a long way to help others see what they might do with them.
Jim
Gary Calvin
(http://www.cs.fsu.edu/~engelen/soap.html)? I played around a bit with
that, and thought about trying to do a wizard-based approach with it,
but I never really got very far. My lack of C skills caught up with
me. But I did use some of the utilities for generating WSDL, etc.
-Gary-
Jim Idle
Jim, is your stuff by any chance based around gSOAP
Jim
Pawel (privately)
Hello,
Just my feedback as a T24 user.
1. We do not use WebServices via http(s). Yet?
2. Offer is partially interesting, but in general I perosnally do not like closed source - just because of maintenance and flexibility of changes reasons. Will you deliver me binaries or give some jBASIC auto-generated code? What will be binary dependency? Do I need to include your extra library? What will happen if we upgrade to newer jBASE release? Will it be compatible? Can you give more light on it? It may be one day interesting for us - I would like to know more details.
I think that we can easily develop any webservice client in Java using standard built-in Eclipse generator. So why do we need to pay for your client generation service?
Perhaps your C/C++ solution is faster (introduces less overhead), but I do not care much to be honest. Differences should not be much visible as this is all about network communication.
3. We try to avoid any 3rd party solutions wherever we can and we are trying to stick to the (T24) package.
4. There is Temenos Application Gateway (TAG), which can act as webservice(s) server. I have not seen it yet (not needed to), but it seems to fulfill our requirements if we need to expose WebServices via http. We can raise SAR to it if it is missing some functionality.
5. I prefer to use MQ communication (middleware) than WebServices over http(s).
I personally think that you should cooperate with Temenos to improve TAG*. Performance, openess and functionality is important in such products.
Kind regards Pawel
* By the way: why did you left them? :)
Wystartuj z siłą bolidu w wyścigu o kombinezon i czapkę
ROBERTA KUBICY! Rusza wielka aukcja charytatywna,
sprawdź więcej:
http://klik.wp.pl/?adr=http://corto.www.wp.pl/as/aukcje7368578.html&sid=387
Jim Idle
Hello, Just my feedback as a T24 user. 1. We do not use WebServices via http(s). Yet? 2. Offer is partially interesting, but in general I perosnally do not like closed source
- just because of maintenance and flexibility of changes reasons. Will you deliver me binaries or give some jBASIC auto-generated code? What will be binary dependency? Do I need to include your extra library? What will happen if we upgrade to newer jBASE release? Will it be compatible? Can you give more light on it? It may be one day interesting for us - I would like to know more details. I think that we can easily develop any webservice client in Java using standard built-in Eclipse generator.
So why do we need to pay for your client generation service?
Perhaps your C/C++ solution is faster (introduces less overhead), but I do not care much to be honest.
Differences should not be much visible as this is all about network communication.
3. We try to avoid any 3rd party solutions wherever we can and we are trying to stick to the (T24) package.
1) I wrote a rather large part of what you are suing, including the compilers;
2) I even fixed up CALLJ after someone put it in there;
3) You have all the source, you would just be paying for me to produce it efficiently;
4) Java, Eclipse and the complicated client generators are all written by you then eh? ;-)
4. There is Temenos Application Gateway (TAG), which can act as webservice(s) server. I have not seen it yet (not needed to), but it seems to fulfill our requirements if we need to expose WebServices via http. We can raise SAR to it if it is missing some functionality.
5. I prefer to use MQ communication (middleware) than WebServices over http(s).
I personally think that you should cooperate with Temenos to improve TAG*. Performance, openess and functionality is important in such products.
CLIF
Pawel (privately)
Hello,
Dnia 17-06-2008 o godz. 2:03 Jim Idle napisał(a):
On Tue, 2008-06-17 at 00:51 +0200, Pawel (privately) wrote:Hello, Just my feedback as a T24 user. 1. We do not use WebServices via http(s). Yet? 2. Offer is partially interesting, but in general I perosnally do not like closed source
Err, taht's wahy you get teh source code to everything ;-) You write the jBC subroutine, but I give you the stub to start from.
So I will receive full source code from you, right? I may (re)compile it on my server whenever I want, in a way I want (debug symbols, etc.). May I change it to add for example caching of method invocations? If full source code is given and there are no binary dependences it is more "safer" for me (see more explanatation about 3rd party below).
- just because of maintenance and flexibility of changes reasons. Will you deliver me binaries or give some jBASIC auto-generated code? What will be binary dependency? Do I need to include your extra library? What will happen if we upgrade to newer jBASE release? Will it be compatible? Can you give more light on it? It may be one day interesting for us - I would like to know more details. I think that we can easily develop any webservice client in Java using standard built-in Eclipse generator.
Yep - that's great, now you have to start a JVM from each JBC program just to consume a bit of XML and CALLJ allows you to return a one whole string only. If that works for you then fine, but this is about doing things with 100K of memory, rather than 100MB (if you are lucky). The same applies for web services of course.
Agree, but you may accumulate CALLJ processes in one, single place and use worker threads pattern to limit number of such processes. This is not perfect as you said, but always better that running CALLJ in each process.
So why do we need to pay for your client generation service?
Because i know what I am doing with all the components, and it is less expensive than you taking 3 weeks to get the Java version to work and report errors, recover from errors and so on;-)
Honestly speaking it took 1-2 mandays for doing this development using Eclipse generator with full integratation with jBASIC.
Perhaps your C/C++ solution is faster (introduces less overhead), but I do not care much to be honest.Yes - well unfortunately, it is this kind of attitude that brings systesm to their knees. You don;t care that every jBC program that needs to use the web service now needs a JVM and that will increase the virtual size of your 600 user system by huge amounts, not mention startup overhead (which is significant)? However, the C solutions is not just a bit faster, it walks all over Java, but if Java is your hammer etc.
I exaggerated a little bit. We normally care about resources and performance, but sometimes it is not worth investing in speeding up process that is rarely executed. Currently I do not see any need to use webservices too often, in almost each process. I agree that resources utilization may be a problem when many processes invoked CALLJ (many JVM instances launched).
Differences should not be much visible as this is all about network communication.No, it is not about that at all, it is about start up latency, response times, memory footprint, reuse of socket resources, all sorts of things that a Java programmer generally doesn't know anything about so assumes that it is OK to ignore :-)
Java programmers also care about such things. JVM can be loaded at process startup or at first CALLJ call I think (am I right?). CALLJ gives some overhead, but I do not think that invocation of WebService in Java will take significantly more time than invocation written in C/C++.
3. We try to avoid any 3rd party solutions wherever we can and we are trying to stick to the (T24) package.
Well:
1) I wrote a rather large part of what you are suing, including the compilers;
2) I even fixed up CALLJ after someone put it in there;
3) You have all the source, you would just be paying for me to produce it efficiently;
4) Java, Eclipse and the complicated client generators are all written by you then eh? ;-)
I am neither saying that you did not write good stuff nor saying that availability of source code is the only way to have reliable solutions. I truly belive in your broad experience and parsers/lexers/compilers/generators/design patterns knowledge. I got knowledge many times by reading your emails.
I wanted to say In point 3 that 3rd party solutions can cause following risks:
a) upgradeability and compatibility (what if I am upgrading my AIX server, what if I am upgrading some T24 components, what if I upgraded my T24 major version, what if jBASE or went 64 bit etc.)
b) lack of support on guaranteed level (aka bug-fixes, defect resolution)
c) maintenance and enhancements
I am very happy to hear that you fixed CALLJ. Can you improve it for us a bit more? :) Why this was ever created is this was/is so crappy? ;)
I am conviced, that banks usually require following things from solutions:
* documentation
* full support from vendor + presence of helpdesk (SLAs) - assurance that bugs will be fixed and raised change requests developed
* continuity of solution (in future)
* references from other customers
.
I can not say to any manager: there is Jim somewhere in the world, good and experienced specialist. He developed nice solution sitting two nights in a row, drinking 2 red bulls. Therefore it is bugfree ;), will not cause any problems and is cheap ;)
Manager would probably simply ask why such excellent solution is so cheap if it is so good. ;)
I am just trying to show that it is hard to convince people to use 3rd party solutions from "unknown" vendor. Sometimes some policies in bank say: open source solutions are not supported and therefore disallowed. Software from non trusted companies is disallowed. Software missing SLAs is prohibited.
4. There is Temenos Application Gateway (TAG), which can act as webservice(s) server. I have not seen it yet (not needed to), but it seems to fulfill our requirements if we need to expose WebServices via http. We can raise SAR to it if it is missing some functionality.Oh yeah :_
I would like to hear more :)
I personally think that you should cooperate with Temenos to improve TAG*. Performance, openess and functionality is important in such products.Er. Why? ;-)
To make happier such annoying bastards like me ;)
Customers (banks) need reasonable, scalable, performant, open and supported solutions out of the box from Temenos. They want to avoid creation of extensions to core package / core solutions whenever possible. They want to keep upgradeability and have support. So local development is against their main goal.
Temenos may provide support, references and brand to the solutions.
You may provide them good skills and increase overall quality of their product(s).
All Temenos customers will be happy if you join your forces. Do not you think? :)
It is better for bank to buy something from them that was developed by you, than to buy something from you directly.
Finally:
1) can you send me more details about your solution (some docs preferably)
2) did you develop jBASIC IDE? (I think that you did survey here in the past)
Cheers
Pawel
----------------------------------------------------
Wakacje 2008. Planujesz wakacyjny wypoczynek?
Chcesz wyjechać w lipcu lub sierpniu?
Sprawdź nasze oferty:
http://klik.wp.pl/?adr=http://corto.www.wp.pl/as/wakacje2008.html&sid=388
Jim Idle
To make happier such annoying bastards like me ;)
Customers (banks) need reasonable, scalable, performant, open and supported solutions out of the box from Temenos.
They want to avoid creation of extensions to core package / core solutions whenever possible. They want to keep upgradeability and have support. So local development is against their main goal.
Temenos may provide support, references and brand to the solutions.
You may provide them good skills and increase overall quality of their product(s).
All Temenos customers will be happy if you join your forces. Do not you think? :)
It is better for bank to buy something from them that was developed by you, than to buy something from you directly.
Finally:
1) can you send me more details about your solution (some docs preferably)
2) did you develop jBASIC IDE? (I think that you did survey here in the past)
Jim