I've added to David's excellent list of patterns below. I'm headed back
to New Orleans next Wed morning to present SOA (general concepts,
benefits, etc.) at a DOD conference, and I'm considering incorporating
the notion of patterns into my presentation.
Joe
David RR Webber wrote:
>
> Duane,
>
> OK - done - synopsis - this is the programmers eye-level view
> that fits into that world of people using UML to create
> enterprise integration applications with J2EE et al today.
>
> So - in addition to this - following Ben's usage - we need
> the SOA BUP - Business Use Patterns, as the overarching
> view here - that introduces what ebSOA is all about -
> and most important - how people can use SOA BUP
> to develop their own solution rapidly.
>
> That way we can dispense with the history lesson in
> OO et al -(well OK - that's NTH - so we'll keep it
> as an Appendix "The Evolution of SOA components").
>
> The SOA BUP will allow business integration designers
> to pick models and patterns, and create new patterns
> for their own for industry uses.
>
> Typical patterns would include:
>
> 1) Classic ebSOA - this is the ebXML pattern around BPM.
>
> 2) Holistic ebSOA - blends use of BPM with webservices.
>
> 3) POA - process-oriented architecture.
>
> 3) SOA - EAI service oriented architecture.
>
> 4) EPR - bespoke solution pattern(s) for particular
> sector domains - in this case eGovernment services
> and citizen-facing applications.
>
> and so on.
How about these possibilities:
5) Infrastructure - utilizing an SOA for infrastucture-type services
such as security, logging, discovery, etc.
6) Calculation - where part of the SOA provides a calculation result
based on input values (such as calculation of APR for a loan); but this
would be a pattern for a "segment" of an SOA, rather than an SOA
overall.
*** Maybe we need to think about "sub-patterns" as well? ***
7) Transactional - utilizing an SOA for transactional-based processing,
such as the submission/processing of a PO to receive an Invoice.
8) Notification - utilizing an SOA for notification-type services such
as a calendar service that sends notifications to other calendars when
an appointment is changed;
9) Others?
> What I'm chiefly after here is avoiding being button-holed.
>
> Ben's approach to SOA - while good for todays programmers
> can also suffer from rapid obsolescence - as witnessed from
> people touting POA, and varients already today. You are
> then yesterdays news.
>
> We need to have an adaptive model here - that can then
> assimulate the latest in-vogue programming components
> as they emerge.
>
> Therefore POA with ebSOA patterns
> keeps you right abreast of a new development. Hence
> SOA BUP is essential IMO. But more important
> it allows you to precisely define what a POA is in
> terms of your proven known value set of components.
> An erector kit.
>
> Thanks, DW
>
> ----- Original Message -----
> From: "Duane Nickull" <>
> To: <>
> Sent: Tuesday, June 08, 2004 6:55 PM
> Subject: [ebsoa] Ben's document
>
> > I also urge each and every one of you to read Ben's PDF document
> > uploaded to our members section. This reads very well.
> >
> > Duane
> >
> > --
> > Senior Standards Strategist
> > Adobe Systems, Inc.
> > http://www.adobe.com
> >
> >
> >
--
Kind Regards,
Joseph Chiusano
Associate
Booz | Allen | Hamilton
