Canonical Schema

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Canonical Schema

starborough
This post has NOT been accepted by the mailing list yet.
Historically, I have found that ESB integration design problems are much improved through the introduction of a canonical schema. So far I haven't seen this topic here, or its inclusion in the development tools.
Are canonical schemas supported?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Canonical Schema

Paul Perez
Administrator
Hello starborough

First I would like to thank you for your interest in OpenESB.  The canonical schema is a famous pattern that is used to make easier the communication between application.
A canonical schema is just a common Schema that is defined as canonical and nothing more. So you can define a simple schema and define it as canonical. So OpenESB is perfectly accurate to implement canonical Schemas.
Nevertheless, as integration architect, I would like to warn you against the canonical schema which behave  a bit like the inheritance. If at the first glance, it makes the life easier, but very quickly, it becomes a strong constraint when you have to modify it after a while.
Few years ago, I worked for an European airline where they defined the customer, the plane, the flight ... as canonical schemas. The airline applications relied on them to simplify their business model but every 6 months the legislation changed and the canonical schemas had to be redesigned. This had a strong impact on the maintenance cost and time to market.
Yes OpenESB support canonical schema but also schema extension, specialisation and all the main features defined in XSD Specifications.

Feel free to contact me for any further question on OpenESB.

Best Regards

Paul
www.pymma.com The best services on OpenESB
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Canonical Schema

starborough
This post has NOT been accepted by the mailing list yet.

Thank you for your reply,

 

Whilst I appreciate your concerns over canonical schemas, the alternatives seem to provide bleaker outcomes.

Without a canonical schema, the tightly coupled connections that bring about the argument for an ESB have a habit of migrating to the orchestration or choreography layer. Even with really great visual tools, the interconnections soon become apparent.

It seems to me that the choice is between

1.        Close coupled systems outside of an ESB

2.       Close coupled connections inside of an ESB… or

3.       canonical schema management.

 

 

Are there any other options

From: Paul Perez [via OpenESB Community Forum] [mailto:ml-node+[hidden email]]
Sent: 18 March 2016 14:26
To: Rob Wendes <[hidden email]>
Subject: Re: Canonical Schema

 

Hello starborough

First I would like to thank you for your interest in OpenESB.  The canonical schema is a famous pattern that is used to make easier the communication between application.
A canonical schema is just a common Schema that is defined as canonical and nothing more. So you can define a simple schema and define it as canonical. So OpenESB is perfectly accurate to implement canonical Schemas.
Nevertheless, as integration architect, I would like to warn you against the canonical schema which behave  a bit like the inheritance. If at the first glance, it makes the life easier, but very quickly, it becomes a strong constraint when you have to modify it after a while.
Few years ago, I worked for an European airline where they defined the customer, the plane, the flight ... as canonical schemas. The airline applications relied on them to simplify their business model but every 6 months the legislation changed and the canonical schemas had to be redesigned. This had a strong impact on the maintenance cost and time to market.
Yes OpenESB support canonical schema but also schema extension, specialisation and all the main features defined in XSD Specifications.

Feel free to contact me for any further question on OpenESB.

Best Regards

Paul

www.pymma.com The best services on OpenESB

 


If you reply to this email, your message will be added to the discussion below:

http://openesb-community-forum.794670.n2.nabble.com/Canonical-Schema-tp7581225p7581226.html

To unsubscribe from Canonical Schema, click here.
NAML

 

Click here to report this email as spam.



 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Canonical Schema

Paul Perez
Administrator
Hello Starborough

Thank you for your reply. I would like to give you more precision on my first answer.

Whatever the case, the tool the technology you use, interconnection will become apparent sooner or later and we cannot avoid it. Integration is a subtle balance between two ways of thinking: Alone we go faster and together we go further. The main concern in integration is to go further and as fast as possible at the same time.

If you have a deep analysis of why together we go slower, you will notice that communications between partners (which is the key of integration) generates dependencies between partners. With the time, the dependencies crystallise the system, so maintenance and evolution become tricky, expensive and increase your time to market.

Whatever the architecture you use, if you make changes in an integrated system, you will have impact on your partners.

In the past, I worked on a project where a simple addition of a column in the table costed more than 3 million of pounds. For sure, in an integrated system, modifications have impacts and there is no way to avoid it (ESB, not ESB; Canonical schemas are not). If you change completely your integration business process or modify half of your partners, we could expect that the price of this upgrade will be expensive.

Nevertheless, for a small modification, we would like to have a lower price. Since we know that impacts are unavoidable, we would be happy to get a linearity between impact and cost. Small impact generates low cost and large impact, high cost. A good integration system, is a system that provides the best linearity between modification and impact. In OpenESB, this linearity is obtained by adding intermediates between partners. OpenESB uses the contract of service, the bus, the orchestrator as intermediates to decrease the impact of a modification and maintain a linearity between modification and impact.

Let take an example. You talk about canonical schema and OpenESB relies on contract of services such as WSDL. Of course a WSDL document embedded schemas to define the structures of the messages between partners. Theoretically, we can think that using canonical schemas or canonical schemas in WSDLs are the same thinks.

