| Author |
Message
|
| mqjeff |
 Posted: Mon Feb 08, 2016 7:24 am Post subject: |
 |
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| inMo wrote: |
| mqjeff wrote: |
| ...the point of what you're calling the first layer was to provide a mechanism for applications that couldn't, or wouldn't, upgrade to using the common API. |
I agree. It is really the only point to the stated first layer - especially when noting the 2nd layer is the common layer. It would almost be better to have the common layer be the primary layer, and consider your 1st layer a helper type layer for those apps desperately needing help to communicate with the primary common layer. |
Exactly.
And as always, one needs to put lots of continual pressure "legacy" applications to either upgrade or retire asap.
Or at least make them take over the maintenance of their part of the adapter layer.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
 |
| ruimadaleno |
| Posted: Thu Feb 11, 2016 4:34 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
I've made some drawings for you scenario (love to scratch paper  )
From my understanding the 1st layer (Proxy) is made of services that just transform the payload and protocol clients are using to your internal/Common
data representation and protocol. Example: client A using MQ + business data with schema A -> your proxy service simply get the payload from a message in
a queue, transform for internal/common representation and "forward" it to the "second layer service"
The second layer is made of services that compose/orchestrate the business data within your internal/backend systems. Example: to update/create customer
address information you might need to "talk" to AS400 , a sqlserver DB and a REST Service. This conversations are implemented in a lower layer
The third layer is just made of something like Data Acces Objects oriented to business entity. Example: you would create a service responsible for operating
the Customer Business Entity. This service would have to deal with all backend systems that are "interested" in customer changes (CRUD)
Three Layer versus two layers:
Are the proxy service really needed ? can you agree with your customers a comunication protocol - SOAP ? can you agree with you customer a business data structure ?
how many of your clients are "flexible" to use SOAP + your internal/common data representation ?
If you have a lot of "Flexible" clients you would go to the Two Layer solution and implement some Three Layer Service for "not so flexible" customers.
Questions you have to answer to yoursel: how many clients ? would you build one proxy service for each client ? are you building one proxy service
for each client that uses a certain protocol ? how many services are you able to maintain (deploy, operate, monitoring, versioning,etc) ? do you have the
resources to handle this potential services "spread" (servers, bandwidth, RAM, execution groups, etc)
Another point: how many business functions are you planning to offer to your client ? what about service granularity ? I see a business function as a set of activities
that need to be executed and are bounded to a set of rules. So, in this architecture, for every business function you should provide a "reusable layer service".
Maybe you can provide a "fat" "reusable layer service" - coarse grained (one service, several operations, each operation provides a business function, business functions are somehow related).
How many clients will use this "reusable layer services". If you have N clients, with distinct protocols + payload you will need N + 1 + M services (N proxy services +
1 reusable service + M target layer services)
Using the three service layer you might end up with a heavy "web service call cascade".
Client --> Proxy service --> second layer service ---> (maybe several) third layer service
This is a lot of http calls and in some business this latency is not usable. Do you need to support "important"/"critical" clients ? are the client/business willing to wait seconds to get the info ? you must provide syncronous web services calls ?
Just some cents 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Thu Feb 11, 2016 10:30 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Quote: |
Using the three service layer you might end up with a heavy "web service call cascade".
|
Yes Yes YES 
And for us, it ran like a two legged dog with the remaining legs tied together.
We compromised (cue much g n a s h i n g of the teeth from the SOA purists) and made it a two layer with all the 3rd layer implmenented as subflows.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Fri Feb 12, 2016 9:01 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| smdavies99 wrote: |
We compromised (cue much g n a s h i n g of the teeth from the SOA purists) and made it a two layer with all the 3rd layer implmenented as subflows. |
Can you provide us more details on this implementation ? i'd like to learn from you experience what benefits you have reached.
When you mention "two layer" do you mean "two services/applications" ?
Do you reuse the second layer and third layer subflows across all first layer services ? how have you implemented comunication between 1st layer and 2nd + 3rd layer ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Fri Feb 12, 2016 11:29 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| ruimadaleno wrote: |
| smdavies99 wrote: |
We compromised (cue much g n a s h i n g of the teeth from the SOA purists) and made it a two layer with all the 3rd layer implmenented as subflows. |
Can you provide us more details on this implementation ? i'd like to learn from you experience what benefits you have reached.
When you mention "two layer" do you mean "two services/applications" ?
Do you reuse the second layer and third layer subflows across all first layer services ? how have you implemented comunication between 1st layer and 2nd + 3rd layer ? |
The three layer model used:-
1) Business Services
2) Composite Services
3) Technical Services
The compromise merged the Composite and Technical services.
The technical ones were things like SAP Input or Output, DB Get, put or update
For resuse these were implemented as sublows and the inputs/output documented.
The interface between the Business Service and the Composite service was originally SOAP. IN have everything in the original 3-layer was done via SOAP.
This is dog slow and not transactional. It is also sycnhronous.
We moved to using MQ for many servivces. We did use a request/reply model but we could do things in parallel. This meant that a business service that needed to merge data from a number of sources could implement an agregation model rather than using the SOAP synchronous model.
Can't say much more than that,
If I were you, I'd look at doing some perfomance modelling just to see how many messages/sec you can get out of your config. Then look at ways to speed things up.
as they say, YMMV
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Mon Feb 15, 2016 1:29 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
The big question here (only p939276 can aswer it ) is the requeriment for sync/async communication.
If the clients need to make requests to services and wait to get a response (synchronously) can we implement the two layer approach with MQ ?
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 15, 2016 5:52 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ruimadaleno wrote: |
The big question here (only p939276 can aswer it ) is the requeriment for sync/async communication.
If the clients need to make requests to services and wait to get a response (synchronously) can we implement the two layer approach with MQ ? |
Yes.
You just have to account for timeouts.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Mon Feb 15, 2016 8:23 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| mqjeff wrote: |
Yes.
You just have to account for timeouts. |
Very interesting ! replacing the http/soap communication between web services and use MQ.
Are there any case studies/examples on this aproach ? I really what to build some knowledge on this subject ? Any performance studies/comparision between the usage of MQ vs the usage of http/soap
Best Regards
Rui Madaleno
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 15, 2016 8:55 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Think SOAP over JMS!
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Mon Feb 15, 2016 10:10 am Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| fjb_saper wrote: |
| Think SOAP over JMS! |
Or
SOAP over MQ.After all a Soap message is just the sort of thing that MQ can handle in its sleep.
MQ is data content format agnostic.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 15, 2016 11:09 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| smdavies99 wrote: |
| fjb_saper wrote: |
| Think SOAP over JMS! |
Or
SOAP over MQ.After all a Soap message is just the sort of thing that MQ can handle in its sleep.
MQ is data content format agnostic. |
Never said that MQ couldn't handle the transport...
However the SOAP nodes will handle SOAP over JMS, but there is no SOAP parser for the MQ nodes. With SOAP over JMS, you have a broader view and the JMS provider is not restricted to MQ... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 15, 2016 11:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You can't use configuration to process the WS-Security and stuff in other WS-* headers using a plain MQInput node.
Whether you need those or not is a different question.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| ruimadaleno |
| Posted: Wed Feb 17, 2016 6:50 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
| smdavies99 wrote: |
SOAP over MQ.After all a Soap message is just the sort of thing that MQ can handle in its sleep.
MQ is data content format agnostic.
|
One challenge here is how to keep the context.
---> compute node A --> soap request ---> compute node B
in the above flow , in compute node A (or before) we can throw context information in environment/localenvironment trees (id's , correlation and other additional info). This context info is then used in compute node B (or after) to process the message.
If we change to a MQ "model" we loose context 
---> compute node A --> mqOutput ---> compute node B
Of course we can keep this context in a RFH2 header, but this will consume development time and maybe bring some limitations (what is the size of the info we can keep in a RFH2 header??)
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 17, 2016 6:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| ruimadaleno wrote: |
| If we change to a MQ "model" we loose context |
... why?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
|
|
