At 04:01 AM 10/26/2001, Aaron Trevena wrote:
>Hi everyone.
>
>I thought I'd mention a couple of concerns..
>
>One of the key 'widgets' in the ecommerce space is banking and merchant
>functionality.
Aaron, while I think commerce is quite important, I personally do not feel
it belongs as part of the P5EE space.
As I've mentioned previously on this list, P5EE is about generic enterprise
frameworks. Banking and merchant functionality is a specific space.
Business::CreditCard belong in a Commerce Perl bundle which ideally would
be "P5EE-Enabled" to plug into a P5EE transaction or web services server.
But it would not come with P5EE.
>In fact its pretty key whether its business logic or a technology
>component. In the module list so far I saw Business::CreditCard - I don't
>know how much that does but it would need to provide some very important
>services, handling not only the handful of online CC processors but also
>banks that companies are already with such as Barclays or HSBC or Chase or
>MSDW.
>
>Also we need to provide a strong selection of business oriented
>ready-to-go components. Tax, Handling, all kinds of business logic that
>often play an important role in any commerce system online or internal.
>
>An enterprise framework means not only being ready to work on the web, but
>also the warehouse, in accounting, and the shop floor. As with Content
>Management most of the functionality is implemented over and over again -
>often poorly or expensively. If key components are ready to roll then it
>makes p5ee more attractive to both developers and managers and makes a
>convincing business case.
>
>As with the W3c who provided the first browser and web server and fostered
>competition while setting a standard building componments will not only
>test the feasibility of the framework but also encourage uptake.
>
>I only mention this because finance and merchant tasks don't *seem* to be
>as well covered as the internet and technology and it often takes only a
>small amount of work to turn a generic vanilla piece of technology into a
>ready to use business logic based component.
I disagree semantically with the last statement. It does not take a small
amount of work to take a vanilla piece of technology to make a ready to use
business logic based component.
It may be true in the sense of specific business rules, but taken as a
generic whole, the commerce space is very different from the life sciences
space which is very different from the banking space which is different
from the mobile phone space, etc.
Also, at the level of business rules, there are so many ways to skin the
cat, that it doesn't make sense to force people into a generic commerce
API. I would prefer to see healthy competition in this area just as we see
with Java.
P5EE should limit itself to the framework that allows YOU to create your
commerce framework if you like. And then the P5EE initiative will label you
as P5EE enabled if you support components on top of P5EE components. But
they should not be P5EE-forced.
I believe this is somethign that Java does correctly. JavaSoft makes J2EE
comprehensive but minimal. It's just mail ,servlets, messaging, transaction
server...
But JDBC, Security and other key APIs are part of the normal SDK.
And extensions on top of that are the realm of other companies or other
initiatives within Sun. eg IBM San Francisco project is a huge business
rules framework for business in Java. San Francisco is a neat project BUT I
would be loathe to be forced to use it because it's been bundled in Sun's J2EE.
Anyway, semantically, you are pushing fora generic Commerce framework not
an Enterprise framework. The litmus test for an enterprise framework is
that it is useful across all industries horizontally.
Later,
Gunther
