Administrator
|
Hi,
Somethings I would like to do on OFBiz site main page : Make clear ERP, CRM, SCM, MRP, CMMS and EAM abreviations in this sentence <<The Apache Open For Business Project is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.>> Something like <<The Apache Open For Business Project is an open source enterprise automation software project licensed under the Apache License Version 2.0. By open source enterprise automation we mean: Open Source ERP (Enterprise Ressouces Planning), Open Source CRM (Customer Relationship Management), Open Source E-Business / E-Commerce, Open Source SCM (Supply Chain Management), Open Source MRP (Materials Requirements Planning), Open Source CMMS (Computerized Maintenance Management System)/EAM (Enterprise Asset Management) and so on.>> I would also like to add a basic "How works OFBiz" section, before "Who is Using Apache OFBiz?" where concepts like SOA (Services Oriented Architecture - I put an "s" explicity), EDA (Events Driven Architecture) and SOI (Services Oriented Integration) would be explained with a sentence or two on how it's implemented in OFBiz (implementable for SOI). More and more people are turning to ESBs and this should attract some interesting users... Jacques From: "Jacques Le Roux" <[hidden email]> > Thanks for comment Raj, > > I have read this interesting article you previously mentionned before making this suggestion. Actually it was that that decided me > to make this proposition. > David well explained what ECAs are in OFBiz : a local EDA implementation. > Because ERP are integrated, and focused on some aspects of entreprise business, they can't be compared to systems build around an > ESB. > Actually you made the same confusion than people who think that Web Services are "the" SOA architecture. > OFBiz proves that such an architecture can exist in a sole system. It has it own SOA architecture, which can even be used from > outside and can use outside services (with limitations OOTB). > We are often asked about SOAP services, and why OFBiz don't provide an easier access to its services (limitation to simple types > currently). > This is because we focus on business implentation and we don't compete with Apache ServiceMix and such (also a manpower issue, > though some efforts has been done in this area http://docs.ofbiz.org/x/yhc - not tested yet, by me at least) > > I think I will use David comments as a basis to write few sentences to put on the section I mentionned. Any help, comments, are > welcome of course.... > > Jacques > > From: "David E Jones" <[hidden email]> >> >> You're confusing the concept with a means of implementing the concept. Also, I don't mean to imply that Service ECA Rules are >> the only way of implementing the concept, but they are one way. That is why I recommended that you look at how SECA rules are >> used in OFBiz (like triggering order item completion with a shipment is packed, order completion on order item completion, and >> by the same means invoicing and many other business processes). >> >> It is not an enterprise-wide form of EDA, just like the service engine is not an enterprise-wide form of SOA. If enterprise-wide >> SOA and EDA tools are used OFBiz can integrate easily with these since internally it is architected using the same principles >> (ie can consume and produce services, and can generate and listen to events. >> >> -David >> >> >> On Jan 17, 2009, at 10:17 PM, Raj Saini wrote: >> >>> I see the events in a event-driven system are emitted by some sources (or agents) and consumed by consumers ( sinks). Sinks >>> have the responsibility of applying a reaction as soon as an event is presented. Generally, event are transmitted among loosely >>> coupled software components. One important think to note here is that source and sinks may not be aware of each other in the >>> event processing and hence this results in the highly modular and loosely coupled applications. >>> >>> I apologizes if I am wrong but I see ECAs as interceptors similar to the aspect oriented stuff and they are triggered as part >>> of the call to service. >>> >>> Thanks, >>> >>> Raj >>> >>> David E Jones wrote: >>>> >>>> It would not be correct to say that EDA (Event Driven Architecture) and ECA (Event-Condition-Action rules) are the same thing. >>>> It would be correct to say that ECA Rules are one way of implementing an event-driven architecture (EDA). >>>> >>>> If you look at how ECA rules are used in OFBiz you'll see it is very consistent with the general EDA concepts. With all logic >>>> flowing through the Service Engine in OFBiz it becomes a natural hub for business events, and ECA rules allow us to do things >>>> based on those business events. >>>> >>>> If you disagree, please do share. How is your vision of an EDA different from how we use ECA rules in OFBiz? >>>> >>>> -David >>>> >>>> >>>> On Jan 17, 2009, at 9:07 PM, Raj Saini wrote: >>>> >>>>> Is ECA same as EDA? I feel ECAs in OFBiz are more like interceptors/triggers where are EDA is all together a different >>>>> architecture pattern. This is a good document explain EDA: >>>>> >>>>> http://www.eaipatterns.com/docs/EDA.pdf >>>>> >>>>> Thanks, >>>>> >>>>> Raj >>>>> >>>>> Jacques Le Roux wrote: >>>>>> I think, as a marketing effort, we should put 2-3 sentences about SOA (Service Oriented Architecture) and EDA (Event Driven >>>>>> Architecture) OFBiz's features on main site, in "Introduction: What is Apache OFBiz?" section for instance. >>>>>> Buzz words (acronyms nowadays) can't hurt if we want more recognition. And it's easier to be understood by using SOA >>>>>> acronym than Service Engine and especially EDA instead of ECA. Of course a sentence explaining quickly both concepts is >>>>>> needed. >>>>>> >>>>>> Any takers ? (several would be better...) >>>>>> >>>>>> Jacques >>>>>> >>>>> >>>> >>>> >>> >> > |
On Jan 22, 2009, at 10:37 AM, Jacques Le Roux wrote: > Hi, > > Somethings I would like to do on OFBiz site main page : > > Make clear ERP, CRM, SCM, MRP, CMMS and EAM abreviations in this > sentence > <<The Apache Open For Business Project is an open source enterprise > automation software project licensed under the Apache License > Version 2.0. By open source enterprise automation we mean: Open > Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, > Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.>> > Something like > <<The Apache Open For Business Project is an open source enterprise > automation software project licensed under the Apache License > Version 2.0. By open source enterprise automation we mean: Open > Source ERP (Enterprise Ressouces Planning), Open Source CRM > (Customer Relationship Management), Open Source E-Business / E- > Commerce, Open Source SCM (Supply Chain Management), Open Source MRP > (Materials Requirements Planning), Open Source CMMS (Computerized > Maintenance Management System)/EAM (Enterprise Asset Management) and > so on.>> I originally chose not to do this because it is very verbose. Even the stuff there now is probably too much, and a simple "Open Source ERP, CRM, and eCommerce" would be sufficient. > I would also like to add a basic "How works OFBiz" section, before > "Who is Using Apache OFBiz?" where concepts like SOA (Services > Oriented Architecture - I put an "s" explicity), EDA (Events Driven > Architecture) and SOI (Services Oriented Integration) would be > explained with a sentence or two on how it's implemented in OFBiz > (implementable for SOI). More and more people are turning to ESBs > and this should attract some interesting users... Before we can make a decision about this sort of thing we really need to do the site redesign thing that has been discussed so much, starting with defining our target audiences and then making sure the info they need is available. There are lots of marketing messages we could deliver, but choosing is important because otherwise there is SO MUCH information it makes all of it less valuable (no one will read through all of it... no one reads through what is currently there... it's already too much...). Here is the page started long long ago to get that going: http://docs.ofbiz.org/display/OFBIZ/OFBiz.org+New+Site+Plan -David > > From: "Jacques Le Roux" <[hidden email]> >> Thanks for comment Raj, >> >> I have read this interesting article you previously mentionned >> before making this suggestion. Actually it was that that decided me >> to make this proposition. >> David well explained what ECAs are in OFBiz : a local EDA >> implementation. >> Because ERP are integrated, and focused on some aspects of >> entreprise business, they can't be compared to systems build around >> an ESB. >> Actually you made the same confusion than people who think that Web >> Services are "the" SOA architecture. >> OFBiz proves that such an architecture can exist in a sole system. >> It has it own SOA architecture, which can even be used from outside >> and can use outside services (with limitations OOTB). >> We are often asked about SOAP services, and why OFBiz don't provide >> an easier access to its services (limitation to simple types >> currently). >> This is because we focus on business implentation and we don't >> compete with Apache ServiceMix and such (also a manpower issue, >> though some efforts has been done in this area http://docs.ofbiz.org/x/yhc >> - not tested yet, by me at least) >> >> I think I will use David comments as a basis to write few sentences >> to put on the section I mentionned. Any help, comments, are welcome >> of course.... >> >> Jacques >> >> From: "David E Jones" <[hidden email]> >>> >>> You're confusing the concept with a means of implementing the >>> concept. Also, I don't mean to imply that Service ECA Rules are >>> the only way of implementing the concept, but they are one way. >>> That is why I recommended that you look at how SECA rules are >>> used in OFBiz (like triggering order item completion with a >>> shipment is packed, order completion on order item completion, >>> and by the same means invoicing and many other business processes). >>> >>> It is not an enterprise-wide form of EDA, just like the service >>> engine is not an enterprise-wide form of SOA. If enterprise-wide >>> SOA and EDA tools are used OFBiz can integrate easily with these >>> since internally it is architected using the same principles (ie >>> can consume and produce services, and can generate and listen to >>> events. >>> >>> -David >>> >>> >>> On Jan 17, 2009, at 10:17 PM, Raj Saini wrote: >>> >>>> I see the events in a event-driven system are emitted by some >>>> sources (or agents) and consumed by consumers ( sinks). Sinks >>>> have the responsibility of applying a reaction as soon as an >>>> event is presented. Generally, event are transmitted among >>>> loosely coupled software components. One important think to note >>>> here is that source and sinks may not be aware of each other in >>>> the event processing and hence this results in the highly >>>> modular and loosely coupled applications. >>>> >>>> I apologizes if I am wrong but I see ECAs as interceptors similar >>>> to the aspect oriented stuff and they are triggered as part of >>>> the call to service. >>>> >>>> Thanks, >>>> >>>> Raj >>>> >>>> David E Jones wrote: >>>>> >>>>> It would not be correct to say that EDA (Event Driven >>>>> Architecture) and ECA (Event-Condition-Action rules) are the >>>>> same thing. It would be correct to say that ECA Rules are one >>>>> way of implementing an event-driven architecture (EDA). >>>>> >>>>> If you look at how ECA rules are used in OFBiz you'll see it is >>>>> very consistent with the general EDA concepts. With all logic >>>>> flowing through the Service Engine in OFBiz it becomes a >>>>> natural hub for business events, and ECA rules allow us to do >>>>> things based on those business events. >>>>> >>>>> If you disagree, please do share. How is your vision of an EDA >>>>> different from how we use ECA rules in OFBiz? >>>>> >>>>> -David >>>>> >>>>> >>>>> On Jan 17, 2009, at 9:07 PM, Raj Saini wrote: >>>>> >>>>>> Is ECA same as EDA? I feel ECAs in OFBiz are more like >>>>>> interceptors/triggers where are EDA is all together a different >>>>>> architecture pattern. This is a good document explain EDA: >>>>>> >>>>>> http://www.eaipatterns.com/docs/EDA.pdf >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Raj >>>>>> >>>>>> Jacques Le Roux wrote: >>>>>>> I think, as a marketing effort, we should put 2-3 sentences >>>>>>> about SOA (Service Oriented Architecture) and EDA (Event >>>>>>> Driven Architecture) OFBiz's features on main site, in >>>>>>> "Introduction: What is Apache OFBiz?" section for instance. >>>>>>> Buzz words (acronyms nowadays) can't hurt if we want more >>>>>>> recognition. And it's easier to be understood by using SOA >>>>>>> acronym than Service Engine and especially EDA instead of ECA. >>>>>>> Of course a sentence explaining quickly both concepts is >>>>>>> needed. >>>>>>> >>>>>>> Any takers ? (several would be better...) >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> > |
Administrator
|
Yes I agree ! I will put my new idea on this page I should not have forgotten :/
Jacques From: "David E Jones" <[hidden email]> > > On Jan 22, 2009, at 10:37 AM, Jacques Le Roux wrote: > >> Hi, >> >> Somethings I would like to do on OFBiz site main page : >> >> Make clear ERP, CRM, SCM, MRP, CMMS and EAM abreviations in this >> sentence >> <<The Apache Open For Business Project is an open source enterprise >> automation software project licensed under the Apache License >> Version 2.0. By open source enterprise automation we mean: Open >> Source ERP, Open Source CRM, Open Source E-Business / E-Commerce, >> Open Source SCM, Open Source MRP, Open Source CMMS/EAM, and so on.>> >> Something like >> <<The Apache Open For Business Project is an open source enterprise >> automation software project licensed under the Apache License >> Version 2.0. By open source enterprise automation we mean: Open >> Source ERP (Enterprise Ressouces Planning), Open Source CRM >> (Customer Relationship Management), Open Source E-Business / E- >> Commerce, Open Source SCM (Supply Chain Management), Open Source MRP >> (Materials Requirements Planning), Open Source CMMS (Computerized >> Maintenance Management System)/EAM (Enterprise Asset Management) and >> so on.>> > > I originally chose not to do this because it is very verbose. Even the > stuff there now is probably too much, and a simple "Open Source ERP, > CRM, and eCommerce" would be sufficient. > >> I would also like to add a basic "How works OFBiz" section, before >> "Who is Using Apache OFBiz?" where concepts like SOA (Services >> Oriented Architecture - I put an "s" explicity), EDA (Events Driven >> Architecture) and SOI (Services Oriented Integration) would be >> explained with a sentence or two on how it's implemented in OFBiz >> (implementable for SOI). More and more people are turning to ESBs >> and this should attract some interesting users... > > Before we can make a decision about this sort of thing we really need > to do the site redesign thing that has been discussed so much, > starting with defining our target audiences and then making sure the > info they need is available. There are lots of marketing messages we > could deliver, but choosing is important because otherwise there is SO > MUCH information it makes all of it less valuable (no one will read > through all of it... no one reads through what is currently there... > it's already too much...). > > Here is the page started long long ago to get that going: > > http://docs.ofbiz.org/display/OFBIZ/OFBiz.org+New+Site+Plan > > -David > > >> >> From: "Jacques Le Roux" <[hidden email]> >>> Thanks for comment Raj, >>> >>> I have read this interesting article you previously mentionned >>> before making this suggestion. Actually it was that that decided me >>> to make this proposition. >>> David well explained what ECAs are in OFBiz : a local EDA >>> implementation. >>> Because ERP are integrated, and focused on some aspects of >>> entreprise business, they can't be compared to systems build around >>> an ESB. >>> Actually you made the same confusion than people who think that Web >>> Services are "the" SOA architecture. >>> OFBiz proves that such an architecture can exist in a sole system. >>> It has it own SOA architecture, which can even be used from outside >>> and can use outside services (with limitations OOTB). >>> We are often asked about SOAP services, and why OFBiz don't provide >>> an easier access to its services (limitation to simple types >>> currently). >>> This is because we focus on business implentation and we don't >>> compete with Apache ServiceMix and such (also a manpower issue, >>> though some efforts has been done in this area http://docs.ofbiz.org/x/yhc >>> - not tested yet, by me at least) >>> >>> I think I will use David comments as a basis to write few sentences >>> to put on the section I mentionned. Any help, comments, are welcome >>> of course.... >>> >>> Jacques >>> >>> From: "David E Jones" <[hidden email]> >>>> >>>> You're confusing the concept with a means of implementing the >>>> concept. Also, I don't mean to imply that Service ECA Rules are >>>> the only way of implementing the concept, but they are one way. >>>> That is why I recommended that you look at how SECA rules are >>>> used in OFBiz (like triggering order item completion with a >>>> shipment is packed, order completion on order item completion, >>>> and by the same means invoicing and many other business processes). >>>> >>>> It is not an enterprise-wide form of EDA, just like the service >>>> engine is not an enterprise-wide form of SOA. If enterprise-wide >>>> SOA and EDA tools are used OFBiz can integrate easily with these >>>> since internally it is architected using the same principles (ie >>>> can consume and produce services, and can generate and listen to >>>> events. >>>> >>>> -David >>>> >>>> >>>> On Jan 17, 2009, at 10:17 PM, Raj Saini wrote: >>>> >>>>> I see the events in a event-driven system are emitted by some >>>>> sources (or agents) and consumed by consumers ( sinks). Sinks >>>>> have the responsibility of applying a reaction as soon as an >>>>> event is presented. Generally, event are transmitted among >>>>> loosely coupled software components. One important think to note >>>>> here is that source and sinks may not be aware of each other in >>>>> the event processing and hence this results in the highly >>>>> modular and loosely coupled applications. >>>>> >>>>> I apologizes if I am wrong but I see ECAs as interceptors similar >>>>> to the aspect oriented stuff and they are triggered as part of >>>>> the call to service. >>>>> >>>>> Thanks, >>>>> >>>>> Raj >>>>> >>>>> David E Jones wrote: >>>>>> >>>>>> It would not be correct to say that EDA (Event Driven >>>>>> Architecture) and ECA (Event-Condition-Action rules) are the >>>>>> same thing. It would be correct to say that ECA Rules are one >>>>>> way of implementing an event-driven architecture (EDA). >>>>>> >>>>>> If you look at how ECA rules are used in OFBiz you'll see it is >>>>>> very consistent with the general EDA concepts. With all logic >>>>>> flowing through the Service Engine in OFBiz it becomes a >>>>>> natural hub for business events, and ECA rules allow us to do >>>>>> things based on those business events. >>>>>> >>>>>> If you disagree, please do share. How is your vision of an EDA >>>>>> different from how we use ECA rules in OFBiz? >>>>>> >>>>>> -David >>>>>> >>>>>> >>>>>> On Jan 17, 2009, at 9:07 PM, Raj Saini wrote: >>>>>> >>>>>>> Is ECA same as EDA? I feel ECAs in OFBiz are more like >>>>>>> interceptors/triggers where are EDA is all together a different >>>>>>> architecture pattern. This is a good document explain EDA: >>>>>>> >>>>>>> http://www.eaipatterns.com/docs/EDA.pdf >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Raj >>>>>>> >>>>>>> Jacques Le Roux wrote: >>>>>>>> I think, as a marketing effort, we should put 2-3 sentences >>>>>>>> about SOA (Service Oriented Architecture) and EDA (Event >>>>>>>> Driven Architecture) OFBiz's features on main site, in >>>>>>>> "Introduction: What is Apache OFBiz?" section for instance. >>>>>>>> Buzz words (acronyms nowadays) can't hurt if we want more >>>>>>>> recognition. And it's easier to be understood by using SOA >>>>>>>> acronym than Service Engine and especially EDA instead of ECA. >>>>>>>> Of course a sentence explaining quickly both concepts is >>>>>>>> needed. >>>>>>>> >>>>>>>> Any takers ? (several would be better...) >>>>>>>> >>>>>>>> Jacques >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >> > |
Free forum by Nabble | Edit this page |