racingcow

Hello,

I am new to SOA, and I have a couple of questions that perhaps someone can help me with.

Let's say I have defined three course-grained "components" (not sure if "component" is the correct terminology here) in my SOA system, called "Component1", "Component2", and "Component3". The three components each need to use a "Customer" object that would represent the same thing in each system, but might have varying properties from component to component. The components are all being built from scratch initially, but SOA is being used in anticipation that one or more of the components will perhaps be replaced later on by other vendors that have existing components that they would rather use in place of our components.

If all three loosely coupled components need to use the "Customer" object...

1.) Where should/can the customer data reside Would each component contain its own repository that stores a repository, or would one component somehow "control" the Customer object

2.) If each component contains its own copy of a Customer object in three separate data repositories, and something like an update operation occurs in one of the components, how would the overall SOA system handle the synchronization of that data between the other two components

Let me know if you need me to clarify anything or need more information from me.

-David



Re: Architecture General SOA Noob Question

Cristerpher

I would think that anytime you have a construct that is used by multiple consumers (your 3 components) that the construct should then be encapsulated... In other words, make Customer it's own component or service, which your 3 components then become consumers of.

If your components are all in the same process, you can use inheritence to describe the data specific to the components and put all of the common functionality in the base.

If you need to expose Customer through web serivces, you can simply use a different web services for each component type that will be using the customer (which can also inherit from a base web service class).

Customer should manage its own persistence independent of the consuming components.

What do you think

Cris





Re: Architecture General SOA Noob Question

racingcow

Thanks for your help, Cris.

So if my three components were "Bank", "Merchant", and "Warehouse", then there would be a 4th "component" with its own web services and repository called "Customer" that the they would consume. So Bank, Merchant, and Warehouse could all make the Customer.Update() web service API to modify the Customer in its repository.

What would happen, then, if I write the system, and a year or so passes and someone replaces my Warehouse component with an existing component from a third-party vendor called "NewWarehouse" that already has its own internal "NewCustomer" object that differs from my Customer object Would I have to write a shim layer or something on top of their existing component that would update the Customer object every time the internal NewCustomer object is updated

-David





Re: Architecture General SOA Noob Question

Cristerpher

The short answer is yes. You'll have to do some integration to get them to work together without knowing about each other.

You would have to have some kind of layer that transforms their Customer type into your Customer type and back. There are different ways of doing this, but it depends on how the third party component was designed itself.

I've seen some clean integrations where overriding or wrapping a class was all that was needed. It is especially nice if they have defined an interface for their objects like ICustomer.

Then I've seen some integrations where the third-party component is so tightly coupled the only way to get at the object when it was in consistent state was to monitor the database for changes and pull that data to create your new object. Hack. You didn't hear this from me.

Cris Zamora





Re: Architecture General SOA Noob Question

racingcow

Okay. Thanks again for your help, Cris.




Re: Architecture General SOA Noob Question

rand007

So in the case of the NewWareshouse application the data for the customer would actually reside in multipe data stores Is there a best practice way to normalize that data or is it something that will be custom written on a case by case basis





Re: Architecture General SOA Noob Question

LivetoCodeCodetoLive!

racingcow wrote:

Thanks for your help, Cris.

So if my three components were "Bank", "Merchant", and "Warehouse", then there would be a 4th "component" with its own web services and repository called "Customer" that the they would consume. So Bank, Merchant, and Warehouse could all make the Customer.Update() web service API to modify the Customer in its repository.

What would happen, then, if I write the system, and a year or so passes and someone replaces my Warehouse component with an existing component from a third-party vendor called "NewWarehouse" that already has its own internal "NewCustomer" object that differs from my Customer object Would I have to write a shim layer or something on top of their existing component that would update the Customer object every time the internal NewCustomer object is updated

-David

I have a few comments here:

1. You should decouple your data objects from your business logic, so there should be nothing like Customer.Update, rather it should be CustomerService.CreateAccount() or CustomerService.ChangeCustomerAddress.

What you would be doing with the Customer.Update is exposing the CRUDy anti-pattern of SOA.

A great resource on that would be this webcast by Ron Jacobs.

2. It would be ideal if there was one centralized factory for your business objects, basically a service where you retrieve all your business object interfaces, and this factory talks to the other systems and maps them to your business objects. That way you will only need to change the logic in one place.

3. I agree with the idea that you have interfaces of all your objects like ICustomer, so that way you just process objects of type ICustomer and do your mapping in the centralized Object factory.

I hope this was helpful.






Re: Architecture General SOA Noob Question

racingcow

Thanks LivetoCodeCodetoLive!. Those were all helpful comments.

  1. I had watched Ron Jacobs webcast when I wrote that, but I guess it didn't sink in very well. :-) I still had my mind in the CRUD world. One thing that did confuse me on Ron's Patterns and AntiPatterns video, however, was that he described CRUD as an AntiPattern, but then showed the following code on one of his "Create the Contract" slides...

    Code Snippet

    public response UpdateCustomer(request)
    {
    // Note message type names omitted
    }

    This seemed like he was using a CRUDy method as one of his examples.

    • Are there good examples or papers that you would recommend to me that shows an SOA object data factory like the one you described Or maybe some other good web material or books that you know of for a beginner to SOA





    Re: Architecture General SOA Noob Question

    LivetoCodeCodetoLive!

    1. I heard teh audio on that one, but that was obviously a mistake n Ron's side.

    2. As for books and material on the object factory

    here us a great one:

    http://en.csharp-online.net/index.php title=Design_Pattern_Framework_2.0%2C_Data_%26_Object_Factory

    and on the same site, an explanation of teh factory pattern:

    http://www.dofactory.com/Patterns/PatternFactory.aspx

    Also, a very promising new technology worth looking at from the ADO.NET team:

    http://astoria.mslivelabs.com






    Re: Architecture General SOA Noob Question

    racingcow

    Thanks again for your help. I will check out those resources.