hi *,
is there a special component for webservice mediation in JCAPS.
we would like to prevent direct point to point WS integration and therefore maybe establish a mediation layer which handles routing and transformation and access management to our webservices.
i only know eInsight wichis more an orchestration tool but a mediation tool.
regards chris
No, not really. It sounds like you want to create some sort of content based router - a message comes in to the router, the router checks the header and forwards it to the appropriate service. Easy enough to do in Java CAPS, but it doesn't come out of the box.. It does have it's drawbacks if performance, scalability and security are issues.
If you have plenty of WS requests, it needs to be able to handle it. The router will act as a funnel - and a performance bottleneck at the same time. This is not really a problem if you deploy it to mutliple web servers and have some sort of load balancer in front of it. This will deal with both performance and scalability if they're issues.
In terms of how you implement it, you could create a service chain in eInsight which does this. For example, create a service to provide access management. After this service has completed, the authenticated message should be placed on a topic. Multiple consumers can be created, each one receiving a different "type" of message (thus your router). The message can then be transformed by another service and then sent to its intended destination service.
Performance would be the biggest issue here if you have a lot of requests so mutiple deployments of this application may be required.
If the message channel between the client and the ultimate destination service needs to be encrypted, then the mediator will cause this obvious problems. You will need to do something like WS-Security and XML Encryption. But only if you need that.
You will also need to use document-style web services as well unless the payload of all of your web services is the same structure.
hi steven,
content based router is not the only thing i want to get out of a ws mediation service.
features that i wish to see is:
1) content based routing
really important when dislocation takes place (e.g. ws of one type is deployed on 100> sites)
2) QOS
really important when you have to distinguish between e.g. gold silver and platinum customers
3) logging / debugging
a mediation service is always capable for turning on additional logging / deb ugging based on sender / receiver and or content and or type of ws call
4) mediation is also good for transforming e.g. REST -> SOAP or other way round
5) mediation can also transform requests (eai like) one format to another
6) add throtteling when requests are routed from dmz to production
7) add ws security when routing out from production into dmz / www
@funnel
of course you have to consider to design this as "really" scaleable LB is a must for such a central component
@service chain
what could be the throughput of such a service chain?
@document style webservices i didnt get that point what do you mean by this?
maybe i am too unskilled in case of ws in large deployments is this a setup which can lead out of the SOA anti pattern which is really common to use ws just point to point and so creating a mass of dependencies and unmanageability
regards chris
Hi Chris
Yeah, I saw that it wasn't only content-based routing that you were after in your mediation service. The routing part was the crux of what I thought you were after. The services which do the other stuff are important, but I didn't think that was what you were concerned about. In answer to your questions / comments below though, here goes:
1) Yes, content based routing is important. I would see this as a JMS Topic, with services at the other end receiving specific messages.
2) Agreed, and your router can help you out with this. Or, you can physically separate your systems by this. eg: you could have a mediation service for platinum customers, another for gold, another for silver and so on. You could provide the platinum customers with redundant and performance oriented infrastructure and so on. Or, if you wanted to use the same physical hardware, you could give each consuming service from the JMS Topic in your router a different priority and tune those consumers. There are a few ways you can do this, so don't take my ideas here as the only ones.
3) I would see that the logging / debugging is a service in your service chain.
4) Yeah, good point. You could have common transformation services as part of your service chain again. So, your common ones occur in your mediation service, and your message specific transformations occur in each message specific service.
5) Agreed once again. However, this sort of transformation sounds like its message specific, so the mediation service probably wouldn't be the best place for this.
6) Hardware appliance for this?
7) Perfect. Adding WS-Security headers would just be another service in your service chain.
@service chain
Throughput - this is hard to quantify when you have zero figures. Of course this is going to add overhead to your mediation service, but it's going to add immense flexibility. If performance is a massive issue, then a mediation service may not be applicable. It's a case-by-case thing really. A service chain is the same concept as an ESB.
@document style web services
Your mediation service needs to provide some sort of interface to the rest of the world. If you use RPC style web services, the number of interfaces you have will be the same number of mediation service interfaces you'll need. With document-style web services, a single interface is used.
I don't know if you're unskilled in large deployments, but at least you're giving it a go and trying to do the right sort of thing.
Everything is a trade-off. You trade off good application design and flexibility for performance. So, if you've got 95% of your web services which need to perform OK, then your mediation service is perfect. For the other 5% that need to perform extremely highly, then point-to-point web services is probably more applicable for this.
Not everything fits in to the same box. Common sense should prevail in all cases and one way of doing things is not necessarily better than the other, it's probably just more applicable in certain circumstances.