We are starting to look at WSO2 Governance Registry software for our SOA Governance(so I'm just beginning to dig into this product). I see that you can auto-build governance data by pointing to a WSDL if you use web services.
Does anyone know if there is any way to do this auto-build by pointing to a Google Protocol Buffer .proto file?
This has our Message formats, and our Service details, so it would be very nice to be able to do that.
IF there isn't anything like that, COULD something be developed to do that (and if so, and pointers to the documentation I would need would be great!).
We are NOT using WebServices, so no WSDL's.....
Thanks!
This capability of pointing to a proto file and crating a service is not possible with WSO2 Governance Registry now.
However it is possible to add this as a new feature, and should be a simple implementation. AFAIK, this will be as simple as creating a handler to deal with proto file as a media type, and do the same stuff we do for a WSDL in that handler, and create a service out of that.
Having a WSDL is not a must to create a service. We can represent non-SOAP services too, in WSO2 Governance Registry.
Related
WSO2 reached out to me in Twitter and told me to put a question here if I had one.
My client wants to customize (for now it only means changing the layout of things) the API Publisher and API Store from a WSO2 API Manager 2.0.0.
Since I know that inevitably we will get to the point where the changes are going to be profound and require external libraries for new functionality (we have a library of AngularJS code which I know they will want to use), I want to know:
What is the official, recommended way to customize and extend the web applications for the API Store and the API Publisher? I need to have version control, unit testing, etc.
Is there a way to move these web apps out of the APIM server and into their own server? All our UI applications are hosted in a specific server.
Realistically, how much change can I introduce before make making an awful mess?
Thank you.
You can create new themes and subthemes for API publisher and store UIs. You can refer docs here.
Please note that publisher and store apps are written in Jaggery. You need a Jaggery server to host Jaggery apps.
If you want to add more functionality to the UI, you can either write jaggery, or you'll have to write your own web application (maybe with AngularJS or any other). In that case, you can use APIM REST APIs to talk to APIM backend.
I am doing a comparison between some Identity Management tools, one of which is the WSO2 Identity Server. I have found a number of wsdl files regarding WSO2 IS web services.
Is there any kind of documentation regarding operations in the wsdl files? Because i can't seam to find any.
Yes. Identity Server contains many web service APIs.. These APIs mainly support for identity and entitlement management functions. You can find web service API such as UserAdmin, RemoteUserStoreManagerService , EntitlementService and so on. But there are some web service APIs for server management functions.. All the UI that you see in WSO2IS server, calls backend web service APIs to get the operation done.. Unfortunately there is no any good document on explaining all these web service APIs. But if you are looking some specific function, You can find them.. As an example, if you want to use WSO2IS as authorization server, You must look about EntitlementService API. More detail on it can be found here. Like that, You can search for some specific topic about WSO2IS in the internet..and get some details about these service.
But, If you like to list and see all WSDL of WSO2IS, You go through this question that is asked in SO. Actually by looking at the WSDL, You can even get some idea about the functions.
I would like to implement access control to a Web service (operations, messages, etc.). My findings indicate that this can be done via WS-Policy or XACML. It looked to me like Axis2 has a good implementation of WS-Policy and one can define assertions that regulate access to every operation for example.
I have some questions:
1) Assuming I have WS-Policy xml file in place, how do I include it in the WSDL (using APIs to include it in the generated WSDL or manually)
2) Assuming I have an application design where client discover services through a broker residing in a repository, are the policies integrated within the wsdl in this repository and every provider who wants to implement a service follows the wsdl+policies in the borker repo OR every provider gets the wsdl from the repo and augments it with its own policies ?
Which approach is correct and feasible in the context of Axis2
3) Can i limit what services a client can search for in the repo by using WS-Policy with UDDI ? Is is supported by Axis2 ?
Thank you very much !!
WS-Policy is a very generic policy language that is not particularly aimed at authorization or access control.
WS-Policy focuses more on what should happen to the message (e.g. signature, encryption...). WS-Policy policies can be referenced to from the WSDL or you can use XSLT to embed the policy inside the WSDL after you generated your WSDL from the service stub.
XACML is much more specific to access control. In that sense, it is probably better suited to your use case. There are several open-source and vendor alternatives. Axiomatics, the vendor I work for, has a JAX-WS interceptor which intercepts your web service message and applies fine-grained authorization using XACML.
Regarding your third question:
Can i limit what services a client can search for in the repo by using
WS-Policy with UDDI ? Is is supported by Axis2 ?
I don't believe you can do that. Also, UDDI isn't actively developed anymore. The standard is a bit old.
Bottom line: WS-Policy is more about how to expose your service and how to handle operations and messages. XACML is more about the actual business authorization logic.
I am working on WSO2 ESB 4.0.3 on MAC OS X Lion (10.7.4)
I would like to know what are the best practices for development for WSO2 ESB 4.0.3.
Currently I am using Data Services Feature in it and existing tomcat application, which we are trying to port to WSO2 ESB, does the SQL query in 2-3 seconds where as WSO2 ESB 4.0.3 with Data Services feature taking around 16-17 secodns.
I would be thankful if some body can let me know best practices for WSO2 and in perticular XSLT transformation.
Hoping for answer.
thanks
Hi Prabath
Here is how my environment is
I am using WSO2 ESB 4.0.3 with Data Services Feature 3.2.2. Proxy service front ends the DS service. Data sources are defined as carbon data sources in datasources.properties.
I tried to run the same service in the WSO2 Data Services Server 2.6.3 and the performance is comparable to what existing tomcat application does but the ESB 4.0.3 with Data Services Feature 3.2.2 takes 8 times more time than tomcat application. Looks like XSLT is not a issue as I thought earlier.
I have all the error handling & input validation in the proxy service which calls this DS.
Also I tried changing it to local for the transport but still same performance issue. Also I have to make sure the format of the forwarded XML is SOAP 12 in the end point definition otherwise proxy service does not forward with local transport.
Can you please suggest so that I can use WSO2 ESB with Data Services Feature 3.2.2 and get comparable performance?
Help really appreciated.
thanks
Abhijit
Hi Prabath
Thanks for reply.
Proxy service validation and transformation is not a problem. Looking at the logs it looks like Data Service deployed in ESB with Data Services feature is taking 8 times more time than the tomcat application. So it is Data Services Feature which is problem I believe and not the proxy service.
Even if we remove the proxy service where you will do the input validations and error handling?
Please let me know.
thanks
Abhijit
Abhijit,
I'm not quite clear of whether this problem is related to executing SQL using dbReport/dbLookup mediators against doing the same thing having data services features installed in ESB OR transforming responses using XSLT at the ESB layer against doing it at the DSS layer.
If it's the former, then you should be able to effectively use the db mediator pair (namely dbLookup and dbreport) to execute simple SQL queries such as SELECT, INSERT, UPDATE, DELETE, etc. However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.
If this is related to the later, meaning, if you refer to the XSLT transformations, I believe there's no such hard and fast rules in doing this and this would completely depend on your requirements and the usecase. For example, if you're only using WSO2 DSS and want to get some request transformed into a particular format that is expected by the client side, it would only be enough for you to get it done at the WSO2 DSS layer. Because, dispatching it into ESB ONLY for the sake of getting the XSLT transformation done, would add an additional unwanted overhead to the end-to-end completion time of your task. On the other hand, if you're doing this as a part of a configuration flow at the ESB side, then it's perfectly okay to use something like XSLT mediator inside the flow itself.
Hope this helps!
Regards.
Prabath
I hope Prabath already gave the answer to your question.
However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.
I'm learning about web services and most of the resources I've been reading talk about registering your web service once it's ready for use by others. Is registering a web service required to use the service?
For example, let's say I have a web application on a company intranet and I create another web service app that retrieves some sort of useful information to be displayed on this private intranet site. Would this new web service require being registered just so my web app can use it or can the web app simply interface directly to the new web service (following the WSDL file) without the need of some sort of UDDI registry?
You can certainly use the service without the UDDI registry.
I have created several Web Services and have immediately used them without registering them. Registration gives others confidence that your Web Service is legitimate and descriptions of how to interact with those services.
Imagine doing development where you have to register any Web Service before using it. Yikes!
No, not at all.
You are probably talking about API directories you may register your WS at. Like UDDI or what it’s named. Entirely optional.
Nobody uses UDDI anymore. It's an idea whose time has come and gone.
It was thought that there would be public registries of web services that everyone would use to find a web service to meet their needs. That never happened.
How could either the service or the app know whether or not the service was registered?
Furthermore, why would they care?
If you're trying to use service orientation the right way, your web services should be registered within a service registry. The registry should contain the published contract of the services and any meta-data that helps the discovery process.
A different questions is: does a service consumer program need to look up a registry and dynamically bind the service it needs to call? NO, NOT AT ALL.
But then, what discovery process am I talking about?
I'm referring to a human (developer, architect, etc.) who is designing/developing a program that needs to call a service. This person should have means to search what services are available in his/her organization. If not, the benefit of reusing services is compromised.
Discovery is also about humans finding out there's a service somewhere in the IT organization that offers the functionality they want.
In this case, the registry can be as simple as an html report that is created and updated manually or generated by parsing (xslt comes handy) the wsdl files.