There used to be a lot of talk, here and elsewhere, regarding CORBA.
In the past few years, however, I haven't seen as much about it.
Perhaps it is merely that everyone's become such experts at it that it
isn't a discussion-worthy topic. Or perhaps there are other factors
that have driven development towards other solutions.
Hopefully one of our local experts (Cameron, if you are following the
group this week, you know you are one of them) can say something more
substantial on the topic.
The worst thing about CORBA is that it's not Web Services
(except when it suits new-wave marketeers to say it is).
Read <URL: http://wiki.tcl.tk/corba >. CORBA *is* inter-
esting. I don't know what the project requirements or
interests of the original poster are, but I'm prepared to
believe CORBA is a good fit.
I find this definition very interesting and looking into http://wiki.tcl.tk/corba
made it even more interesting. But I'm afraid that CORBA might just be
fad and that it will all of a sudden go away. I this still being used?
What's wrong about CORBA being not Web Services?
CORBA is several years old and was a big buzz word at one time. Some
companies/industries bought into it and use it a lot -- others never went
there and most likely will not go there. CORBA can be and is blocked at
some company/agency firewalls -- sometimes for very good reasons.
Web Services is the latest buzz word. It, unlike CORBA, will walk through
firewalls since it is making calls over http -- be that good or bad.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
I am also trying to develop an inventory and manufacturing system
using Tcl/Tk. Would it be an advantage to use CORBA?
I found this article "The Rise and Fall of CORBA"
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=396
Saying CORBA will not automatically open doors and may close a few on you.
That being said, I'd need to see a lot more of you Use Cases and other parts
of your requirements and or designs to say where and how much it might help you.
Such a discussion is not, IMHO, suitable to the newsgroup. We may want to
take this off line -- and include Cameron Laird also.
Thanks. But for now I think I'll differ the use of CORBA. Learning Tcl/
Tk and CORBA is too much for me to handle right now. Even though I'm
very interested w/ it, I'm still having second thoughts.
I suspect we need to start over. What would CORBA have accomplished
for your project? Are you aware that Tcl supports *many* other forms
of IPC <URL: http://wiki.tcl.tk/1228 >, some of them much easier to
learn than CORBA?
Ok. As I mentioned I am trying to develop an Inventory and Production
System. Just to get it up and running I'll be using Windows XP,
Windows 2003 server and Sybase. But as soon as I get linux working all
windows os will be replaced by it. At the start it will be used by at
least 6 users and will expanpand gradually.
So how can I benefeat from "Inter-Process Communication" or CORBA
being implemented in Tcl/Tk? I'm a newbie and so you have to explain
it to me in lay man's terms. Thanks.
> So how can I benefeat from "Inter-Process Communication" or CORBA
> being implemented in Tcl/Tk? I'm a newbie and so you have to explain
> it to me in lay man's terms. Thanks.
If you're developing an architecture with several components
distributed over several machines and OSes, and you don't know what
"Inter-Process Communication" means, I'm afraid you'll need slightly
more help than we can afford to give in reasonable time and newsgroup
space.
However, if you mean the projection on Tcl of the concept of IPC, it's
not desperate.
Cameron has given you a link to a rich page listing many many
techniques. But if you're a newbie, maybe can start with two simple
things: (anonymous) pipes and (inet) sockets. Both are deadly simple
to establish in Tcl. I've built dozens of things out of many small
components with them, and put them into production in fairly demanding
environments, without ever needing any of the other IPC mechanisms.
Now your turn: can you solve your problem using sockets ?
-Alex
I think I'm repeating myself: I can hardly do better than to reinforce
the words of my friend Alexandre. I'm frankly skeptical of the original
poster's prospects for success. An integrated manufacturing and
inventory system ... well, I can attest that even people with experience
find these challenging.
Tcl is a GREAT vehicle for this kind of "real-world" project, though,
and several of us who try to contribute to comp.lang.tcl have a back-
ground in shop-floor issues and projects.
It's nice that tcltkdev seems to realize that data management plays
a crucial role. I'm no fan of Microsoft's SQL Server ...
Why are we talking so much about IPC? What infrastructure is already
in place? Is the communication supposed to be with RFID readers,
live machine tools, existing HMIs, ...?
My blunt recommendation is that tcltkdev immediately go to his
employers/backers/financiers and tell them that the full system they
have in mind will cost more than they currently estimate/realize/in-
tend.
As someone who has spent the better part of 30 years programming in this
space, here is the best advice I can give you:
Hire several consultants who know both distributed programming. The
majority should be well versed in "Production Systems", but at least one
should be from more of an accounting background and familiar with "Inventory
Control Systems". They should all have a couple of years of experience and
make sure a good bit of it is outside of the Microsoft OS. Lastly, you
generally want to look for people with a CSCI (while there are notable
excepts, particularly in this group).
The problem domain you are attempting to work in is not for "lay man" it is
an exacting and unforgiving domain (i.e. mistakes can be **very** costly or
even deadly depending on your what you are producing and what is being used
to produce it).
Nothing is in place right now. I have to start from scratch. My client
is upgrading from MS-DOS/Novell network. What I really wanted was to
put in new blood into the upgraded system. I thought CORBA or
something like it would not be too complicated to implement but I
think I was wrong. I'm now starting with MS Windows and would move to
Linux as soon as I can get it to work seemlessly with my program
written in Tcl/Tk.
I have other projects written in PowerBuilder. Since I wanted my
programs to run on Linux I decided to use Tcl/Tk instead.
If It would be too complicated to implement what I found interesting
then I won't be forcing the issue.
>
> Nothing is in place right now. I have to start from scratch.
>
> I have other projects written in PowerBuilder. Since I wanted my
> programs to run on Linux I decided to use Tcl/Tk instead.
>
> If It would be too complicated to implement what I found interesting
> then I won't be forcing the issue.
I am not certain that you are understanding what people are saying
yet. The kind of software that you describe is quite complex, no
matter what language is used for development.
It is a non-trivial effort, requiring, in all likelihood, hundreds, if
not thousands, of hours of work to do right.
I think that your initial remarks, asking for "lay man's terms", left
the impression that you were a hobbiest.
Imagine, as an illustration of the opportunity you face, if you were a
big fan of the television show "E.R." or "House" or one of the other
medical shows, and knew all about all the episodes. Now imagine you
have someone come to you and say "Hey, I've a brain tumor - you know a
lot about medical terms and stuff - would you perform brain surgery on
me...."
Perhaps you are not merely at "fan" level - maybe you are "first year
med student". Still a daunting task.
What I meant with "lay man's terms" is that I'm still new to how thing
are described in Tcl/Tk. I do understand the complexity of my project.
Unless you already anticipate needing to interoperate with other
systems
which are also CORBA-enabled, I don't think I would recommend starting
a
CORBA project in 2007. However, since it is relevant to the
discussion,
you may want to read this case study describing a once successful
approach
to such a problem:
http://www.usenix.org/publications/library/proceedings/tcl2k/brazile.html
Jason
So -- are you a "first year med student" ? A freshly graduated
physician ? A seasoned brain surgeon who is just unacquainted with
those new laser lancets ?
*If* you are the surgeon, I think a cursory look at the laser lancet
(socket.n, open.n, fileevent.n, and vwait.n manpages) should put you
back on tracks.
Otherwise, you'd better drop it fast and hire a surgeon; this is a
clear consensus from this thread...
-Alex
Posters were not using terms specific to Tcl/Tk but rather standard industry
and Computer Science terms. BTW, Larry's estimate if off by an order of
ingratitude or two -- it should be tens of thousands to hundreds of
thousands of hours (yes the project we are hearing you describe is a multi
man year project -- but then maybe you are using big terms for a much
smaller scoped project so we could be all off on the wrong track).
That was enligntening. I agree w/ you. I don't think CORBA is what I
want. My system won't be interoperating w/ other systems.
Is there an advantage of putting all my procs on a server and my
distributed client would just request for execution of such procs?
Would this be more complicated to program? Assuming that this is done
in Tcl, can it execute more than one proc at a time (interrupt)?
You are asking good questions, which shows you are motivated and
capable of thinking through things. But I have to agree with the
other advice given here that if the success of the project is
important businesswise and if you can afford it, it would be best
to hire an experienced consultant (preferablly someone who has
already done something similar to what you want) to at least help
you work out your requirements and possible plans for realization.
If this is primarily a learning project, primarily in Tcl, and
primarily not affecting anyone else, then there are potentially a
lot of rewarding things in store for you over the next couple of
years as you start exploring things like Tcl and Tk's event
oriented programming. A good place to start is to search for
all of Richard Suchenwirth's small but useful examples of many
different programming paradigms (e.g. start here http://wiki.tcl.tk/rs)
Personally, I have borrowed much from these gems over the years,
the most recent being http://wiki.tcl.tk/1664
Have fun and good luck,
Jason
> You are asking good questions, which shows you are motivated and
> capable of thinking through things. But I have to agree with the
> other advice given here that if the success of the project is
> important businesswise and if you can afford it, it would be best
> to hire an experienced consultant (preferablly someone who has
> already done something similar to what you want) to at least help
> you work out your requirements and possible plans for realization.
>
> If this is primarily a learning project, primarily in Tcl, and
> primarily not affecting anyone else, then there are potentially a
> lot of rewarding things in store for you over the next couple of
> years as you start exploring things like Tcl and Tk's event
> oriented programming. A good place to start is to search for
> all of Richard Suchenwirth's small but useful examples of many
> different programming paradigms (e.g. start herehttp://wiki.tcl.tk/rs)
>
> Personally, I have borrowed much from these gems over the years,
> the most recent beinghttp://wiki.tcl.tk/1664
>
> Have fun and good luck,
> Jason
This a learning project, primarily in Tcl, and unfortunately will be
affecting my client's business if it fails. Hence the success of the
project is very important businesswise and I am also legally
accountable. I can't afford to hire a consultant. I am my client's
consultant. I don't have two years. I only have five months that's why
I've started exploring now. I have been in a similar situation before
and I was able to deliver inspite of the difficulties.
I could do this in PowerBuilder in less than half the time but I
prefer doing it in Tcl/Tk inspite of the risk for reasons I mentioned
earlier.
> I could do this in PowerBuilder in less than half the time but I
> prefer doing it in Tcl/Tk inspite of the risk for reasons I mentioned
> earlier.
Then you must know what a socket or other IPC means.
You never answered this question, please do: do you know what a socket
is ???
Or maybe powerbuilder is a secret implementation of TIP 131 ?
http://www.tcl.tk/cgi-bin/tct/tip/131.html
-Alex
"A socket is one end-point of a two-way communication link between two
programs running on the network. Sockets are used to represent the
connection between a client program and a server program."
"A capability supported by some operating systems that allows one
process to communicate with another process."
I am familiar with sockets and IPCs but no programming experience with
it. The nearest probably would be stored procedures and triggers in
database servers.
What I meant with this is the regular programming part excluding
sockets, ipcs, corba, etc. I'm trying to learn Tcl/Tk from scratch.
My advice then would be to do it in PowerBuilder in half the time and
spend the other half of the time beginning to get into the following
issues (for starters - sorry as good a list as I can do in 10
minutes):
The event-driven paradigm
http://www.cs.vu.nl/~gpierre/courses/np/ousterhout.pdf
Basic concepts behind network programming and IPC
http://www.kohala.com/start/unpv22e/unpv22e.html
The Tcl paradigm for network programming
http://www.tcl.tk/about/netserver.html
The Tk paradigm for GUIs
http://www.amazon.com/gp/product/0201634740/002-3432420-9648053
http://wiki.tcl.tk/Actions
The Tcl paradigm for database management
http://www.tcl.tk/community/tcl2004/Papers/D.RichardHipp/drh.html
The Tcl paradigm for testing
http://wiki.tcl.tk/1502
Different Tcl paradigms for data structures
http://wiki.tcl.tk/2995
http://wiki.tcl.tk/3379
Code is data and vice versa (not exactly what I am looking for but..)
http://wiki.tcl.tk/9178
http://wiki.tcl.tk/3010
Different Tcl paradigms for packaging
http://www.equi4.com/
I've used Combat for about 6 years now and have been very happy with it.
I think it is easier and flexible to use than most of the other more
popular "solutions" out there.
I have a paper that goes into all the details of the project that
we used it for here if you're interested:
http://www.futuretek.com/presents/mdopt/aiaa-2005-7143.pdf
(We used many of the MICO services as well like: naming, event and
interface repository.)
The disadvantage of CORBA is that it gets a lot of bad press, mostly by
people who have never used it! :-)
(Tcl also gets a lot of press mostly by people who've never used it
too...maybe they are good match for each other since they can commiserate.)
Here are a couple of issues that you might want to think about though:
1.) Penetrating the firewall and Natting issues. It can be done with
CORBA, especially if the ORB supports bidirectional GIOP.
(Unfortunately, MICO nor Combat supports that yet. TAO and JACORB does.
BTW, TAO has a protocol called HTIOP that tunnels IIOP over HTTP. It is
supposed to work pretty well although I haven't tried it myself. There
are TAO bindings for Combat, but I've never exercised them.)
2.) Versionitus issues. This plagues any messaging solution, even XML.
Essentially the client and server code need to be in synch as the
interface definitions and data definitions change. With Combat, it can
hit the interface repository on both the client and server side so as
long you keep the interface repostory current and you don't mind
restarting the servers you're good to go. (There are other approaches
I've been thinking about as well to reduce versionitus that I can go
into details about if anybody is interested.) Also, Combat maps structs
and value types to name value lists so that actually reduces the
versioning problem a bit since you only grab what you need out of the
list (or array when you map the name value pairs into the array.)
Anyway, I'd be happy to answer other questions if you decide you want to
pursue the CORBA approach for your project.
Good Luck!
Rob
I'm a newbie on Tcl/Tk working on a real world project using it. I
just wanted to add something interesting on top of learning Tcl/Tk.
The application I'm working on needs to run on both windows and linux.
So Powerbuilder is out of the question. This is a risky attempt on my
part engaging on this project using Tcl/Tk since I'm a newbie but I'm
willing to risk it and I'm very positive that I can do it.
I am an experienced programmer. But nothing technical just plain old
database programming like creating billing system, hr, a/p, a/r and
etc.
Now I get it: you're running for QOTW, aren't you ?
-Alex
Alex,
He is using the word in the older (pre mid 90s) sense:
Technical vs Business vs Scientific programming
The only problem is the world has moved on an Business programmers now do a
lot of the things (like distributed programming) that only Technical
programmers used to do.
Back in the bad old days, you had people who programmed on (to use today's
lingo) back office machines -- these machines ran batch, or later were ran
DBs that several people (accountants and manages were connected to, but
sometimes only one was allowed in at a time).
What is QOTW?
Quote Of The Week -- a nice tradition of this community, look for the
nearly-weekly Tcl-Url post.
-Alex
Much Scientific programming is now rather like Business and Technical
programming too, especially towards the higher-end. For example,
bioinformatics is mostly about database searching (an area that has been
more the realm of business computing), and a lot of HPC now uses
massively distributed systems (an area that is very interesting to
technical programmers). Mind you, I wouldn't say that the areas are
converged; rather they're talking to each other more than they used to.
Donal.