On the ground, there is a fundamental difference due to the understanding of how canonical schemas must be used. My background showed me that business and developers are often using canonical schema as the basis of their application business model. If not, canonical schemas have a great influence on the application business model design. If it is not the objective of the canonical model, it is what happens on the ground. Unfortunately, up today, I did not see other usage of the canonical schema in the project I worked on.

On the other side, the contract of service is used for a different purpose. A contract of service defines the messages the partners will exchange. With the WSDL, the normalisation is on the message exchanged itself and not on the internal structure of the applications. We face exactly the same issue with Java or C# interfaces. Developers define them to share structures between Java applications and use them to structure their internal business model as well.

Certainly your company or your customers are able to make the difference between both uses of the canonical schemas, but my skill demonstrated it is not often the case. It is the reason why I warned you against the canonical schemas.
My point of view is the contract of services are more efficient as to reduce dependencies between partners

OpenESB has other intermediate level such as the orchestrator, the dynamic addressing and the next versions will provide additional intermediate levels to provide linearity between modification and impact. (Not the topic today)

I hope my point of view is more understandable today.

Best Regards

Paul
www.pymma.com The best services on OpenESB
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Canonical Schema

starborough
This post has NOT been accepted by the mailing list yet.

So… in short

It’s not possible to remove highly coupled components, even at a logical level, it’s only possible to provide different ways of managing them in layers of the architecture.

 

From: Paul Perez [via OpenESB Community Forum] [mailto:ml-node+[hidden email]]
Sent: 21 March 2016 10:59
To: Rob Wendes <[hidden email]>
Subject: RE: Canonical Schema

 

Hello Starborough

Thank you for your reply. I would like to give you more precision on my first answer.

Whatever the case, the tool the technology you use, interconnection will become apparent sooner or later and we cannot avoid it. Integration is a subtle balance between two ways of thinking: Alone we go faster and together we go further. The main concern in integration is to go further and as fast as possible at the same time.

If you have a deep analysis of why together we go slower, you will notice that communications between partners (which is the key of integration) generates dependencies between partners. With the time, the dependencies crystallise the system, so maintenance and evolution become tricky, expensive and increase your time to market.

Whatever the architecture you use, if you make changes in an integrated system, you will have impact on your partners.

In the past, I worked on a project where a simple addition of a column in the table costed more than 3 million of pounds. For sure, in an integrated system, modifications have impacts and there is no way to avoid it (ESB, not ESB; Canonical schemas are not). If you change completely your integration business process or modify half of your partners, we could expect that the price of this upgrade will be expensive.

Nevertheless, for a small modification, we would like to have a lower price. Since we know that impacts are unavoidable, we would be happy to get a linearity between impact and cost. Small impact generates low cost and large impact, high cost. A good integration system, is a system that provides the best linearity between modification and impact. In OpenESB, this linearity is obtained by adding intermediates between partners. OpenESB uses the contract of service, the bus, the orchestrator as intermediates to decrease the impact of a modification and maintain a linearity between modification and impact.

Let take an example. You talk about canonical schema and OpenESB relies on contract of services such as WSDL. Of course a WSDL document embedded schemas to define the structures of the messages between partners. Theoretically, we can think that using canonical schemas or canonical schemas in WSDLs are the same thinks.

On the ground, there is a fundamental difference due to the understanding of how canonical schemas must be used. My background showed me that business and developers are often using canonical schema as the basis of their application business model. If not, canonical schemas have a great influence on the application business model design. If it is not the objective of the canonical model, it is what happens on the ground. Unfortunately, up today, I did not see other usage of the canonical schema in the project I worked on.

On the other side, the contract of service is used for a different purpose. A contract of service defines the messages the partners will exchange. With the WSDL, the normalisation is on the message exchanged itself and not on the internal structure of the applications. We face exactly the same issue with Java or C# interfaces. Developers define them to share structures between Java applications and use them to structure their internal business model as well.

Certainly your company or your customers are able to make the difference between both uses of the canonical schemas, but my skill demonstrated it is not often the case. It is the reason why I warned you against the canonical schemas.
My point of view is the contract of services are more efficient as to reduce dependencies between partners

OpenESB has other intermediate level such as the orchestrator, the dynamic addressing and the next versions will provide additional intermediate levels to provide linearity between modification and impact. (Not the topic today)

I hope my point of view is more understandable today.

Best Regards

Paul

www.pymma.com The best services on OpenESB

 


If you reply to this email, your message will be added to the discussion below:

http://openesb-community-forum.794670.n2.nabble.com/Canonical-Schema-tp7581225p7581228.html

To unsubscribe from Canonical Schema, click here.
NAML

 

Click here to report this email as spam.



 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Canonical Schema

Paul Perez
Administrator
In short:
There is no way to remove dependencies between partners involved in the Same business process. But we can improve the linearity between an evolution and a modification  and its impact on the integration system.
OpenESB uses intermediates to do it.

PPe
www.pymma.com The best services on OpenESB
Loading...