[andre1001]

Opssss, correcting the last one...

We'll work on tools to isolate you from the message to a degree, but if those tools start supporting the exposure of individual objects on to the bus (like java2wsdl does for Web Services), then we're breaking loose coupling and moving away from SOA.

Hi Mark,

Imagine this architeture:

.Net client -> WS -> ESB -> Session Facades -> POJOS

Do you mean it would be wrong if I was exposing on WS tier the same Pojos (generated by java2wsdl) that I use on my Session Facades!?

Thanks.

[burrsutter]

I'll let Mark deal with the what is "right" vs "wrong".

But here is my 2 cents.

.Net client -> WS -> ESB -> Session Facades -> POJOS

Will work

so will

.Net client -> ESB-> WS -> ESB -> Session Facades -> POJOS

and several other combinations of these technologies. Session facades are not required. WS is mostly important because there is a .NET client here otherwise it is not required. In the future, we hope to have alternatives to WS for .NET clients.

The secret sauce, IMHO, is think with messages, not method parameters and return values.

[andre1001]

Hi Burr,

I would like to come back to some questions in your post...

But, by now, what would be the best?

1) .Net client (someDomainObjtStub generated with java2wsdl) -> WS -> ESB -> Session Facades -> POJOS (sameDomainObj)

2) .Net client (string1, string2, .... or string []) -> WS -> ESB -> Session Facades -> POJOS (DomainObj)

[burrsutter]

Finding what is "best" is always a challenge. :-)

From the 2 approaches presented, I would choose option 1 because it is dramatically easier to implement and would allow me to get my project/product deployed that much faster. The easiest way to work with a .NET client is through WSDL/SOAP.

However, I believe there is a better approach that I've not yet had the time research and prototype it.

Consider these possible future requirements:
- AJAX clients (JSON, instead of XML)
- Swing or RCP clients (use of the actual domain objects)
- Flash clients (similar to a .NET client using WSDL)
- an external system interacting with the same service in both a sync and async manner
- changing of the service while in production, live 24 x 7

[andre1001]

"burrsutter" wrote:

From the 2 approaches presented, I would choose option 1 because it is dramatically easier to implement and would allow me to get my project/product deployed that much faster. The easiest way to work with a .NET client is through WSDL/SOAP.

We've choose 1 either, but I'm afraid we are coupling Domain Objects with Web Services and his clients.

1) If I change some attribute on my Domain Objects I would have to regenerate his stub an ask my clients to use it. Domain objects are designed to change. Interfaces can't follow the same principle.

2) I MUST code my Domain Objects with public getters and setters for all attributes in order to generate his stubs clients. This allows clients create Domain Objects with invalid state.

What is easy now, can be turned difficult a few time ahead.

[burrsutter]

I agree. If you believe the domain objects are likely to change often. And if you think you'll have hundreds or thousands of clients to update with the newly generated stubs then you might be better off with a single string of XML between the .NET client and the server-side component that is sent in via HTTP POST. Very loosely coupled and message oriented and very, very flexible.

[marklittle]

Sorry, I missed the updates to this thread. I agree with what Burr has been saying: keep the coupling loose; think in terms of services and messages and don't expose your backend implementation choices (POJOs etc.) If you do that then you'll end up with tighly coupled applications. In the early days of CORBA, people were exposing individual objects through IDL "because you can", which wasn't very smart. It took a few years for most users to realise you could develop services (coarse grained components) and expose those as IDL, hiding the individual objects from the client. Think of your service as a demultiplexor as much as you can. That way, if you decide to change how you implement your service (at the backend), you won't have to change the clients as long as the contract between client and service remains identical. There should be a close relationship between the contract and the messages/MEPs.

[andre1001]

Thanks for your comments.

Now we can go ahead.

"burrsutter" wrote:
Session facades are not required.

Aren't Facades still useful for:

1) transaction control?
2) POJOs coordination?
3) build POJOS without data access code?

But, I'm still wondering if this patterns are valid with ESBs. I'm wondering, for example, if ESB shouldn't control components dependencies. In Java EE model components dependencies should stay in Facades.