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

Thanks a lot for this info.

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.

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.

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.

https://documentation.softwareag.com/webmethods/wmsuites/wmsuite10-15/webhelp/understanding-sag-integration-and-api/

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.