About Static Methods in Ofbiz

[Hemanth Kumar Kanamarlapudi]

Hi Users,

Can any one tell me the architectural reason why all the java methods are static and how these will be thread safe
Also any implications or the things we need to handle when we are using some third party java objects with out static methods from ofbiz static methods.

If any document about this is available please let me know the particular section or page number along with document url.

Thanks in advance.

Thanks & Regards
Hemanth

________________________________
http://www.mindtree.com/email/disclaimer.html

[Adrian Crum]

I don't know what you mean by all the Java methods are static. There are
some static methods in utility classes, but that is standard practice in
Java programming.

The static methods are thread safe because there is no instance of the
enclosing class. In other words, the utility class does not have a state
that can be altered by threads.

-Adrian

Hemanth Kumar Kanamarlapudi wrote:

> Hi Users,
>
> Can any one tell me the architectural reason why all the java methods are static and how these will be thread safe
> Also any implications or the things we need to handle when we are using some third party java objects with out static methods from ofbiz static methods.
>
> If any document about this is available please let me know the particular section or page number along with document url.
>
> Thanks in advance.
>
> Thanks & Regards
> Hemanth
>
> ________________________________
> http://www.mindtree.com/email/disclaimer.html
>

[David E. Jones-2]

There is a little bit more to being thread-safe. The biggest danger  
comes when a static method refers to a static/class field because it  
may be used by multiple threads at the same time. This has happened a  
few times in the history of OFBiz, and hopefully there isn't anything  
like this in the code right now (and there are none that I am aware  
of), but there could be.

-David


On Sep 9, 2009, at 8:52 AM, Adrian Crum wrote:

> I don't know what you mean by all the Java methods are static. There  
> are some static methods in utility classes, but that is standard  
> practice in Java programming.
>
> The static methods are thread safe because there is no instance of  
> the enclosing class. In other words, the utility class does not have  
> a state that can be altered by threads.
>
> -Adrian
>
> Hemanth Kumar Kanamarlapudi wrote:
>> Hi Users,
>> Can any one tell me the architectural reason why all the java  
>> methods are static and how these will be thread safe
>> Also any implications or the things we need to handle when we are  
>> using some third party java objects with out static methods from  
>> ofbiz static methods.
>> If any document about this is available please let me know the  
>> particular section or page number along with document url.
>> Thanks in advance.
>> Thanks & Regards
>> Hemanth
>> ________________________________
>> http://www.mindtree.com/email/disclaimer.html

[James McGill-5]

On Wed, Sep 9, 2009 at 7:52 AM, Adrian Crum <[hidden email]> wrote:

> I don't know what you mean by all the Java methods are static.
> -Adrian


With very few exceptions, all the service methods in all the applications,
as far as I've seen, are static.
I'm sure there's a solid rationale for this approach, but I'd like to know
the details.  It seems to make it
more of a "Class - function" oriented design, not "Object" oriented, and
it's unusual Java.

--
James McGill
Able Engineering
Phoenix, Arizona

[David E. Jones-2]

On Sep 9, 2009, at 2:29 PM, James McGill wrote:

> On Wed, Sep 9, 2009 at 7:52 AM, Adrian Crum <[hidden email]>  
> wrote:
>
>> I don't know what you mean by all the Java methods are static.
>> -Adrian
>
>
> With very few exceptions, all the service methods in all the  
> applications,
> as far as I've seen, are static.
> I'm sure there's a solid rationale for this approach, but I'd like  
> to know
> the details.  It seems to make it
> more of a "Class - function" oriented design, not "Object" oriented,  
> and
> it's unusual Java.

You're right, services are not object-oriented, they follow a service  
oriented architecture. You can use objects within the services, but  
the point of them is to operate in a more isolated and well-defined  
context. In other words they should only know about the parameters  
passed in and what they can find in the database or by calling another  
service, and likewise they should only persist in the database or by  
calling other services.

To better understand the architecture of OFBiz and to get an idea of  
the big picture (which will help this make more sense), please watch  
the framework introduction videos available here:

http://docs.ofbiz.org/display/OFBTECH/Framework+Introduction+Videos+and+Diagrams

-David

[Shi Jinghai]

Personally I think it's because of the convenience in ftl.

We try to use getInstance().method(...) to call methods instead of using
static methods.


在 2009-09-09三的 16:36 +0530，Hemanth Kumar Kanamarlapudi写道：

> Hi Users,
>
> Can any one tell me the architectural reason why all the java methods are static and how these will be thread safe
> Also any implications or the things we need to handle when we are using some third party java objects with out static methods from ofbiz static methods.
>
> If any document about this is available please let me know the particular section or page number along with document url.
>
> Thanks in advance.
>
> Thanks & Regards
> Hemanth
>
> ________________________________
> http://www.mindtree.com/email/disclaimer.html

[James McGill-5]

I'm not the best communicator in these forums, I realize.

I understand the service architecture pretty well, and have explored the
applications that relate to my business requirement in some depth.  I didn't
intend to come across as skeptical of the design, but rather, curious as to
whether there are performance and/or scaling considerations that are
addressed by the static procedure calls.
Are server JRE's happier with static members?  Is there a lesser need for
runtime optimizations?  Does this make it simpler to scale the application
by deploying multiple servers?

