Hi All,

Often ESB (formerly Intergration Server) is projected as the SOA supported product. Well I have used ESB almost everytime whenever there was an integration between systems using adapters/ftp/sftp/file polling/DB polling so on and so forth. When it comes to consuming webservices in ESB, it seriously lacks some of the basics (wm 7.1.2) such as

1. Context name changes are not supported in ESB. Every time a context of a webservice is changed, we have to delete and then re-generate consumers. The port alias setting does not allow us to change context. This is a limitation as in SOA environment the context changes almost every release (versioning) ex [url]http://xx:111/v1.1/xxyService[/url] can change to [url]http://xx:111/v2.0/xxyService[/url]

2. The schema is again a problem. If 2 or more webServices are importing common schemas then the consumer generation in ESB gives heaps of warnings. Sometimes webService consumer documents do not generate some fields if a schema is already present withing ESB. This again is very critical, ESB should support having 2 same schemas in different folders without any warning/error

3. Canonicals (broker documents) again do not support namespaces. Ex: cust:name is not supported as broker documetn field, it has to be cust_name or name. In SOA world, everything is defined using XML schema and if we try to create a document from XML SChema in ESB, it always creates namespaces with “:”

4. The schema documents generated by ESB are always named as “doctypes__”. Well this is acceptable but there should be option to keep the schema name as it is withtout renaming them automatically

5. Schema extensibility points are not properly supported. ESB generated the extensibility points and the “end_of_xx” markers. However the default values defined in the schema are not taken on run-time.

6. MTOM support is still an issue for us. Anyfile more than 20MB erorrs out as ESB uses getFile() for MTOM. Probably what we had faced needs more investigation.

7. MTOM with SOAP 1.1 is not supported in ESB

8. Identity asserter mechanism cannot be used in ESB (passing custom token in http header of a soap call) as soapHttp() does not support altering or adding any tokens in the http header

9. No support for SOAP over JMS

10. ESB generates all operations of an webservice even though the requirement is to use only 1 operation. Does not give any options to generate only those operations which are required.

Regards,
Sumit

IntegrationServer is the ESB ( Enterprise Service Bus), if you talk about SOA you should get in contact with Mediator and CentraSite active SOA. (This is the replacement for X-broker/infravio).

Now inside the ESB you do build the webservices, and some of the limitations you comment are already (thanks god) resolved in wM 8.0.

