| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMB/IIB as facade "server" - is itgood architectur |
« View previous topic :: View next topic » |
| Author |
Message
|
| ruimadaleno |
 Posted: Thu Jun 18, 2015 3:55 am Post subject: WMB/IIB as facade "server" - is itgood architectur |
 |
|
Master
Joined: 08 May 2014
Posts: 274
|
Hi all,
our it environment is composed by 4 domains (you might heard of it silos ...  ). Each one of these domains uses a certain technology to develop and deliver applications and web services. Let's focus on web services.
So, we have:
Domain A - web services built on asp, asp.net , several .net framework versions
Domain B - web services built on outsystes technology Outsystems
Domain C - web services built on java
Domain D - web services built on WMB/IIB
IT strategy is to build an Service Oriented environment (something like SOA). I was asked to evaluate the following scenario:
WMB/IIB should play the ESB role in our architecture, so, each service from domains A,B, and C should have a "Broker Representation" - for every service in domains A, B and C a wrapper/proxy service should be built and deployed in WMB to act as a façade to the "real" service in the Domain. These "facade services" should be available in service catalog (WSRR) to be consumed by business/applications.
From an architectural viewpoint is this a good approach ? what are the Pros/cons on this approach ? any best practices ?
Cons
-----
Single Point of failure: if broker goes down every attempt to consume a service from domain A,B and C will fail
for every service provide by domain A,B and C , a service must be built in WMB. These service can get more complicated (high development time) as the "real" service gets more complicated (example: a service with high number of input data and no documention)
Pros
-----
Reusability - in the sense that, right now, services from domains A, B and C are not published in the service catalog (remenber, each domain is an it silo). Publish the service in a catalog can lead to more reusability
Standardization - every message (xml) sent to "facace service" is formatted accordingly to the standard (we have a standard message structure, following the ideia of canonical message in ESB)
Monitoring - Right now Domains A,B and C provide no info (metrics) about service usage/performance nor log info. With record and replay we can keep logging info and gather statistics (with both monitoring info and resource/message flows statistics)
We can build "façade services" that use queues for high volume/long running jobs, providiing faster responses to clients.
_________________
Best regards
Rui Madaleno
Last edited by ruimadaleno on Fri Jun 19, 2015 2:05 am; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Jun 18, 2015 5:55 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
This has been one of IBM's standard strategies and implementation approaches for IIB for a long time.
You might consider ways to simplify and consolidate the facade interface, to reduce the complexity with the backend web services.
But that's only possible if the data itself can be simplified.
And it would potentially require a separate or modified contract with the back end. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Thu Jun 18, 2015 7:58 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| mqjeff wrote: |
This has been one of IBM's standard strategies and implementation approaches for IIB for a long time.
You might consider ways to simplify and consolidate the facade interface, to reduce the complexity with the backend web services.
But that's only possible if the data itself can be simplified.
And it would potentially require a separate or modified contract with the back end. |
Hi mqjeff, thank you for your answer.
Have you been exposed to an it environment where the above scenario was implemented ? what are the challenges and pitfalls ? are you aware of some case studies/documentation (maybe developer works article) that focus on this scenario ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Jun 18, 2015 8:39 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
I've spent time helping people build this.
The only challenges and pitfalls I've ever run into were people issues, not technology issues. Two architects can't ever agree on the same approach or the same technology or the same anything. And two business owners don't ever want the other one to succeed.
Get a senior VP to attend every meeting and point a finger at the winner each time. And then don't let him (if it's actually a her - GOOD ON YOU, MATE) take meetings with individuals.
I know of at least one customer I helped in a past life that had an implementation of this that ran - without maintenance- for six or eight years and was the only part of their infrastructure that didn't experience significant outages. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Jun 19, 2015 3:59 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| mqjeff wrote: |
I've spent time helping people build this.
The only challenges and pitfalls I've ever run into were people issues, not technology issues. Two architects can't ever agree on the same approach or the same technology or the same anything. And two business owners don't ever want the other one to succeed.
Get a senior VP to attend every meeting and point a finger at the winner each time. And then don't let him (if it's actually a her - GOOD ON YOU, MATE) take meetings with individuals.
I know of at least one customer I helped in a past life that had an implementation of this that ran - without maintenance- for six or eight years and was the only part of their infrastructure that didn't experience significant outages. |
Hi mqjeff, thank you for your valuable tips.
I believe this challenge is 80% people "management" and 20% technology. As for people, in this scenario we will have the sponsorship from CIO, so every IT team/silo will be aligned with this strategy, we will need to find sponsorship from management/business to align the distinct business units.
as for the 20% share of technology i think the challenge might be the different data formats (mainly xml schemas) of xml consumed and returned by backend services. We will try to evaluate if a data format consolidation is possible or if the façade services will use the same data formats delivered by backend services.
We don't want to just build a façade service that acts as "router", the goal is to enrich the message, providing some value, and we will try to apply the soa service xml format standard in place.
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