It's early in our development effort, but we have been wondering about the
scalability of OFBiz (or specifically, of the product/order applications for
inventory control and supply chain).  I shouldn't change the subject
mid-thread this way, so I will try to formulate more specific questions
about scaling.

I'm hoping for more specific advice than is found here:
http://docs.ofbiz.org/display/OFBADMIN/Scaling+and+Performance+Plan

I also wonder if anyone can share a case study of OFBiz applied to
industrial supply chain, say with multiple facilities or unusual product /
work effort configurations.

--
James McGill
Able Engineering

[David E. Jones-2]

On Sep 10, 2009, at 8:48 PM, James McGill wrote:

> I'm not the best communicator in these forums, I realize.
>
> I understand the service architecture pretty well, and have explored  
> the
> applications that relate to my business requirement in some depth.  
> I didn't
> intend to come across as skeptical of the design, but rather,  
> curious as to
> whether there are performance and/or scaling considerations that are
> addressed by the static procedure calls.
> Are server JRE's happier with static members?  Is there a lesser  
> need for
> runtime optimizations?  Does this make it simpler to scale the  
> application
> by deploying multiple servers?

With these questions you are implying issues but not actually saying  
what you are worried about...

What is it that concerns you?

> It's early in our development effort, but we have been wondering  
> about the
> scalability of OFBiz (or specifically, of the product/order  
> applications for
> inventory control and supply chain).  I shouldn't change the subject
> mid-thread this way, so I will try to formulate more specific  
> questions
> about scaling.
>
> I'm hoping for more specific advice than is found here:
> http://docs.ofbiz.org/display/OFBADMIN/Scaling+and+Performance+Plan
>
> I also wonder if anyone can share a case study of OFBiz applied to
> industrial supply chain, say with multiple facilities or unusual  
> product /
> work effort configurations.

Are you worried about the customization side of things, or the scaling  
side of things? Or, perhaps both?

If you haven't already you could check out the OFBiz users wiki page  
to see some of the end-users and a bit about what they've done with  
OFBiz (usually not a lot of details, but general ideas and company  
names are sometimes enough).

-David

[Shi Jinghai]

One of the top 10 banks in China (top 30 in Asia, top 300 worldwide) is
building its core system on OFBiz.

Many banks are waiting to see the result. If success, David can announce
OFBiz has reached the goal on affecting 20% of world economy :).

Hope this will come true soon.


在 2009-09-10四的 21:51 -0600，David E Jones写道：

> On Sep 10, 2009, at 8:48 PM, James McGill wrote:
>
> > I'm not the best communicator in these forums, I realize.
> >
> > I understand the service architecture pretty well, and have explored  
> > the
> > applications that relate to my business requirement in some depth.  
> > I didn't
> > intend to come across as skeptical of the design, but rather,  
> > curious as to
> > whether there are performance and/or scaling considerations that are
> > addressed by the static procedure calls.
> > Are server JRE's happier with static members?  Is there a lesser  
> > need for
> > runtime optimizations?  Does this make it simpler to scale the  
> > application
> > by deploying multiple servers?
>
> With these questions you are implying issues but not actually saying  
> what you are worried about...
>
> What is it that concerns you?
>
> > It's early in our development effort, but we have been wondering  
> > about the
> > scalability of OFBiz (or specifically, of the product/order  
> > applications for
> > inventory control and supply chain).  I shouldn't change the subject
> > mid-thread this way, so I will try to formulate more specific  
> > questions
> > about scaling.
> >
> > I'm hoping for more specific advice than is found here:
> > http://docs.ofbiz.org/display/OFBADMIN/Scaling+and+Performance+Plan
> >
> > I also wonder if anyone can share a case study of OFBiz applied to
> > industrial supply chain, say with multiple facilities or unusual  
> > product /
> > work effort configurations.
>
> Are you worried about the customization side of things, or the scaling  
> side of things? Or, perhaps both?
>
> If you haven't already you could check out the OFBiz users wiki page  
> to see some of the end-users and a bit about what they've done with  
> OFBiz (usually not a lot of details, but general ideas and company  
> names are sometimes enough).
>
> -David
>
>

[James McGill-5]

On Thu, Sep 10, 2009 at 8:51 PM, David E Jones <[hidden email]> wrote:

> With these questions you are implying issues but not actually saying what
> you are worried about...
>
> What is it that concerns you?

My instincts tell me what I need to know personally, but I am
anticipating questions from the people who drive my project, that's
all.  OFBiz isn't something with enough mindshare to build its own
confidence among the suits, and it falls on me to sell it.  I know
there are plenty of people using OFBiz successfully, but none of them
quite matches our particular square peg; a specialized type of supply
chain management in aerospace engineering.

> Are you worried about the customization side of things, or the scaling side of things? Or, perhaps both?