( [url]http://techcommunity.softwareag.com/ecosystem/documentation/webmethods/wmsuite8_ga/relnotes/8-0_webMethods_Release_Notes.html#_webMethods_ESB/Integration_Server[/url] )

1- Context changes aka input/output parameters of course need to regenerate connectors, else how would you reflect the change?

2- This is resolved in wM 8. “Customizable Namespace Prefixes/Multiple Schema Domains”

3- Why is that an issue? Namespaces always contain “:”

4- Why an issue? That’s anyway IS internals.

5,6,7- Ask for a feature request

8- You have document handlers for HTTP Headers. If you talk about WS-Security yes out of the box is limited but you can build your custom solution.

9- Yes thats true, I think that’s in their roadmap.

10- Why is this an issue? Wizard generates them, if you do not need all operations then delete the ones you don’t need.

Regards

I didn’t think IS alone constituted the ESB. I thought it was a combination of IS and Broker.

Here are some terminology nitpicks:

Canonical != Broker document

Web services != SOA

We could have a long discussion here, as older IS versions could publish locally and not use broker (of course nothing clustered) and etc, however I accept broker is esential part and after version 6.5 a must

Totally true, thats why I pointed to CentraSite active SOA and Mediator

Actually, I’m referring to SAG/wM definition of what they call their ESB. I believe they say their ESB consists of IS and Broker, or at least they used to. It may be that only IS is (and perhaps always) their ESB.

Current IS versions can still publish locally.

Broker is a good part of the suite, but my position for years has been that pub/sub is actually a bad thing for most integrations.

Governance tools, registries and intermediaries != SOA either but they are useful.

Yes ESB = IS + Broker (atleast that’s what SAG started calling from 7.x, source - white pages)
I agree, but what i meant is our canonical (Business Object model) is a broker document
I agree on second point also, however use of web services is a major part of SOA implementation in our case

Centrasite and Xbroker is more on SOA Governance (registries, design time policies, runtime policies etc…) Services can reside anywhere ESB, Weblogic, etc… anywhere.

Its difficult to take up an upgrade project when you are already in development phase. It would be great if SAG comes with a service pack for 7.1.2.

Context change does not necessarily mean change in service interface (change in XSD or WSDL). It may be a change in the internal logic of the service and hence version upgrade. It can also be change in environment end points.

Issue is when you generate a IS document from an XSD and try to make it a broker document. if its a small document we can manually alter “:” to something else. But with large broker documents it becomes a bit difficult.

Its not an issue. It’s more on readability when you have XSD with a name Customer.xsd and same document type in ESB is docType_ns_Customer.

Yes i agree but that means its not in ESB right now…

I was referring to WmPublic/pub.client:soapHTTP. We cannot pass tokens to http header. I have already raised this in Brainstorm

Yes i agree but that means again that its not in ESB right now…

Not an issue, the way it generated consumer should be consistent with how it is generated in Portal.

Yep this is annoying to the say the least, it’s what happens when you retrofit web services with two different product sets. Broker and IS come from different parents. While understandable at first I believe this should have been corrected by now.

Still not working correctly in Version 8. I have a current ticket on this, if it gets fixed correctly I’ll let you know. They have been able to duplicate the issues which is always a good thing.

Rob you know we disagree on this but that’s okay. :p:

Another option for this issue since SAG is unlikely to correct this, is simply to not use full namespace qualification on your local elements in your schemas. I stopped doing that even though others recommended it as a best practice and my life experience has improved dramatically. :biggrin: To many namespaces is the reason for global warming.

We do and it is!

Agreed. I generally avoid namespace prefixes altogether, except at the edges of the integration when required by an end-point.

I think the webMethods suite will continue to suffer problems 2,3,4,5 until it supports XML schema natively rather than importing them as IS/broker documents and then performing all subsequent processing on documents. There just seems to be an impedance mismatch between them.

ck

I think the irony here is that webMethods IS has been using XML pretty extensively underneath the covers. Flow and the documents you mention make heavy use of XML and they did this long before anybody else even new what Web Services or XML were. The problem I think though is they didn’t keep up with the trends. The idea of doing interface first design in the web services world was foreign to most tool vendors and languages including .Net and Java. They all supported XML but it was generally within the context of how they thought it was being used in their specific toolset. Everyone kind of rushed to retrofit their respective products to accommodate and there have been lots of releases across the board as this has progressed.

Your point is completely valid about it’s ability to handle externally generated XML schema and documents. The lack of control over what and how it is generated leads to a lot of frustration. And the broker which is written primarily in C doesn’t speak XML at all. Version 8 is making some strides towards better XML schema imports but it’s not completely there yet.:uhoh:

For me I’ve adopted a hybrid approach to the top down service design practice that eliminates the issues with schema imports and broker support of XML. It’s been effective for me and is compatible across the major toolsets. I hope to lay out the pattern for this at some point and I’ll post it somewhere for others to see. I use this design approach both in webMethods and .Net so it isn’t specific to the webMethods IS issue with XML schema.

We could all just forget this and go REST, it solves all these problems right?

I agree there are issues with the support of XML and XML schema, but I prefer the approach of all processing using IS documents. For me, XML, CSV, and other formats are better dealt with at the “edges.”

Other toolsets use the “all XML in the middle” approach, which is fine too.

There are 2 issues which we may face in this case

1. If we have to model our IS canonical form based on the XML schema, the import feature in Developer is of no use as it will add “:”. If we start doing it manually in IS then main point is defeated “ease of use” and “faster development time”

2. As long as we are doing integration interface we would still be happy with IS Documents. The moment we start using it as an application interface with MWS+BPM, we are stuck. The BPM needs a broker document (means we cannot use XML schema generated IS Document) and MWS application tries to invoke a webservice via ESB/BPM layer. We have rework to convert IS Document to XML specific IS Doc types created by webservices. This again defeats the purpose “ease of use” and “faster development time”. There are workarounds but they are not “'time” effective and do not provide an edge over services/utilities developed in normal JAVA/.NET or any other language.

Hi Guys,

Do you feel it is worth raising this in brainstorm ?
Please let me know your suggesstions.

Regards,
Sumit

yes. Colin has already raised for #1 but at least it’s worth raising for #2 and #3

Raised the ideas, votes please

1. URL parameter in web service alias (consumer)
   [url]http://softwareag.force.com/ideas/viewIdea.apexp?id=08720000000PDIn[/url]

2. Support for HTTP headers in soapHTTP and soapClient services
   [url]http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000004JcP[/url]

3. Broker documents do not support namespaces
   [url]http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000008a2X[/url]

4. Support for schema extensibility points
   [url]http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000008a2c[/url]

5. Document type names generated in ESB should be configurable
   [url]http://softwareag.force.com/ideas/viewIdea.apexp?id=087200000008a2h[/url]

2. The schema is again a problem. If 2 or more webServices are importing common schemas then the consumer generation in ESB gives heaps of warnings. Sometimes webService consumer documents do not generate some fields if a schema is already present withing ESB. This again is very critical, ESB should support having 2 same schemas in different folders without any warning/error

…For this wM 8 also not supported.I have tested in different packages, still its throwing warnings and its overwriting with old schemas.

If any body having idea on this …pls let me know…

Thanks,

Sreenivas