Re: [ebsoa] Sample Pattern: Receptionist as a Hub

["David RR Webber" <david@drrw.info>]

Matt,

Unfortuantely some of us have to work on XML projects for a living ; -)

Here's my take on the pattern language thingy.  I'm not sure I see a
clear winner in this field - but lots of religious choices.  I'd hate for us
to paint ourselves into a corner because:

#1 - we pick religion 'A', and that alienates everyone in other religions.

#2 - we spend way to much time trying to pick a religion.

#3 - people think they have to do patterns in religion 'A' in order to
       do ebSOA.

I'd much rather say we like the idea of patterns - and that we have
a neutral business-centric approach to this - where people can
develop examples in various domains and CoIs for ebSOA, with
tools that makes sense for that CoI.  BCM is also preaching this
same story - and the BCM Appendix A is all about building
libraries of good patterns and templates for a CoI.

Then - and this is key - we can focus in on the aspects of the
problem solution that the pattern language needs to expose and
manage from the ebSOA point of view.  I don't care what else
it does - but it absolutely has to have: (reaches for broken record again!),
wearing sveldt kid gloves:

#1 - context mechanism exposed in XML
#2 - ability to interface to choice point mechanism and linking and
switching
#3 - ability to use components of ebSOA stack.

Out of this fog we then have emerging communities that can take their
existing stuff - and present it as ebSOA patterns.  This drives lots of
good things - it makes it easier for people to align with ebSOA, and
then when they do align - because they are sharing concepts and
components - it drives easier alignment across communities and
better integration.  Not only should we be stating goals for ebSOA,
but we should be wisely choosing the paths to reach those goals
easily and expeditiously.

Thanks, DW

----- Original Message ----- 
From: "Matthew MacKenzie" <mattm@adobe.com>
To: "'David RR Webber'" <david@drrw.info>; "'Chiusano Joseph'"
<chiusano_joseph@bah.com>
Cc: "'ebSOA'" <ebsoa@lists.oasis-open.org>
Sent: Monday, May 10, 2004 7:53 AM
Subject: RE: [ebsoa] Sample Pattern: Receptionist as a Hub


> You should have stuck around during the last meeting and debated this.
> We've pretty much agreed on using some kind of pattern language.
>
> Patterns can be expressed in a fashion that appeals not only to
programmers,
> but the other interested folks...although a little programmer-centric
focus
> would be good for 'eb' at this point.
>
>
> -----Original Message-----
> From: David RR Webber [mailto:david@drrw.info]
> Sent: Sunday, May 09, 2004 6:27 PM
> To: Chiusano Joseph; Matthew MacKenzie
> Cc: ebSOA
> Subject: Re: [ebsoa] Sample Pattern: Receptionist as a Hub
>
> Joe / Matt,
>
> I'm not a big fan of picking a pattern language - as
> that tends to immediately lock you down into
> programmer land.
>
> Since we are 'eb' focused - the BCM approach is
> saying that there are 'eb' patterns out there that
> work for specific domains and CoI.  So - go there - makes
> those available to the community - and tailor them so they
> drive your solution stack.
>
> Some patterns can work great as office documents, others
> require agent tools, other form guides.  We should not
> limit ourselves - but rather describe the capabilities the
> pattern technology needs to enable.
>
> The users of the patterns should be able to leverage:
> context, linking and switching, XML, and scripting, to
> drive the implementation layer from the logical and
> conceptual 'eb' layers.
>
> This allows the solution providers to work with
> patterns and technology they know and trust
> with their CoI, while leveraging the OASIS
> ebSOA stack as the delivery layer.
>
> DW
>
> ----- Original Message ----- 
> From: "Chiusano Joseph" <chiusano_joseph@bah.com>
> To: "Matthew MacKenzie" <mattm@adobe.com>
> Cc: "ebSOA" <ebsoa@lists.oasis-open.org>
> Sent: Sunday, May 09, 2004 1:44 PM
> Subject: Re: [ebsoa] Sample Pattern: Receptionist as a Hub
>
>
> > Thanks Matt. Applying this to technology and integration, I believe the
> > rough equivalent would be an integration broker.
> >
> > If folks agree, what would be the next step given our charter? To show
> > how an integration broker can be used within an architecture to
> > communicate between (for example) 2 ebXML-based* systems, or perhaps
> > from a non-ebXML-based system to one that is?
> >
> > Just trying to get an early sense of where this patterns path could take
> > us, before we go too far with it.
> >
> > Joe
> >
> > *we would need to define what "ebXML-based" means, of course
> >
> > Matthew MacKenzie wrote:
> > >
> > > Here is an example of a "Pattern". Patterns can be defined for all
kinds
> of processes, not just software development. We may have to do a bit of
> research on what an appropriate pattern language would be for our work,
but
> this is a good example.
> > >
> > >
>
http://www.comp.lancs.ac.uk/computing/research/cseg/projects/pointer/pattern
> s/receptionistAsAHub/receptionistAsAHub.html
> > >
> > > ___________________________
> > > Matthew MacKenzie
> > > Senior Architect
> > > IDBU Server Solutions
> > > Adobe Systems Canada Inc.
> > > http://www.adobe.com/products/server/
> > > mattm@adobe.com
> > > +1 (506) 871.5409
> >
> > -- 
> > Kind Regards,
> > Joseph Chiusano
> > Associate
> > Booz | Allen | Hamilton
> >
>
>
>