Hi,
I am looking at developing a simple web app using DSP for browsing EDI files(non-WM platform used for EDI translation) archived on Unix box.
I hadn’t used DSP earlier and I want to wet my HANDS with it. This being a non-critical application thought I could use the oppurtunity to play with something new. Moreover, this is a simple application of three simple screens accepting user input and displaying data, so portal is not being considered here. At this time we don’t have any apps developed on portal.
I have to go thru my architecture review and the Q that would be asked would be : why not JSP since WM 6.5 platform supports it? The above excuse of using it for my pleasure is something certainly I can’t provide to the commitee.
Your thoughts on the pros/cons of DSP/JSP for a new web app development on IS platform would help me a lot in the review process.
Thanks,
AK
If you already have JSP skills in house, I would go that way as DSP is proprietary to WM. The webMethods JSP taglibs only run in the “cradled” Tomcat instance hosted on an Integration Server so in both cases your web-UI is limited to IS.
Obviously, for any serious UI, you should either use Portal or some other presentation layer.
If you are only interested in a simple, limited-scope UI for Integration configuration or support, I would consider IS-hosted JSP or perhaps DSP where the deciding factor would be existing in-house skill sets.
DSP will eventually be deprecated although it may take another full release or two to come to pass.
DSP have only a few tags - and its limitation appears quickly, and I’m guessing, You don’t want to write additional flow services to overcome this limitations. DSP is good for some simple transformation of output XML, when integration is done using REST approach.
JSP is very good approach for something not trivial.
I must use GWT and SOA approach for myself for a try - it will be the best approach I think.
Yes, I have tried it, but in effect of not having enough time, to gather some practical knowledge, pros and cons only.
GWT is AJAX approach, what means: GWT application is web browser logic (of UI functionality) centric - JavaScript code generated by GWT compiler is the application itself, and need nothing more from server than services (some serializated objects, XML or JSON to communicate with) - what means SOA - and technology ideal to use with webMethods IS.
GWT + Struts 2 ? I think, it haven’t a chance to work in form other than: “only MVC from Struts and interactive pages from GWT”.
Struct 1 was a server UI-logic and rendering approach with page reloading. GWT not like page reloading - page is a application of part of application and may holding a context of application. With GWT, web application may consist of single (only one !) big and interactive page.
Well, I’m currently trying to integrate both and am doing good progress…
On the client side there is GWT, on the server side struts2 + struts2gwt plugin for action processing abstracts GWT rpc service invocation. Server side is also using spring+JPA+hibernate, which makes it a little more difficult to pass domain objects to gwt (because of annotations and stuff), so I’ll have to use DTOs instead. Right now that’s the only down side I see…
tks