What is the best to exporting API & EndPoint & DataService on WSo2 ?
usually I export the API & EndPoint in same car.file then exporting dataservice in other carbon file
If your APIs and the Dataservices depend on each other it may be best to package them together. If not, packaging them together would introduce unnecessary downtime to the other service when updating one service. (Redeploying an API would redeploy the Data services). Also, Carbon Applications are deployed in alphabetical order. So if you have anything that depends on the deployment order you can prefix the carbon application with a number or a letter. For example 1_APIServices.car, 2_AppDataServies.car. So they will always be deployed in a certain order on server restart.
This is based on the use cases and requirements. If you want to reuse the data service or the API, then you can have them in separate car files and deploy. Otherwise you can have those in a single car file.
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.
deploying the WSO2 APIM 2.1.0 using puppet, we consider to deploy the API itself with the CICD as well.
In theory - I could copy (template) the synapse files (proxy, api) and the api is available for the call, however - the API is not visible in the store. I assume there's more data in the database than just a synapse config file.
Is there a way to define / deploy API (including to the store) using the configuration files or it needs to be done manually?
Edit:
I thought there's a way to deploy API using the API Admin Services. But when calling addAPI with the metadata XML, looks ok. But trying to see the API in the publisher throws an exception
ERROR - index:jag org.wso2.carbon.apimgt.api.APIManagementException: Unable to find the API: admin-myapi-v1.0.0 in the database
Thank you for any hint
g.
Based on your requirements it looks like you can use one of the following options.
Migrate APIs - You can export APIs from one environment and import those APIs to the new environment. When you import APIs in the new environment, those APIs will be in created state. You need to manually publish those APIs. May be using the jaggery API or REST API you will be able to publish the APIs.
REST API
Jaggery API - This is deprecated at the moment and discourage for using this.
Once you create the APIs, APIs related details will be saved in the database. Additionally, synapse configuration can be found in the file system. If you point the previous database to the new deployment and deploy the synapse artifacts, APIs will work. But then again API creation/publishing and entire flow will not be tested. For CICD, you need to consider above mentioned options. In the future releases, there is more focus towards the REST API and it will be more useful for the CICD.
I am using Axis2 (1.5.3 currently) and Tomcat (6.0.26 currently) and am running a web service. I would like to also host HTML pages for configuring the web service.
What is the best way to go about this? I assume keeping the same context is key, but perhaps it is not.
My current distribution is located under a folder structure similar to this:
Tomcat/webapps/mycompany
With the actual service code here:
Tomcat/webapps/mycompany/WEB-INF/services/myService
In a browser, I can hit my web service by going to here:
/mycompany/services/myService
I note that I can drop actual HTML files in this path and Tomcat will, indeed serve them up.
For instance, if I put "index.html" under Tomcat/webapps/mycompany, I can navigate to /mycompany/index.html and see my html.
What I want to do is have this HTML be attached to JAR/class files that can interact with the already-existing service class files in the same context as the service. Therefore, I can have the browser configure the web service directly.
Is this possible, and is there a tutorial or something out there that will help me with this? Note that I have been working with Tomcat and Axis2 for a while now for this particular web service, but I have never actually deployed a web application/html using Tomcat before.
Thanks.
First of all what do you mean by a configuring a service. Normally in SOA world services are analogous to interfaces. IMHO you can just change a service, since their are other users that rely on the services you are exposing.
If i want to change a service i would rather introduce a new version of the service after deprecating the existing one.
Are you talking about applying QoS to existing serviecs. Then that makes sense.
Anyway, If you want to have a web-app alongside with axis2 service engine, it is possible. If you look inside the axis2 war file you'll find the web.xml entry to Axis2Servlet. It is this servlet that serves the web services requests.
So, what you need is the Axis2Servlet mapping in your web-app along with your usual servlet-mappings. Number of possible ways to configure your services using web-app files. One options is to use web-services call itself to (with authentication) to configure it.
By "configure a service", take this example:
The service has a set of datasets.
Each dataset exists in a separate database.
The service can manage 0..n datasets.
The service must be configured to know about each dataset.
This is what I'm configuring. I'm not trying to configure Axis itself or redefine the service.
I would like to host the HTML using the same instance of Tomcat that I'm hosting the web service with. It needs to manage sessions, have login capability, an whatnot, and has to be able to configure the web service live.
From what I'm reading, it's probably best to make an interface to the web service that the web application module can call into from a different context.
Is there a better way?
We are evaluating multiple ESB products currently (Mule, Fuse and WSO2), and one of our key requirements is to easily migrate services between multiple environments. I can see how this can be done in WSO2 with g-reg for the most part, but am struggling to see how we would parametrise the endpoint uris and maintain them separately in each environment? (This seems fairly trivial in Mule and Fuse).
The preferred way is:
Create/save ALL endpoints as registry resource (either using management console or Developer Studio)
Since the endpoints are saved in the registry, now the ESB configuration is totally independent of the environment. (We can create a Carbon Application out of this, which is basically can be deployed in any environment)
So, if you need to move the configuration from dev->qa, you can use the same .car file created
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.