Oera

[tamhas]

I am branching this off of another thread on validating input because it doesn't really have anything to do with that thread.

joey.jeremiah said:
I still have lots of catching up to do on architectures and I'd like to ask a couple more questions on OERA if I can -

1. Assuming it is desirable to conserve AppServer calls as much as possible, ideally satisfy a request with a single call. Should services be built so they can satisfy every request in a single call or as close as possible to that idea?

2. Continuing the first question, are Business Entities the foundation services, sort of speak, that on top of them larger composite services can be built, like, Business Tasks and Business Work flows?

For the first question, you need to think about both the AppServer and the message bus in terms of services ( see http://www.oehive.org/ESBAsAnApplicationArchitecture for my whitepaper on the use of a message bus ). Design of an SOA depends critically on the right breakdown of what is within a service and what is communicated between services. Within a service the connections between components can be fine-grained, but between services they are necessarily coarse-grained. There are a number of strategies for making this more efficient, e.g., caching frequently used data locally in a facade object. Unfortunately, we don't have quite the facility for service design that I think we should have because of the lack of a multi-threaded client ( see http://www.oehive.org/MultiThread ).

For the second question, a business entity is not a service, it is a component. An order service might request a customer object from the accounts receivable service, for example.

For a very interesting view of how to look at OERA, I recommend downloading the new AutoEdge reference application from PSDN. It and the associated whitepapers should give you a start, even if I don't agree with a lot of the specific details ... especially since I want to do it using objects!

 

[joey.jeremiah]

For the first question, you need to think about both the AppServer and the message bus in terms of services ( see http://www.oehive.org/ESBAsAnApplicationArchitecture for my whitepaper on the use of a message bus ). Design of an SOA depends critically on the right breakdown of what is within a service and what is communicated between services. Within a service the connections between components can be fine-grained, but between services they are necessarily coarse-grained. There are a number of strategies for making this more efficient, e.g., caching frequently used data locally in a facade object. Unfortunately, we don't have quite the facility for service design that I think we should have because of the lack of a multi-threaded client ( see http://www.oehive.org/MultiThread ).

Is there a good description for coarse-grained ?

My general, sort of layman, impression is that the application is fragmented into independent as possible services. Where as with components you could combine as many as needed, with a service the service consumer would ideally use a single call to satisfy a request.

In regards to caching, do you not think that the caching done at the database level (buffer pool/-B) is a good, simple effective solution ? Of course caching done at the database level isn't the same as the logical view end result, sort of speak, but there's no added management, complexities etc. involved.

For the second question, a business entity is not a service, it is a component. An order service might request a customer object from the accounts receivable service, for example.

For a very interesting view of how to look at OERA, I recommend downloading the new AutoEdge reference application from PSDN. It and the associated whitepapers should give you a start, even if I don't agree with a lot of the specific details ... especially since I want to do it using objects!

Again, my unprofessional impression, is that a service whether an object or simulating an object is a bunch of related operations. If it's all the operations associated with cars or something more complex. In the OERI and AutoEdge aren't clients or service consumers making calls to Business Entites ? doesn't that make them services ?

Lastly, is there a book or sort of a bible on SOA, you could recommend ?


Thanks in advance.

Sorry, I have to go now, I'll be back

 

[tamhas]

Is there a good description for coarse-grained ?

The opposite of fine-grained? Seriously, though, neither is an absolute, but is instead an indicator of a direction. An example of fine-grained is requesting the name of a customer; an example of coarse-grained is requesting a customer object.

My general, sort of layman, impression is that the application is fragmented into independent as possible services. Where as with components you could combine as many as needed, with a service the service consumer would ideally use a single call to satisfy a request.

Services don't imply a lack of components or objects, quite the contrary; services are made up of components. A service is merely a coherent chunk of functionality which can be accessed via a known API. It isn't that one would only contact it once, but rather that one tends to hand it or request from it meaningful whole increments of work. Ideally, one wants a service to be stateless so that it can be replicated, so it needs to be able to have all of the information necessary to complete its work in a single message.

In regards to caching, do you not think that the caching done at the database level (buffer pool/-B) is a good, simple effective solution ? Of course caching done at the database level isn't the same as the logical view end result, sort of speak, but there's no added management, complexities etc. involved.

If all one were caching were database buffers, then -B is going to do the job better than we can, but that isn't the whole story. One may have a reason to cache business entity objects, for example, because considerable effort may go into marshalling that object, e.g., one might access a dozen tables in building an Order object. So, that object should stick around long enough that we are likely to be done with it. One can also cache because the source of the object is not local. E.g., the source of a Customer object might be on a different machine than the Order service, so the Order service might cache Customer objects for some period to minimize the number of calls required. One can also cache collections, e.g., a copy of the entire table of state or province codes would get cached in a service that needed that table and the database containing those codes might not be on the machine using the collection.

If it's all the operations associated with cars or something more complex. In the OERI and AutoEdge aren't clients or service consumers making calls to Business Entites ? doesn't that make them services ?

You shouldn't be thinking of services in terms of business entities, but rather in terms of some operation. I.e., there is an inventory management service, not an item service.

You also might want to check out the distinction between layers and tiers on this thread http://www.psdn.com/library/thread.jspa?threadID=2564&tstart=0

Lastly, is there a book or sort of a bible on SOA, you could recommend ?

Not limited to SOA, but rather focusing on ESB, I highly recommend Dave Chappell's book, Enterprise Service Bus from O'Reilly.

 

[joey.jeremiah]

Thanks for that,

I've been meaning to read Dave Chappell's book, also because he's one of us, well, at least in the family.

I know his book covers ESB, it's in title but does it also go into detail about SOA architecture ?

 

[tamhas]

I know his book covers ESB, it's in title but does it also go into detail about SOA architecture ?

I suppose that is a little hard for me to answer since I have been thinking in terms of services and buses since about 1995. So, probably there is a better book focusing on SOA itself, but I don't know what it is.

 

[tamhas]

One source might be a couple new papers by John Sadd on SOA which you will find here http://www.psdn.com/library/kbcategory.jspa?categoryID=54

I haven't read them yet, so I can't speak to how wonderful they are.