Steve Jones wrote:
> 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.
>
Yes.
>> 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.
>
Well, it's not perfect of course but the thinking (so I'm told) was that
you'd be typically in one of two camps:
(1) Passing mostly code
(2) Passing mostly data
In case (2) you tend to want to use a DTO style of object with nothing
more than getters and setters. And thus the reasoning was that if
you're doing this you might just as well reference the fields directly.
Of course, that's not to everyone's taste.
There is a case (3), which is a fully fledged object but actually that
doesn't seem to show up much in reality (from what I've seen so far).
If I really need good separation, I have a layer that knows about the
concrete Entry implementations (with a factory for creation, etc) and
then have my Entry implementations also implement an interface which is
used by all other layers to access/manipulate the Entry.
>> 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.
>
+1 (you knew that right? ;)
>> Of course software is not the only place the pipedreams of more people ==
>> more
>> productivity exist.
>
> But it is one of the worst.
>
+1
Dan.
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/
