OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [ubl-dev] Preparing for UBL

It may be interesting to look also at IBM WebSphere Business Integration Connect (version Express costs about $600 and supports AS2 protocol for information exchange, then there are more capable and of course more expensive version Advanced and Enterprise that may be used as a hub). WBI Connect does not explicitly support UBL, but it supports XML in general.

Ing. Miroslav Vaic 


Trask solutions &Igr; Business Integration

Podbabska 20, 160 46 Prague 6
Czech Republic


-----Original Message-----
From: David Lyon [mailto:david.lyon@computergrid.net] 
Sent: Friday, May 20, 2005 6:39 PM
To: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] Preparing for UBL


Yes they could do all that...

alternatively, they could just spend the $300 and buy a 
product like Computergrid which provides the capabilities
that they need.

This is what we are doing in the Computer Industry in
Australia - enabling Computer shops to be up and running
with UBL in about half an hour.

Small businesses just aren't like Government departments
or big companies - just don't have endless time or budgets
to play with. It's got to work quickly and simply..

As good as it may be.. if an open source UBL system requires
300 hours to get going, the real cost is 300 * whatever the
hourly rate is. That may run into the thousands...

Not all businesses want to waste that sort of money on
UBL... so people need to be clear about what the real costs
of "free" UBL actually are.

Anyway... food for thought...



