On 28/09/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
>
> 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?
The later. Aysnc is a hard problem full stop, and while things like
blocking queues and exchanges make it simpler, its still not something
I'd trust many people to do.
>
> > 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.
I was thinking about using a space for what I'm coding, but I thought
I'd try it out just using the bits in the standard Java language. The
biggest challenge I'm facing is eventing, which a space would have
made easier.
>
> 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.
And I still can't get over the lack of elegance of public variables.
>
> 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.
I think its more than that, I was at an event last night where they
had a chap talking about grid computing. He made a point I really
agree with, some people just _can't_ get parallel computing, you can
explain it all you like but they just won't "get" it. It takes
certain types of minds to cope with the idea that many things can
happen at the same time.
>
> 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...
Ahhh the good old MMM. Aren't you glad to live in a fast paced
industry where we repeatedly make the same mistakes? ... no? Me
neither.
>
> Of course software is not the only place the pipedreams of more people ==
> more
> productivity exist.
But it is one of the worst.
>
> 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/
