I have to agree as well.
However this is not always a problem with SM, but a nature of the beast in
general.
As ESB's deal with many other areas as well, sometimes the problems are in
those areas rather than SM itself.

I have written quite a few services for SM myself and got them all working
(even when the examples never matched the code supplied). But even I do
not understand JBI install zips myself. I find it easier to build Pojos
and put them in the servicemix.xml file as that's more like Spring
developing to me. But from reading the docs this is not what SM is about.
I should really be making proper JBI zips and using the neat hot deploy
features of SM. Then I would be using it properly, rather than just using
a feature of SM to get what I want.

I would ideally like a very, very, very simple step by step guide on how
you package up a MyPojo service into a JBI install file and why it should
go into the install dir rather than the deploy dir and so on. And I am
sure in time that will come.

For example on the 3.0 release list is the task to provide an XFire
example and the SM guys are really very fast in delivering. When 3.0 Final
finally gets released (if it has not already, I am not sure), it will be a
big thing. ESB's are here to stay and imho will be the defacto way of
supplying a SOA. Services have to run on/inside something and I think it
will be these Buses that do it.

So, I would suggest that you stick with it, but yes it is a lot of pain at
the moment.


Regards Rick






pradeep <[EMAIL PROTECTED]>
14/09/2006 16:19
Please respond to servicemix-users


        To:     [email protected]
        cc:
        Subject:        Re: Hello World



Steven,

I am having been experimenting with ServiceMix for about 2 weeks  and I
agree with points raised by you. Most of documentation work is IN PROGRESS
because of which newbies like me find it difficult to understand things
quickly. Posting queries in the forum helps but not all questions get
answered making things difficult. Like Terry said the best way to
understand
ServiceMix is going through the code but is tough if we have less time.

Pradeep


Steven wrote:
>
>
> Although I agree in general, the problem is I simply don't have time to
> read someone else's code to learn how to use their product.  I work in
an
> office where SOA is being considered and I'm just trying to put together
a
> small example of how ServiceMix could be used.  From my newbie
> perspective, if you haven't been in the SOA/messaging game for a while,
> all of the info out there is written from a point of view of the reader
> knowing what's going on - which I don't.  ;-)
>
> Luckily, the ServiceMix examples all work as expected once you get past
a
> couple of hurdles (proxy servers, ant and proxy servers, etc. etc.). The
> best example I've found thus far is the rss-binding example.  It's close
> to what I want to do.  This brings up another thing I've notice, there
> doesn't seem to be an info on how to use ServiceMix as a solution to a
> problem. For instance, as a newbie to ServiceMix I don't yet understand
> what I need to configure or build myself to get a stock quote from a
> service (via http) every five minutes, then cache those results, then
> allow clients to request the lastest results from the cache.  I know I
> could use the quartz and http components, but what else?  How do I cache
> the results.  What do I need to provide in terms of custom components,
> etc.  Unless you've been involved with ServiceMix for a while, this kind
> of solutions based info just isn't found - or at least, I can't find it.

> Seems like a good oportunity for someone to write a book: "Real World
> ServiceMix Solutions"  Any takers?
>
>
>
>
> Terry wrote:
>>
>>> No one seems willing to share
>>> "how" they learned what they learned.
>>
>> Well, one of the neat things about ServiceMix is that big chunks of it
>> are written using ServiceMix, so by looking at the source you get lots
>> of examples of how to deal with all the basic patterns. Also, by
>> following the example of the ServiceMix unit tests, you can build your
>> own unit test suite to determine the behaviour of the container in
>> situations that you can't find direct examples for.
>>
>> Terry
>>
>>
>
>

--
View this message in context: 
http://www.nabble.com/Hello-World-tf2087343.html#a6308135
Sent from the ServiceMix - User forum at Nabble.com.





Direct Line Group Limited, registered in England
with number 2811437, registered office 3 Edridge
Road, Croydon, Surrey  CR9 1AG.  The following
companies are members of the Direct Line Group:
Direct Line Insurance plc, Direct Line Life
Insurance Company Limited, Direct Line Unit
Trusts Limited and Direct Line Financial Services
Limited, all of which are authorised and regulated
by the Financial Services Authority.  All are
members of The Royal Bank of Scotland Group.

This email is intended for the addressee only and
may contain confidential, proprietary or legally
privileged information.  If you are not the
intended recipient of this email you should
notify us immediately and delete it.  You should
not copy, print, distribute, disclose or use any
part of it.  We reserve the right to monitor and
record all electronic communications through our
networks.  We cannot accept any liability for
viruses transmitted via this e-mail once it has
left our networks.

Reply via email to