We are finding Product and Order to be a very good starting point,
actually, and we just need to add some industry-specific details to
the inventory process, and we have some work to do because our concept
of "work effort" doesn't quite match what's defined in OFBiz
out-of-the-box.  It doesn't seem like a huge job so we are fairly
confident (and wish to give kudos to you and everyone who has worked
to get the application this far!)

We don't even expect to face many "scaling" issues, just basic
concerns about what will happen when we have to deploy in two or three
facilities that might not be able to share a database instance, or
what happens when inventory and order records get really large.

Our senior management is understandably risk-averse, since the
situation that leads us to a customized solution is a result of
failure of other solutions to scale to our current needs.  It's up to
me to reassure them, but I'm mainly going on instincts and hope and my
own evaluation of the framework.

I've probably talked too much under the subject of "Static methods",
since that's not really my concern.  I would still very much enjoy
hearing from anyone who has done supply chain and inventory control
work in OFBiz, especially if their model doesn't quite match what
OFBiz's model of "manufacturing."

--
James McGill
Able Engineering

[David E. Jones-2]

On Sep 10, 2009, at 11:59 PM, James McGill wrote:

> On Thu, Sep 10, 2009 at 8:51 PM, David E Jones <[hidden email]> wrote:
>
>> With these questions you are implying issues but not actually  
>> saying what
>> you are worried about...
>>
>> What is it that concerns you?
>
> My instincts tell me what I need to know personally, but I am
> anticipating questions from the people who drive my project, that's
> all.  OFBiz isn't something with enough mindshare to build its own
> confidence among the suits, and it falls on me to sell it.  I know
> there are plenty of people using OFBiz successfully, but none of them
> quite matches our particular square peg; a specialized type of supply
> chain management in aerospace engineering.

Depending on narrowly you define your industry, size of company, type  
of products, etc you'll have more or less success finding a similar  
company using Apache OFBiz. There are hundreds of companies with  
production deployments of it, but there are so many types and sizes of  
companies out there. To make things more difficult this isn't  
commercial software where a vendor can require users to buy a license  
and tell them what they are doing with it... so none of us really  
knows a whole lot about what everyone is using the software for aside  
from things people share on the mailing lists/etc or things for  
clients or others they are working with.

>> Are you worried about the customization side of things, or the  
>> scaling side of things? Or, perhaps both?
>
> We are finding Product and Order to be a very good starting point,
> actually, and we just need to add some industry-specific details to
> the inventory process, and we have some work to do because our concept
> of "work effort" doesn't quite match what's defined in OFBiz
> out-of-the-box.  It doesn't seem like a huge job so we are fairly
> confident (and wish to give kudos to you and everyone who has worked
> to get the application this far!)
>
> We don't even expect to face many "scaling" issues, just basic
> concerns about what will happen when we have to deploy in two or three
> facilities that might not be able to share a database instance, or
> what happens when inventory and order records get really large.

This is different from what people usually talk about when speaking of  
scaling. OFBiz does have features that help with running distributed  
synchronized systems, mainly through the Entity Sync functionality.  
This is used for POS systems where you might have 2-4 (or more!)  
levels of servers (ie like POS system, in-store server, regional  
server, main central server). This is also used for ecommerce sites,  
usually with different sites for different parts of the world and  
hosted in data centers in different parts of the world, with customer  
and order and other data all flowing to a central server (or server  
pool).

One thing to keep in mind with this is that the data propagation is  
asynchronous. That means you don't want to rely on it for high  
conflict things like inventory checks, unless each server pool takes  
care of only inventory in a certain facility/warehouse, or inventory  
is handled physically as in a physical store.

> Our senior management is understandably risk-averse, since the
> situation that leads us to a customized solution is a result of
> failure of other solutions to scale to our current needs.  It's up to
> me to reassure them, but I'm mainly going on instincts and hope and my
> own evaluation of the framework.

This can be a tough thing. It is all too common for executives to  
evaluate software in terms of how successful the business is that is  
selling the software. With community-driven open source software  
trying to do that will lead to a great deal of discomfort and  
confusion... ;)

As for failure, you can mess up a project based on OFBiz just as  
easily as on other systems or on custom software. That's why my big  
thing these days (and my big bread winner) is HEMP:

http://www.dejc.com/home/HEMP.html

To increase discomfort and confusion I've decided to make this  
material available for free too! ;)

> I've probably talked too much under the subject of "Static methods",
> since that's not really my concern.  I would still very much enjoy
> hearing from anyone who has done supply chain and inventory control
> work in OFBiz, especially if their model doesn't quite match what
> OFBiz's model of "manufacturing."

There are lots of people who do supply chain and inventory control  
with OFBiz, mostly in the retail sector, and some including very  
complex setups with multiple warehouses, retail stores, multiple web  
sites, hundreds of thousands of products and hundreds of suppliers,  
and so on. The manufacturing stuff in OFBiz does some of this too, and  
that stuff is pretty comprehensive and functional, and mostly sits on  
the more general supply chain and inventory control stuff in OFBiz  
that is used for many other things.

Best of luck with you evaluation effort... many of the best  
deployments happened because someone internally pushed OFBiz as an  
option. I know that's true with some of the bigger companies using it  
who I've worked with, including British Telecom and United Airlines.

-David