So I want to learn about the Service Oriented Architecture that in detail that can be done using webMethods, just wanted to ask about whether it is possible to do any kind of project using webMethods or is there any resources to learn Service Oriented Architecture in order to get better clarity of where webMethods is used.
Hi Kirtish,
the webMethods Suite is aware of WebServices based on SOAP protocol as well JSON-Rest-Apis.
Adittionally it is providing some adapters for connecting to different datases, SAP system, etc.
You might want to check out the documentation section for some guides and/or get you a free trial edition and explore it yourself.
Regards,
Holger
SOA and webMethods arenât exactly the same. webMethods integration server and most of the webMethods products have Service Oriented Architecture, meaning it has this architectural pattern and thatâs it. You can implement anything with SOA. You donât even need to have SOAP (simple object access protocol) anywhere to implement SOA(service oriented architeture) because they are not really related at all.
SOA is basically an architectural pattern that lets you implement loosely coupled systems. As an example, imagine functional programming and replace every function with a webservice. Thatâs what SOA is. When you have this architecture, you can change any webservice with some other service, as long as you donât change the service signatures. In webMethods, even simple sum functions are webservices.
It is possible to do anything with webMethods. When you canât do something with predefined services, you can implement a new service using JAVA(native language for webMethods), C/C++, C# and even pyton, or bash and so on.
I usually like wikipedia as a starting point. You donât need webMethods for SOA. You can implement SOA with any programing language that has web service support.
Consider this scenario for a better picture. You have a 3rd party system that has a certain functionality, like sending emails or printing files or creating pdf documents. Assume you need a library to access these features and you have multiple clients that use the same functionality. If you deploy the library to implement these functions on client side, next time you want to make changes to the implementation(you might even want to change the product itself or move some of the functions elsewhere), you need to update every client. This simple task can become pretty problematic. For example, that app itself may need an update/upgrade for support, and the upgrade may require library change, and sometimes you canât find the responsible team at all. Every user story is finished, project is live and itis no longer supported because there arenât any issues/bugs left so it doesnât even have a responsible team. What SOA provides here is, you wrap the library with a service, and next time you need to make changes to the implementation, you update the service. You can even add versions to the service end point to support previous versions. Other then this benefit, its pretty much the same as functional programing.
3 Likes
Thanks a lot for this info
In addition to @engin_arlak great detail, I would offer this â donât worry about the âSOAâ label at all. It has never had a well-scoped definition. It inaccurately morphed into being a synonym for SOAP (which itself became an inaccurate synonym for âweb servicesâ) but the âbuzzwordâ nature of it has died off. I donât hear anyone use SOA in any context any more.
These days the buzzword is âAPIâ â presented as though they are a recent invention, even though âAPIsâ have been around for decades. The twist here is the prevalent use of HTTP for transport and JSON for representation â which in buzzword fashion have pirated the original meaning of REST to refer to any communication of JSON over HTTP (even though the REST definition by Fielding did not specify the use either of those things). âREST APIâ is commonly used, even though the inventor of REST at one point said âthere is no such thing as âREST APIâ.â
In any case, there is a pile of material on the web related to âwhat is SOAâ? Be aware that the definitions will vary, depending upon the author. In particular, vendors will use definitions that may or may not be consistent with descriptions from âacademicsâ or analysts.
If youâre designing an application, or collection of related components that interact loosely, the concepts of SOA will be helpful. If youâre an integration-focused person, the concepts are good to know but are somewhat less applicable since the âin-the-middleâ components are constrained by what the end-points support.
Of course this is wading into a broader discussion of âintegrationâ and how to structure the various components, assign roles/responsibilities, etc. This chat could go many, many directions. 
2 Likes
What is the background for the question? What do you want/need to accomplish?
Since my organizationâs project has SOA principles in it and they also work with SOAP and WSDL I just basically want to understand the principles that is used in my project so that I get much more clarity about certain things , for example where is webMethods used in this architecture and why was this architecture designed this way in the first place. To be honest even if I ask someone to explain the architecture no one really has the time to do it. So I want to understand it on my own.
You should have asked like that. Check the document below. It has everything you need. You probably donât have everything in your environment. Try to focus on what you have.
1 Like
Keep in mind that SOA != SOAP/WSDL. Many seem to view it that way but SOA as an architectural style does not dictate the use of SOAP (indeed, it does not specify any particular format, protocol, etc.). And the use of SOAP does not mean one is âdoingâ SOA. (Side trip: using JSON over HTTP does not mean one is âdoingâ REST either but thatâs another topic.)
What are the principles the project has indicated they are adopting? With those perhaps the community can share thoughts related to those on how wM components can fit and what roles/responsibilities are reasonably assigned to them within the architecture.
For example, middleware tools can be used in these contexts, which will differ in design and details:
-
As a logical extension of an application. Often times an application needs to be customized in some way. That customization can be hosted in wM tools and viewed as part of the application itself.
-
As a pure intermediary. wM tools used to facilitate interactions between applications, with varying degrees of coupling.
-
As an independent actor that is viewed as another application. The CAF, workflow, BPM, etc. components can be used to create custom applications.
The obvious focus of the wM suite is integration (middleware) capabilities but it has components that can go beyond that.
To the degree you can share more detail about the project principles and the high-level function of the project it would help the participants here provide more meaningful guidance.
2 Likes
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.