| Author |
Message
|
| PankajS |
 Posted: Wed Sep 24, 2014 7:35 am Post subject: What is Best practice regarding number of Ops/IIB Interface |
 |
|
Voyager
Joined: 27 Dec 2004
Posts: 82
|
Hi there,
Quick Background: We are implementing SOA based Integration project and we have BPM8.5 and IIB9 in out product stack.
I have two queries.
1. What should be granularity of a ESB services ? By that I mean, is it a good practice to expose IIB service interface with one (or at max two ) operations or it does not matter ?
My personal experience has been that more the number of operations, more is the complexity of the service and further it is difficult to maintain the service in PRD environment
However, would like to hear from experts on this.
2. What is the best practice to implement the Composite Services. Should that be implemented as BPEL MicroFlow or IIB Service ?
In the reference of out project, there are two categories of the composite services.
i> A service that invokes multiple ESB services
ii> A service that invokes multiple SoRs(System of records)
My view on the issue is that ESB should only host the atomic services and BEPL microflows should be used for composite services. This is based on the experience that the composite services, especially the one that involve sequential and dependent calls get complex to develop as there is no out of box support for this in IIB.
Looking forward to hearing from experts on their experience. |
|
| Back to top |
|
 |
| Dave Ziegler |
| Posted: Wed Sep 24, 2014 12:43 pm Post subject: |
|
|
Centurion
Joined: 15 Apr 2014
Posts: 118
|
|
| Back to top |
|
|
| smdavies99 |
| Posted: Wed Sep 24, 2014 11:00 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
Please bear in mind that going to a two or three tier SOA Architecture will result in a performance degredation to the calling application.
I worked (at a previous employer) where we had a 3-tier arch. It was dog slow.
I implemented on service as a single tier (using subflows from a 3-tire model) and got a FIVE fold increase in throughput. This was on V6.1.0.9 and the hardware was a Sloooooowwwww Solaris System so this may not be representative of more recent versions of Broker/IIB and modern hardware.
The SOA Purists (I have a bookshelf filled with SOA books) seem to insist on SOAP everywhere even internally between the layers of your SOA Architecture. This will slow your system down. We have a perfectly good Interflow solution sitting underneath broker that is called MQ. There is IMHO nothing wrong in sending Request/reply SOAP Formateed messages over MQ (and even using non persistent messaging) . I call this being pragmatic.
There has to be a bit of a trade off between a Pure SOA design and one that works for you and your environment. A decent and representative POC will tell you what is best for your environment.
_________________
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: Thu Sep 25, 2014 1:06 am Post subject: |
|
|
Master
Joined: 08 May 2014
Posts: 274
|
Regarding service granularity there is no golden rule to point you the number of operations each service should deliver.
Avoid extreme scenarios:
- High number of services with a one or two operations
- Low number of services with high number of operations
You should look by the business side, usually avoid services with high number of operations. Eventually create several services, aggregating similary or logical related operations by business requirement.
In theory services with high number of operations will have more consumers => more traffic . Also, a bug in service with high number of operations can bring down several operations causing high impact in business.
Just my two cents 
_________________
Best regards
Rui Madaleno |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Sep 25, 2014 6:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Use MQ whenever possible. There are so many advantages over web services and (God forbid) files.
Transactionality being just one benefit. Using WS you have no transactionality and you have to handle the situation where the other end is not available.
I won't bore you with details - but I spend a lot time solving (other people's) problems in flows that use WS and java and very little time solving problems in flows that use MQ and ESQL.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| PankajS |
| Posted: Thu Sep 25, 2014 10:42 pm Post subject: |
|
|
Voyager
Joined: 27 Dec 2004
Posts: 82
|
Thanks Guys for inputs. This is my outlook on the issues after discussion.
1. Granularity:
All agree that there is no golden rule as such on granularity and it really depends on case to case basis but having less operations is always an advantage. To put down some advantages that I can think off-
1. Less operations are less number of interaction points through one interface so less susceptible to changes so easy to maintain
2. It adds to difficulties in identifying testing scope for services with multiple operations as change in even one operation may trigger the regression test on whole bundle.
3.Impact Analysis: A service with multiple operations will invite wide spread impact analysis each time it changes due to its multiple touch points
2. Composite service and choice of platform.
My view on this is, the product should be used to its strength ! I mean, BPM is design for orchestration so I would prefer to use it if it is in my product stack. (When I am saying this, I am still to answer the question what are tangible benefits of doing so ? If any one has done such study, please do share.)Only exception would be when performance is the key. In such cases I would prefer to go with single layer provided I am not proposing a mammoth to be built on service layer. |
|
| Back to top |
|
|
|
|
