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
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]
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
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 “:”
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
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.
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.
MTOM with SOAP 1.1 is not supported in ESB
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
No support for SOAP over JMS
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.
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.
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.
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.
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.
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”
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.
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.
