Should one be creating new webservices at a webMethods layer instead of using some J2EE app server? in an enterprise a number of business components could be written as resusable web services, should they exist in webMethods? esp written in a proprietary flow language? Is the enterprise tied to webMethods ?
I think webMethods should rather be used to orchestrating different webservice components created across the enterprise and also for governance
I bet this question has come up before, let me know your thoughts
doesn’t matter that’s the whole point of web services. All your interface interactions are at a abstract standard layer. Implement them where ever you like because that is hidden or should be to all of your calling applications. I don’t really believe in vendor lock in. Switching out J2EE application servers is not an easy task and most fail pretty bad at it. All vendors tout standards but folks rarely can implement without taking advantage of some of the vendor goodies.
I would spend a lot of time at the interface definition layer and not worry so much about the actual underlying implementation technology. My two cents.
Well it becomes an issue to consider especially when the web service has to aggregate data from different systems and provide a aggregated response.
And people say integration platform like webMethods is good for aggregation because of its mapping, transformation capabilities.
The more I think about it, mapping can be very easily done using boarder industry standard such as XSLT
Anyway, i am planning on using webM just as an ESB to sit infront of a service built on J2EE standard, I really dont like the way WSDL is consumed in webMethods and use a service coordinator pattern to aggregate data from disparate systems, however use webMethod if I need some adapater capability when connecting to disparate systems.
Not even a contest with webMethods IS. Flow is designed ground up for mapping and is an extremely fast and productive environment for doing that.
.
Sounds like you are thinking from an RPC world, try thinking from a messaging world. Data aggregation becomes just message building with each service just doing their thing without knowledge of the other services and yes the webMethods platform of products does this very well. But a J2EE based system could do it as well. I threw J2EE out for you because it sounded like you like to do things harder than they need to be.
IMHO good architecture and good systems are simple and easy to maintain/support. The webMethods platform is a very good host of all kinds of Web Services. It is simple and highly productive to develop in. I’ve done both J2EE and webMethods IS and there really isn’t any comparison when it comes to developer productivity and maintainability.
I have found that developers as well as architects that come from either a hardcore J2EE or .Net background have a very difficult time with the concept of webMethods. It requires a different way of thinking about constructing applications.
That being said there is no reason why you can’t segment your Web Services as you have suggested. There is no right answer. I haven’t found a compeling reason to have a J2EE application server but you might and that’s okay. That’s the great thing about the concept of services.
