Adam, The HR situation you describe is (onboarding/offboarding) is a classic case for BPM. What I'm seeing these days is many vendors providing BPM as yet another component of SOA, often riding on top of the ESB for mediation, communication, etc. As you point out, it's entirely possible to implement a broker based solution like you are doing using message queues, but BPM with an ESB offers a compelling case for these types of process based integration scenarios.
With SOA in general, I prefer to take an approach where I view implementations through a maturity model. There are a number of different ones floating around, but they all have some similarly: most companies start by building a few simple services, that they integrate point to point. As they mature with services, things like UDDI, Governance, architected services, mediation, managed services, etc. start to enter the picture. In my experience, SOA is rarely trivial to implement. What you end up with in the end, if you've done things "right" isn't necessarily a system that's less complex than what you started with, but rather an architecture that is much more flexible, scalable and capable than where you started. I'm a firm believer that SOA is something you build - I just don't see how it's something you can buy (although you can certainly buy service enabled software). -Rob On Feb 26, 6:52 am, "Adam Haskell" <[EMAIL PROTECTED]> wrote: > > I doubt you'd find a core SOA in CF simply b/c in the end you would > > > > > probably end up leveraging many things in Java > >>If you insist on message queues, maybe. But to me 'SOA' can equally mean > WSDL > >>or REST end points, performing fairly simple jobs on a database. > > Like I originally said I question the scalability of this type of solution. > Its a fact of life SOAs are not as performant, you just can't have that type > of architecture without overhead, but REST and webservices at the core of an > SOA are going to perform even worse. That being said, you hit the nail on > the head, at the end of the day SOA is what you make of it. If exposing > database interactions through webservices suffices for a company's overall > needs then its a fine solution, I would not call that SOA in my company but > others very well would. In our enterprise this type of interaction is not > nearly enough, we need a much more robust solution. In our company, as an > example, when an employee is created in HR at least 5 different systems need > to react to this addition. In order for systems to work in this scenario we > have to have a canonical form of an employee and then each system subscribes > to a queue and translates that employee to its needs and does what it needs > to do. > > > fact that your SOA solution would have a fixed starting cost of maybe 10k > >>There are free-er CFML runtimes. > > True, and BD has a great OEM licensing, but when one starts talking about > using event gateways and other features specific to one CFML engine one > starts limiting the engine one can use. > > Adam Haskell > > On Tue, Feb 26, 2008 at 4:44 AM, Tom Chiverton <[EMAIL PROTECTED]> > wrote: > > > > > On Monday 25 Feb 2008, Adam Haskell wrote: > > > I doubt you'd find a core SOA in CF simply b/c in the end you would > > > probably end up leveraging many things in Java > > > If you insist on message queues, maybe. But to me 'SOA' can equally mean > > WSDL > > or REST end points, performing fairly simple jobs on a database. > > > > fact that your SOA solution would have a fixed starting cost of maybe > > 10k > > > There are free-er CFML runtimes. > > > -- > > Tom Chiverton > > Helping to adaptively harness cross-platform infomediaries > > on:http://thefalken.livejournal.com > > > **************************************************** > > > This email is sent for and on behalf of Halliwells LLP. > > > Halliwells LLP is a limited liability partnership registered in England > > and Wales under registered number OC307980 whose registered office address > > is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. > > A list of members is available for inspection at the registered office. Any > > reference to a partner in relation to Halliwells LLP means a member of > > Halliwells LLP. Regulated by The Solicitors Regulation Authority. > > > CONFIDENTIALITY > > > This email is intended only for the use of the addressee named above and > > may be confidential or legally privileged. If you are not the addressee you > > must not read it and must not use any information contained in nor copy it > > nor inform any person other than Halliwells LLP or the addressee of its > > existence or contents. If you have received this email in error please > > delete it and notify Halliwells LLP IT Department on 0870 365 2500. > > > For more information about Halliwells LLP visitwww.halliwells.com. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
