Steve Jones wrote:
> OOoh quite a bit, I'm writing something at the moment actually using the
> wonderful concurrent package that.
Okay, so is Java poor at Async, or is Async hard to do with the tools you have
to use in Java?
> My point is that something like BPEL which has built into its "language"
> the concept of a request response and can handle behind the scenes the
> "block", "poll" or "event" question is simpler for most people than
> trying to understand how threads really work.
I use tools like Javaspaces for async in java because it puts the async
contention and threading issues in the service and its associated API. This
greatly simplifies async operations. It doesn't remove the need for developers
to learn something to solve the problem. But, it greatly reduces the
opportunity for hidden bugs that incorrectly written concurrent software can
introduce.
Javaspaces programming allows software to focus specifically on the data
processing. It also allows programming in the small as the predominent mode. As
with any transactional services, it is still possible to create circular wait.
An important concept in any SOA though is to design a domain specific API
system
that conveys the language of the problem solving steps so that you can have a
highlevel orchestration "language" that is understandable and which provides
the
ability to plug in varied solutions for each needed operation without having to
switch technologies such as BPEL or something else wholesale. Some of these
technologies don't allow too much plugability, especially of transport for
messaging, so you have to make a decision what's best for your needs.
> Async is hard, and like threading there are less than 5% of people who
> can actually do it well (and I'm being generous with 5%), so if you are
> doing async stuff its a good idea to pick an environment that makes it
> simpler to do async by hiding lots of the challenging bits from you.
>
> If I had 20 Doug Leas on my teams I'd always use Java for async,
> unfortunately I don't.
Yes, this is the issue. It is hard to manage concurrency if you don't have
formal training and understand the theory and practices needed. This is no
different than any other software development concept though. The issue is
that
concurrency is much more critical to software correctness, and much harder to
hack around and arrive at a working solution. This criticality causes many to
panic and run away, instead of learning about how others have solved the
problem.
The software industry has an amazingly large number of untrained developers.
There is a general thought that more people can create more code faster. The
real issue is that fewer, trained people need to be given enough time to do the
job correctly...
Of course software is not the only place the pipedreams of more people == more
productivity exist.
Gregg Wonderly
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/service-orientated-architecture/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