On Thu, 19 May 2005 10:02 am, Stephen Green wrote:
> Micah
> A few simplistic notes (all my own opinion, etc and not to be relied on
> without checking
> out for accuracy, IP, regulations, etc...):
> you need trading partners who:
> - are willing to adopt UBL (persuasion and/or pressure needed here)
> - have the resources to adopt UBL (this you are already helping with the
> SBS) My own main
> item on my personal task list of how to prepare for adoption is to help
> with the SBS or
> equivalent and to fill any similar gaps to make adoption easier, preferably
> working with OASIS)
> - have themselves other trading partners who are willing to adopt UBL -
> hence getting UBL
> into horizontal acceptance would help prepare for adoption here, as with
> the SBS but also
> (as again you are already helping to do :-) ) with getting UBL into mass
> tools support
> such as encouraging XForms support for UBL in products like OOo (which
> arguably has
> an added advantage, perhaps politically and economically, of being free
> open source)
> then with regard to gaps and addressing the BPM side a bit you need:
> - for there to be (either because you or others have produced it or you or
> others have persuaded
> a suitable organisation to produce it on your and yourtrading partners'
> behalf) a specification
> of a suitable workflow or set of collaborations (as in ebXML-BPSS) to which
> trading partner agreements
> (for example, but not limited to, ebCPPs and ebCPAs) can refer. This helps
> with identification and
> thence routing and reliable handling of exchanged messages. Resources or
> relevant standards to
> your business may determine how you do this or prepare to do it. You might
> decide to set up a
> ebRegistry or UDDI registry to hold the various specs. For a BPSS you might
> need a registry to be
> set up on your and your trading partners' behalf by a suitable body or
> agency. If you are not
> in a suitable industry for it to be done by an industry body which your
> trading partners also regard
> then there might be problems (this is the bit I might find most difficult)
> - a suitable way to create the agreements and specs and for your trading
> partners to do so too
> (maybe you can help some of them do this, or maybe an agency you have in
> common can, or maybe
> your own agency would help them as well as you) - perhaps VANs will restyle
> themselves for this
> as DaveW mentioned
> - if you want super systems with full automation then the above needs to be
> done 'properly' - at
> least there may be limits imposed on how it can be done (perhaps it's still
> a bit early for this and besides
> you or your potential trading partners may find it too challenging, risky
> and politically unacceptable as yet)
> - for the BPSS and maybe for the CPP/CPAs and for any other preparations
> for trading I can think
> of you would need to identify the exact processes you wish to engage in
> with UBL (perhaps mixing
> with other standards too). In a BPSS you'd need to break this into
> collaborations, essentially binary
> (or more comlex) but one-way messages are possible. This can be helped with
> patterns (ebBP TC just
> mentioned that an Invoice might be a one-way 'exchange' and can use the
> pattern for this called
> 'Notification'. I guess for many either just the Invoice or just the Order
> or Order/OrderResponse
> (depending perhaps on your postion in a supply chain and your influence
> among you trading partners)
> would be the first for concentrating on for return on investment. Denmark
> and Sweden have started with
> Invoice and then started looking towards the Order. I'd prefer to start
> with the Order/OrderResponse
> where these could be used with web trading sites provided by suppliers who
> might then send OrderResponse
> messages and later Invoices too. A credit note might be handy but this
> doesn't exist in UBL yet and besides
> there may be less ROI for it (fewer messages) but it may be mandatory that
> you not mix paper with
> electronic in the same process (depends on local regulations perhaps)
> - you may need to clear the whole thing with stakeholders, auditors (local
> and industry), tax offices, etc
> Maybe there needs to be better help for these things in OASIS and even in
> the UBL TC (e.g. providing
> ebBPSS documents for the UBL processes, besides the SBS and form specs,
> etc) to help those in a
> more horizontal setting (not have a major industry body to provide them for
> your supply chain). That's
> the sort of position of need of help I would be in.
> Then you (and your trading partners but perhaps with different software for
> your different roles) need software to:
> - handle messages, perhaps routing depending on a message header such as
> ebMS
> - extract data for integration with legacy systems, etc
> - produce return messages at several 'layers' (e.g. for the messaging layer
> such as for reliable messaging, etc,
> for the general business layer e.g. to signal a message receieved,
> processed successfully, etc  the specific
> business message layer e.g. from your finance system e.g, to return an
> OrderResponse to an Order or an
> OrderResponseSimple)
>  - perhaps to add SSL, etc
>  - to send messages from the finance system or various message layers
>  - provide an audit trail
>  - archive messages and perhaps related artifacts with them or separately
>  - involve humans where necessary (e.g. on certain errors or where there
> were message contents that couldn't be
>     understood or just for every message contents before it gets into the
> finance system or perhaps to manually
>     or semi-manually input messages)
>  - in some cases you might need to use special software to extract
> paper-based output or input
>     into UBL (as with Denmark's) or from UBL into paper-based documentation
> (e.g. with UNLayout and Ken's stylesheets)
>  - some may wish to get software to automate the finding and arrabgements
> with suitable suppliers or buyers, etc
>  - validation software, e.g. based on Schematron, script or the like or
> perhaps using proprietary software
> Then you might need to customise UBL and produce tighter schemas specific
> to your needs (and get the
> trading partners to accept them too, perhaps combining theirs and yours),
> perhaps producing schematron
> schemas to help with the validation (yours and/or theirs). This assumes
> tighter coupling of trading partners
> and maybe you can do better than that with UBL (e.g. if there were to be a
> very common implementaion
> of UBL in readily available or even free-opensource software which met most
> requirements just enough
> to justify the extar work using it to get data to and from your systems and
> likewise appealled to your
> potential trading partners and had sufficient acceptance in the legal,
> government and finance departments
> to be allowed for this purpose e.g. being sufficiently non-exclusive for
> public sector use  --  e.g. OOo etc??)
> That's all I dare write for now.
> All the best
> Steve
> ----- Original Message -----
> From: "Micah Dubinko" <micah@dubinko.info>
> To: <ubl-dev@lists.oasis-open.org>
> Sent: Tuesday, May 17, 2005 11:15 PM
> Subject: [ubl-dev] Preparing for UBL
> > I am researching for an article on UBL. What steps would you recommend
> > an organization to take in order to prepare for UBL adoption?
> >
> > I'm also interested in any links between UBL and BPM, especially as
> > real-world experiences. Can anyone elaborate?
> >
> > Thanks!
> >
> > .micah
> >
> > --
> >   Available for consulting. XForms, web forms, information overload.
> >   Micah Dubinko                           mailto:micah@dubinko.info
> >   Brain Attic, L.L.C.                        http://brainattic.info
> >   Yahoo IM: mdubinko                                +1 623 298 5172
> >   Learn XForms today: http://xformsinstitute.com
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> > For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

Computergrid : The ones with the most connections win.

To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]